DOPインシデントとイベントへの対応複数選択
AWS Organizations 環境で本番アプリケーションが障害を起こし、直前に行われた何らかの設定変更が原因と強く疑われている。DevOps チームは、影響を受けたリソースについて「いつ・誰が・どのリソースをどのように変更したのか」を正確に特定し、根本原因を突き止めたい。この調査に最も適した手法を2つ選びなさい。
AAWS Config の設定タイムライン（configuration timeline）で対象リソースの構成項目の変更履歴・関連リソース・変更時刻を時系列で追跡する
✓ 正解
AWS Config の設定タイムラインは対象リソースの構成項目スナップショットを時系列で保持し、変更された属性・変更時刻・関連リソースへの影響を追跡できるため、「何がどう変わったか」の特定に直結し要件に合致する。
BAWS CloudTrail のイベント履歴で障害発生時間帯の管理イベントを検索し、どの IAM プリンシパルがいつどの API を呼び出したかを特定する
✓ 正解
AWS CloudTrail のイベント履歴は管理イベントとして API 呼び出しを記録し、実行した IAM プリンシパル・時刻・操作内容を特定できるため、「誰がいつ変更したか」を突き止める根本原因分析の要件を満たす。
CAmazon GuardDuty の検出結果を確認し、脅威インテリジェンスに基づく異常なアクティビティのパターンから設定変更を行った実行者を割り出す
Amazon GuardDuty は脅威インテリジェンスと機械学習で悪意ある挙動を検知するサービスで、正規の設定変更の完全な履歴や実行者を網羅的に追跡する目的には設計されておらず、原因究明の主軸にはならない。
DAWS Trusted Advisor のチェック結果の推移を確認し、ベストプラクティスからの逸脱が発生したタイミングから設定変更の時刻を推定する
AWS Trusted Advisor はコスト・セキュリティ・パフォーマンス等のベストプラクティスをチェックするが、個々の設定変更の正確な時刻や実行者を記録しないため、いつ誰が変更したかの特定はできず推定にとどまる。
EAmazon Inspector の継続的スキャン結果を確認し、脆弱性スコアの変化から変更が加えられたリソースと変更内容を特定する
Amazon Inspector は EC2・コンテナ・Lambda の脆弱性やネットワーク到達性を評価するサービスで、設定変更の変更履歴や実行者を記録する機能を持たないため、根本原因の特定には利用できない。
解説
設定変更に起因するインシデントの根本原因分析では、「何がどう変わったか」と「誰がいつ変えたか」を突き合わせるのが定石である。
AWS Config の設定タイムラインは、各リソースの構成項目（configuration item）のスナップショットを時系列で保持し、いつ・どの属性がどう変化したか、関連リソースへの影響までを追跡できる。
AWS CloudTrail のイベント履歴は、API 呼び出しを記録し、どの IAM プリンシパルが・いつ・どの操作を実行したか（誰が変更したか）を特定できる。
この2つを組み合わせることで「いつ・誰が・何をどう変更したか」を完全に再構成できる。
選択肢の GuardDuty は脅威検知が目的で、正規の設定変更の履歴や実行者を網羅的に追跡する用途ではない。
選択肢の Trusted Advisor は推奨事項のチェックで、変更の時刻や実行者を正確に特定できず推定にとどまる。
選択肢の Inspector は脆弱性・ネットワーク到達性の評価であり、設定変更の履歴や実行者の特定には使えない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →