模擬問題集一覧

SCS-C03 模擬問題集（練習問題）

AWS Security – Specialty 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

2 練習テスト 100 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

2 テスト · 全 100 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%

説明

SCS-C03（AWS Security – Specialty）の合格に向けた、本番形式の模擬問題集です。全 100 問を2 回の練習テストに分割し、 試験モード／演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 100 問＋全解説が受け放題

模試プラン（¥980/月）なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

SCS-C03 の出題範囲（カバーしている分野）

全 100 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はSCS-C03 の学習ガイドにまとめています。

SCS-C03 の無料練習問題（15 問・解説つき）

会員登録なしで、全 100 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1【図の内容（S3 バケットポリシーの文字起こし）】 { "Effect": "Allow", "Principal": …アイデンティティおよびアクセス管理
問題
セキュリティエンジニアが、MyLambdaFunction という名前の AWS Lambda 関数のトラブルシューティングを行っています。この関数は、DOC-EXAMPLE-BUCKET という名前の Amazon S3 バケット内のオブジェクトを読み取ろうとするとエラーになります。この S3 バケットには次のバケットポリシーが設定されています。 【図の内容（S3 バケットポリシーの文字起こし）】 { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:lambda:::function:MyLambdaFunction" } } } Lambda 関数がバケット内のオブジェクトを読み取れるようにするには、セキュリティエンジニアはこのポリシーにどのような変更を加えるべきですか？

選択肢と解説

  • 1
    Condition 要素を削除し、Principal 要素を別の値に変更する。
  • 2
    Action 要素を別の値に変更する。
  • ✓
    Resource 要素を "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*" に変更する。
  • 4
    Resource 要素を "arn:aws:lambda:::function:MyLambdaFunction" に変更し、Principal 要素も変更する。

解説

【正解】C

【0からの解説】
S3 のアクセス許可では、操作の対象が「バケットそのもの」なのか「バケット内のオブジェクト」なのかで、ARN（リソース指定）の書き方が変わります。
・バケット自体に対する操作（例: s3:ListBucket）→ ARN は arn:aws:s3:::バケット名（末尾なし）
・オブジェクトに対する操作（例: s3:GetObject、s3:PutObject）→ ARN は arn:aws:s3:::バケット名/*（末尾に /* が必要）

この問題のポリシーは Action が s3:GetObject（=オブジェクトの読み取り）であるにもかかわらず、Resource が arn:aws:s3:::DOC-EXAMPLE-BUCKET（バケット自体）になっています。GetObject はオブジェクトレベルの操作なので、このリソース指定ではどのオブジェクトにも一致せず、Lambda 関数はアクセス拒否（Access Denied）になります。
そこで Resource を arn:aws:s3:::DOC-EXAMPLE-BUCKET/* に変更し、「バケット内のすべてのオブジェクト」を対象にすれば、s3:GetObject が正しく許可され、関数はオブジェクトを読み取れるようになります。

【誤りの選択肢】
A：Principal の Service は lambda.amazonaws.com で、Lambda がサービスとしてアクセスする際の指定として妥当です。Condition の aws:SourceArn は特定の関数だけに限定する正しい制限であり、削除や Principal 変更は問題の原因（リソース ARN の不一致）を解決しません。
B：Action は s3:GetObject であり、オブジェクト読み取りには正しい権限です。問題はアクションではなくリソース ARN にあるため変更不要です。
D：Resource を Lambda 関数の ARN に変えるのは誤りです。S3 バケットポリシーの Resource は S3 リソース（バケットやオブジェクト）を指す必要があり、Lambda 関数 ARN を指定しても S3 オブジェクトへのアクセスは許可されません。

【参考】
Amazon S3 のバケットポリシーの例
Amazon S3 リソースの ARN 形式
この問題のページを開く →
問題 2最も少ない管理オーバーヘッドでこの要件を満たすソリューションはどれですか？データ保護
問題
セキュリティエンジニアが Amazon Macie を使用して、会社の Amazon S3 バケット内の機密データをスキャンしています。会社には多数の S3 バケットがあり、それぞれに多数のオブジェクトが保存されています。セキュリティエンジニアは、機密データを含む S3 バケットを特定し、それらのバケットに対して追加のスキャンを実行する必要があります。 最も少ない管理オーバーヘッドでこの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    S3 バケットに S3 クロスリージョンレプリケーション（CRR）を設定し、オブジェクトを 2 つ目の AWS リージョンにレプリケートする。2 つ目のリージョンの Macie で、レプリケートされたオブジェクトを毎日スキャンする。
  • 2
    S3 バケットの S3 イベント送信先として AWS Lambda 関数を作成する。オブジェクトが S3 バケットにアップロードされたときに、その Lambda 関数がそのオブジェクトの Macie スキャンを開始するように設定する。
  • ✓
    Macie 自動検出（automated discovery）を設定し、S3 バケットからデータを継続的にサンプリングする。Macie が機密データを検出した S3 バケットに対してフルスキャンを実行する。
  • 4
    S3 バケットに対して Macie スキャンを実行するよう設定する。スキャン結果を Amazon DynamoDB テーブルに集約し、クエリに利用する。

解説

【正解】C

【0からの解説】
Amazon Macie は、機械学習とパターンマッチングで S3 内の個人情報（PII）などの機密データを発見するマネージドサービスです。
Macie の「自動機密データ検出（automated sensitive data discovery）」を有効にすると、Macie が組織内の全 S3 バケットからオブジェクトを継続的に効率よくサンプリングして分析し、どのバケットに機密データがありそうかをマップ（機密度スコア）で示してくれます。これは追加の構成がほとんど不要で、AWS が自動で対象を選んでサンプリングするため管理オーバーヘッドが最小です。
そのうえで機密データが見つかったバケットだけに対してフルスキャン（機密データ検出ジョブ）を実行すれば、無駄なく深掘りでき、要件（特定→追加スキャン）を最小の手間で満たせます。

【誤りの選択肢】
A：CRR で別リージョンに複製してからスキャンするのは、レプリケーション構成・追加ストレージコスト・別リージョン運用が増え、オーバーヘッドが大きいです。機密データ特定にレプリケーションは不要です。
B：Lambda でアップロード毎にスキャンを起動する設計は、関数開発・イベント連携・既存オブジェクトの扱いなど運用負荷が高く、「最も少ない管理オーバーヘッド」に反します。
D：すべてのバケットを最初からフルスキャンし、結果を自前で DynamoDB に集約する構成は、スキャンコストも実装負荷も高く非効率です。Macie 自体に検出結果の確認手段があるため自作の集約は不要です。

【参考】
Macie の自動機密データ検出
Amazon Macie とは
この問題のページを開く →
問題 3この要件を満たすソリューションはどれですか？インシデント対応
問題
セキュリティエンジニアが、ある AWS アカウントに影響を及ぼしているインシデントに対応しています。アカウント ID は 123456789012 です。攻撃により、複数の AWS リージョンにまたがってワークロードが分散して作成されました。 セキュリティエンジニアは攻撃を封じ込め、影響を受けたすべてのリージョンからコンピューティングおよびストレージのリソースを削除しました。しかし、攻撃者は AWS KMS キーも作成していました。この KMS キーのキーポリシーは、IAM プリンシパルに kms:* 権限を明示的に許可しています。 このキーは前日に削除がスケジュールされていましたが、依然として有効で使用可能な状態です。キーの ARN は arn:aws:kms:us-east-2:123456789012:key/mrk-0bb0212cd9864fdea0dcamzo26efb5670 です。セキュリティエンジニアは、このキーをできるだけ早く削除する必要があります。 この要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    アカウントのルートユーザー認証情報でログインし、待機期間 7 日で KMS キーの削除リクエストを再発行する。
  • ✓
    KMS キー ID が存在する他のリージョンを特定し、7 日後の削除をスケジュールする。
  • 3
    IAM プリンシパルが KMS キー ARN に対して kms:* を許可するように更新し、待機期間 7 日で削除リクエストを再発行する。
  • 4
    KMS キーを無効化し、30 日後に削除リクエストを再発行する。

解説

【正解】B

【0からの解説】
キー ARN の中の鍵 ID が mrk- で始まっていることに注目します。これは「マルチリージョンキー（multi-Region key, MRK）」を示します。マルチリージョンキーは、プライマリキーと、他リージョンに作られた「レプリカキー」が同じキーマテリアル・同じキー ID（mrk-... 部分）を共有する仕組みです。

マルチリージョンキーでは、各リージョンのキーは独立して管理され、削除のスケジュールはリージョンごとに個別に行う必要があります。あるリージョンで削除がスケジュール済みでも、他リージョンのレプリカが残っていればキーは使われ続けます。さらに、レプリカキーが残っている間はプライマリの完全な削除に制約が生じます。
したがって、攻撃者が複数リージョンにわたって作成したこのキーを確実に消すには、まず同じキー ID を持つ全リージョンのキーを洗い出し、それぞれで削除をスケジュールする必要があります。KMS の削除待機期間は最短 7 日なので、7 日でスケジュールするのが「できるだけ早く」削除する方法です。

【誤りの選択肢】
A：ルートユーザーでログインしても、削除待機期間の最短は 7 日であり通常操作と変わりません。さらに他リージョンのレプリカキーを無視しているため、キーは他リージョンで使われ続けます。
C：問題文の通りキーポリシーはすでに kms:* を明示的に許可しており、削除権限は不足していません。権限を更新しても他リージョン対応をしていないため要件を満たしません。
D：無効化（disable）だけでは削除になりません。また KMS の削除待機期間は最短 7 日で、30 日を選ぶのは「できるだけ早く」に反します。他リージョン対応もありません。

【参考】
マルチリージョンキーの削除
KMS キーの削除
この問題のページを開く →
問題 4【図の内容（IAM マネージドポリシーの文字起こし）】 { "Version": "2012-10-17", "Stat…アイデンティティおよびアクセス管理
問題
ある AWS アカウント管理者が IAM グループを作成し、各ユーザーが多要素認証（MFA）を使って認証することを必須とするため、次のマネージドポリシーを適用しました。このポリシーを適用した後、管理者は「ユーザーが AWS CLI を使って Amazon EC2 のコマンドを実行できない」という報告を受けました。 【図の内容（IAM マネージドポリシーの文字起こし）】 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:*", "Resource": "*" }, { "Sid": "BlockAnyAccessUnlessSignedInWithMFA", "Effect": "Deny", "Action": "ec2:*", "Resource": "*", "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } } } ] } MFA を引き続き強制しつつ、この問題を解決するには管理者は何をすべきですか？

選択肢と解説

  • 1
    aws:MultiFactorAuthPresent の値を true に変更する。
  • ✓
    ユーザーに対し、aws sts get-session-token CLI コマンドを実行し、MFA の --serial-number と --token-code パラメータを渡すよう指示する。得られた値を使って API/CLI 呼び出しを行う。
  • 3
    SAML 2.0 を使ったフェデレーション API/CLI アクセスを実装し、ID プロバイダー側で MFA を強制するよう設定する。
  • 4
    ロールを作成しロールの信頼ポリシーで MFA を強制する。ユーザーに sts assume-role を実行させ --serial-number と --token-code を渡させ、得られた値を環境変数に保存する。ポリシーの NotAction に sts:AssumeRole を追加する。

解説

【正解】B

【0からの解説】
このポリシーは「MFA で認証されていない場合は ec2:* をすべて拒否する」という典型的な MFA 強制ポリシーです。ポイントは aws:MultiFactorAuthPresent がいつ true になるかです。
このキーは、リクエストを行う際の一時的な認証情報（セッション）が MFA を使って取得された場合にのみ true になります。AWS マネジメントコンソールは MFA でサインインすると自動的に MFA 付きセッションになりますが、AWS CLI で長期アクセスキー（アクセスキー ID とシークレットキー）をそのまま使うと、そのリクエストには MFA 情報が付かないため aws:MultiFactorAuthPresent は false 扱いになり、Deny に引っかかって EC2 操作ができません。

解決策は、CLI でも MFA 付きの一時セッションを取得することです。aws sts get-session-token を MFA デバイスのシリアル番号（--serial-number）とワンタイムコード（--token-code）付きで実行すると、MFA 認証済みの一時認証情報（アクセスキー・シークレット・セッショントークン）が返されます。これらを使って CLI を実行すれば aws:MultiFactorAuthPresent が true になり、Deny を回避しつつ MFA 強制を維持できます。

【誤りの選択肢】
A：aws:MultiFactorAuthPresent はリクエスト時に AWS が自動判定する条件キーであり、ポリシーで true に「書き換える」ものではありません。値を true に固定するとそもそも MFA 強制の意味がなくなります。
C：SAML フェデレーションに切り替えるのは大掛かりな構成変更で、既存の IAM ユーザー＋CLI 運用を維持したいこの状況には過剰です。問題は MFA 付きセッションの取得方法であり、フェデレーション導入は不要です。
D：sts:AssumeRole を NotAction に入れると、その操作が MFA なしでも拒否されなくなり MFA 強制が緩みます。また assume-role 方式は別ロールへの切り替えが前提で構成が複雑になり、最小限の解決策としては不適切です。

【参考】
MFA で保護された API アクセスの設定
GetSessionToken（AWS STS）
この問題のページを開く →
問題 5これらの要件を満たすソリューションはどれですか？セキュリティの基盤とガバナンス
問題
ある会社が、認証局（CA）を使ってコード署名証明書に署名するコード署名アプリケーションを開発する必要があります。このソリューションは AWS Key Management Service（AWS KMS）の非対称キーを使用する必要があります。さらに、コンプライアンス目的で、その KMS キーの作成・由来・使用に関する変更不可能（immutable）な証拠を収集して保存し、社内監査人が参照できるようにする必要があります。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    S3 オブジェクトロックを有効にした Amazon S3 バケットを作成する。すべての kms.amazonaws.com の CreateKey イベントについて、イベントセレクターとログファイル検証を有効にした AWS CloudTrail 証跡を作成する。CreateKey イベントをその S3 バケットに送るようイベントセレクターを設定する。KMS キーを作成する。その後、当該 KMS キー ARN を参照する API 呼び出しを対象にするようイベントセレクターを更新する。監査人にその S3 バケットへのアクセスを付与する。
  • 2
    KMS キーを参照するアプリケーション操作のログを実装する。ログに関連メタデータをすべて含める。ログを Amazon CloudWatch Logs ロググループに保存する。ロググループの自動エクスポートを設定し、エクスポートを監査人に送る。
  • 3
    監査人がアクセスできる Amazon DynamoDB テーブルを作成する。Amazon EventBridge ルールで起動される AWS Lambda 関数を作成する。EventBridge ルールが KMS API 呼び出しを監視し、当該 KMS キー ARN を参照するすべての API 呼び出しを対象にフィルタするよう設定する。Lambda 関数が API 呼び出しの内容を DynamoDB テーブルに保存するよう設定する。
  • 4
    Amazon CloudWatch Logs Insights を、KMS キー使用状況を追跡するカスタムメトリクスとともに設定する。CloudWatch ダッシュボードでリアルタイムにメトリクスを可視化する。CloudWatch アラームを設定する。サブスクリプションフィルターでデータを別アカウントに複製し、監査人がレビューできるようにする。

解説

【正解】A

【0からの解説】
要件の核心は「KMS キーの作成・由来・使用に関する変更不可能（immutable）な証拠を、コンプライアンス／監査向けに保存する」ことです。AWS で「いつ・誰が・何の API を呼んだか」を記録する標準サービスは AWS CloudTrail です。CloudTrail は KMS の CreateKey や暗号化/復号などの API 呼び出しを記録できます。

「変更不可能」を実現する 2 つの仕組みが鍵です。
・S3 オブジェクトロック：保存したログオブジェクトを一定期間（または無期限で）削除・上書きできないようにする WORM（Write Once Read Many）機能。これでログの改ざん・削除を防ぎます。
・CloudTrail のログファイル検証（log file validation）：ログファイルが配信後に改ざんされていないことをハッシュ（ダイジェスト）で検証できる機能。証拠の完全性を証明できます。
この 2 つを組み合わせ、CloudTrail のイベントセレクターで KMS の CreateKey と当該キー ARN を参照する呼び出しを捕捉し、改ざん不可能な S3 バケットに保存して監査人に読み取りアクセスを与える A が要件を完全に満たします。

【誤りの選択肢】
B：CloudWatch Logs は閲覧・分析には便利ですが、それ自体に WORM（変更不可能性）の保証はありません。アプリ側ログの自作はカバレッジも不確実で「immutable な証拠」要件を満たせません。
C：DynamoDB に API 内容を保存しても、テーブルのレコードは更新・削除が可能であり改ざん耐性がありません。Lambda 自作部分の信頼性・完全性証明も乏しいです。
D：CloudWatch ダッシュボードやアラームは監視・可視化向けで、改ざん不可能な監査証跡の保存手段ではありません。サブスクリプションでコピーしても WORM 保護にはなりません。

【参考】
CloudTrail ログファイルの整合性の検証
S3 オブジェクトロックの使用
AWS KMS の CloudTrail によるログ記録
この問題のページを開く →
問題 6（2 つ選択してください）インシデント対応
問題
ある開発チームが、会社の SaaS（Software as a Service）アプリケーションを管理するためのオープンソースのツール群を作成しています。会社は誰でもコードを閲覧・ダウンロードできるよう、コードをパブリックリポジトリに保存しています。 その後、コードの中に、会社の AWS 環境の内部リソースへのアクセスを与える IAM アクセスキーとシークレットキーが含まれていることが判明しました。 セキュリティエンジニアは、流出した認証情報が不正に使用されたかどうかを特定するソリューションを実装する必要があります。さらにそのソリューションは、流出した認証情報の追加使用を防止する必要もあります。 これらの要件を満たす手順の組み合わせはどれですか？（2 つ選択してください）

選択肢と解説

  • 1
    AWS IAM Access Analyzer を使用して、流出した認証情報がどのリソースにアクセスし、誰が使用したかを特定する。
  • ✓
    流出した IAM アクセスキーを、そのユーザーの IAM アカウントで無効化（deactivate）する。
  • 3
    Amazon GuardDuty にルールを作成し、ソースコード内のアクセスキーが使用されるのをブロックする。
  • 4
    流出したユーザー向けに、新しい IAM アクセスキーとシークレットキーを作成する。
  • ✓
    IAM 認証情報レポートを生成する。レポートを確認し、アクセスキーを所有するユーザーが最後にログインした日時を特定する。

解説

【正解】B、E

【0からの解説】
公開リポジトリに IAM アクセスキー／シークレットキーが漏洩した状況です。要件は「不正利用が発生したかを特定する」ことと「それ以上の不正利用を防ぐ」ことです。
E（IAM 認証情報レポート）：認証情報レポートには各アクセスキーの最終使用日時(access key last used)・最終使用リージョン・最終使用サービスが記録されます。これを見れば、漏洩後にそのキーが使われたか、想定外のリージョン／サービスから使われていないかを確認でき、「不正利用が発生したか」を特定できます。
B（漏洩したアクセスキーの無効化）：露出したアクセスキーを直ちに無効化(deactivate)すれば、以後そのキーでのアクセスを止められ、追加の不正利用を防げます。
この 2 つ(B と E)の組み合わせが、特定と封じ込めの両方を満たします。

【誤りの選択肢】
A：IAM Access Analyzer は、リソースベースのポリシーを分析して外部や意図しないプリンシパルに共有されているリソースを検出するサービスです。「その認証情報が何のリソースにアクセスしたか／誰が使ったか」という利用履歴の追跡は行いません(それは AWS CloudTrail の役割)。よって不正利用の特定手段として不適です。
C：Amazon GuardDuty は脅威を検出するサービスであり、特定のアクセスキーの使用をブロックする機能はありません。GuardDuty にそのようなルールを作ることはできません。
D：新しいアクセスキーを作成しても、漏洩した古いキーは有効なままで不正利用を止められず、また「不正利用が発生したかの特定」にもなりません。まず漏洩キーの無効化(B)が必要です。

【参考】
漏洩した可能性のあるアクセスキーへの対応 - IAM
IAM 認証情報レポートの取得
この問題のページを開く →
問題 7これらの要件を満たすソリューションはどれですか？データ保護
問題
ある会社が、AWS Organizations の組織に対して AWS Config を有効にしています。会社は組織全体で数百個の Amazon S3 バケットをデプロイしています。 セキュリティエンジニアは、AWS Key Management Service（AWS KMS）で暗号化されていない S3 バケットを特定する必要があります。さらに、AWS KMS で暗号化されていないオブジェクトが S3 バケットにアップロードされるのを防止する必要があります。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    s3-default-encryption-kms の AWS Config マネージドルールを使って暗号化されていない S3 バケットを特定する。SCP を作成し、オブジェクトが AWS KMS で暗号化されている場合にのみ s3:PutObject アクションを許可する。
  • 2
    s3-default-encryption-kms の AWS Config マネージドルールを使って暗号化されていない S3 バケットを特定する。各 S3 バケットにバケットポリシーを作成し、オブジェクトが SSE-S3（S3 管理キーによるサーバー側暗号化）の場合にのみ s3:PutObject を拒否する。
  • 3
    s3-bucket-ssl-requests-only の AWS Config マネージドルールを使って暗号化されていない S3 バケットを特定する。SCP を作成し、オブジェクトが AWS KMS で暗号化されている場合にのみ s3:PutObject アクションを許可する。
  • 4
    s3-bucket-ssl-requests-only の AWS Config マネージドルールを使って暗号化されていない S3 バケットを特定する。各 S3 バケットにバケットポリシーを作成し、オブジェクトが AWS KMS で暗号化されている場合にのみ s3:PutObject を許可する。

解説

【正解】A

【0からの解説】
要件は 2 つです。①KMS で暗号化されていない S3 バケットを「特定（検知）」する、②KMS 暗号化なしのオブジェクトのアップロードを「防止」する。

①特定 → s3-default-encryption-kms という AWS Config マネージドルールが、まさに「S3 バケットのデフォルト暗号化が KMS（SSE-KMS）になっているか」を評価してくれます。組織全体で Config が有効なので、KMS 未使用のバケットを一括で洗い出せます。

②防止 → AWS Organizations 環境なので、組織全体に横断的にガードレールをかけられる SCP（サービスコントロールポリシー）が適しています。s3:PutObject を「オブジェクトが KMS で暗号化される場合に限り許可」する条件（例: s3:x-amz-server-side-encryption が aws:kms）にすれば、KMS 暗号化なしのアップロードを組織全体で防げます。
「特定＝Config（s3-default-encryption-kms）」「防止＝SCP（KMS 必須）」の組み合わせである A が両要件を満たします。

【誤りの選択肢】
B：特定ルールは正しいものの、防止策が「SSE-S3 の場合に拒否」となっており、KMS 以外（例: 暗号化指定なし）を網羅できません。また各バケットに個別ポリシーを作るのは数百バケットでは運用負荷が高く、組織横断の強制には SCP が適切です。
C：s3-bucket-ssl-requests-only は「通信が SSL/HTTPS で行われているか（転送時暗号化）」を評価するルールで、バケットの保存時暗号化が KMS かどうかは判定しません。特定要件に合致しません。
D：同じく s3-bucket-ssl-requests-only は転送時暗号化用のルールで、KMS 保存時暗号化の特定には使えません。防止策の方向性は妥当でも、特定ルールが誤っています。

【参考】
s3-default-encryption-kms（AWS Config マネージドルール）
S3 のサーバー側暗号化を SCP で強制する例
この問題のページを開く →
問題 8これらの要件を満たすソリューションはどれですか？検出
問題
セキュリティエンジニアが、Amazon S3 バケット内のオブジェクトに関する詳細情報をキャプチャするロギングソリューションを実装する必要があります。このソリューションには、リクエストを行った IAM アイデンティティや、オブジェクトがアクセスされた時刻といった詳細が含まれている必要があります。データは構造化されており、ほぼリアルタイムで利用できる必要があります。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    S3 バケットで Amazon S3 サーバーアクセスログを有効にする。ログを保存する新しい S3 バケットを作成し、そのバケットからログを分析する。
  • ✓
    AWS CloudTrail のデータイベントログを有効にする。ログを保存する新しい S3 バケットを作成し、そのバケットからログを分析する。
  • 3
    S3 バケットに保存されたオブジェクトへのアクセスをログに記録するよう AWS Config ルールを設定する。
  • 4
    Amazon Macie を有効にして、S3 バケットに保存されたオブジェクトへのアクセスをログに記録する。

解説

【正解】B

【0からの解説】
要件は「①リクエストを行った IAM アイデンティティ ②アクセス時刻 ③構造化データ ④ほぼリアルタイム」でオブジェクトレベルのアクセスを記録することです。

これに最も合致するのが AWS CloudTrail のデータイベント（data events）です。CloudTrail のデータイベントを S3 に対して有効にすると、GetObject や PutObject などのオブジェクトレベルの API 操作を記録できます。CloudTrail のレコードには、誰が（userIdentity = IAM アイデンティティ）、いつ（eventTime）、何を、どこから行ったかが JSON 形式（構造化データ）で含まれ、配信はほぼリアルタイムです。これで①〜④すべてを満たします。

【誤りの選択肢】
A：S3 サーバーアクセスログもオブジェクトアクセスを記録できますが、形式はスペース区切りのテキスト（CloudTrail ほど構造化されていない）で、配信はベストエフォートで遅延があり「ほぼリアルタイム」ではありません。また IAM アイデンティティの詳細さでも CloudTrail に劣ります。
C：AWS Config はリソースの「設定（構成）」の変化を追跡・評価するサービスで、オブジェクトへの個々のアクセス（誰がいつ読んだか）を記録する用途ではありません。要件に合いません。
D：Amazon Macie は機密データの「分類・検出」を行うサービスで、オブジェクトへのアクセスログを取るサービスではありません。要件の用途が異なります。

【参考】
CloudTrail で S3 のデータイベントをログ記録する
CloudTrail のデータイベント
この問題のページを開く →
問題 9セキュリティエンジニアがこの問題をトラブルシューティングするために最初に取るべきステップはどれですか？セキュリティの基盤とガバナンス
問題
ある会社が AWS Organizations を使って、Production、Development、Testing の 3 つのワークロード OU から成る組織を管理しています。会社は AWS CloudFormation テンプレートを使って、これらの OU に属する AWS アカウント内のワークロードインフラを定義・デプロイしています。各ワークロード OU には、それぞれ異なる SCP がアタッチされています。 会社は、Development OU と Testing OU のワークロードに対して CloudFormation スタックの更新を正常にデプロイできました。しかし、同じ CloudFormation テンプレートを使って Production OU 内のアカウントでスタック更新をデプロイしようとすると、更新が失敗します。エラーメッセージは IAM 権限が不足していることを報告しています。 セキュリティエンジニアがこの問題をトラブルシューティングするために最初に取るべきステップはどれですか？

選択肢と解説

  • ✓
    Production OU 内アカウントの AWS CloudTrail ログを確認する。デプロイ試行中の CloudFormation からの失敗した API 呼び出しを探す。
  • 2
    Production OU にアタッチされているすべての SCP を削除し、CloudFormation スタック更新を再実行して、SCP が CloudFormation の API 呼び出しを妨げていたかどうかを判断する。
  • 3
    CloudFormation が使用するロールが、テンプレートで参照されているリソースを作成・更新・削除するのに十分な権限を持っているか確認する。
  • 4
    Production OU にアタッチされている SCP を、すべて Testing OU にアタッチされている SCP と同じものにする。

解説

【正解】A

【0からの解説】
問われているのは「最初（FIRST）に取るべきトラブルシューティングのステップ」です。トラブルシュートの基本は、いきなり構成を変更するのではなく、まず事実（どの API がなぜ失敗したか）を調べて根本原因を切り分けることです。

同じテンプレートが Development／Testing では成功し Production だけ失敗していること、エラーが「IAM 権限不足」であることから、原因は Production 固有の権限要因（SCP による拒否、または CloudFormation 実行ロールの権限不足）のどちらかと推測できます。これを切り分けるには、AWS CloudTrail ログを確認し、どの API 呼び出しが・どのプリンシパルで・どんな理由（明示的 Deny など）で失敗したかを見るのが最短かつ安全な第一歩です。CloudTrail のエラーメッセージには SCP による拒否か IAM 権限不足かを判別する手がかり（errorCode/errorMessage）が含まれます。

【誤りの選択肢】
B：原因確認の前に本番（Production）の SCP をすべて削除するのは、セキュリティガードレールを外す危険な操作で、本番環境では特に避けるべきです。「最初のステップ」として不適切です。
C：実行ロールの権限確認は有効な調査ですが、原因が SCP の拒否である可能性も同等にあります。まず CloudTrail で「どの API がなぜ失敗したか」を見れば、ロール権限の問題か SCP の問題かを一度に切り分けられるため、A の方が「最初の」ステップとして適切です。
D：Production の SCP を Testing と同じにするのは、確認前にガードレールを弱める変更であり、根本原因の特定にもなりません。本番のセキュリティ要件を損なうため不適切です。

【参考】
CloudTrail を使ったトラブルシューティング
SCP の評価とトラブルシューティング
この問題のページを開く →
問題 10これらの要件を満たすソリューションはどれですか？インフラストラクチャセキュリティ
問題
セキュリティエンジニアが、VPC 内で動作するパブリック Web アプリケーションを保護する必要があります。この VPC は Amazon CloudFront ディストリビューションのオリジンをホストしています。このアプリケーションは、複数回のレイヤー 7（L7）DDoS 攻撃を受けてきました。CloudFront ディストリビューションには AWS WAF の Web ACL が関連付けられており、その Web ACL には、評判の悪い既知の IP アドレスから保護するための AWS マネージドルールが 1 つ含まれています。 セキュリティエンジニアは、手作業なしで、レイヤー 7 DDoS 攻撃をリアルタイムに検出して緩和する自動化されたソリューションを構成する必要があります。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    CloudFront ディストリビューションで AWS Shield Advanced を有効にする。DDoS の兆候について Amazon CloudWatch でアラートを設定する。
  • 2
    AWS Shield Advanced を有効にし、AWS DDoS レスポンスチームとのプロアクティブエンゲージメントを設定する。
  • 3
    VPC に AWS Network Firewall をデプロイする。DDoS の兆候を検出するセキュリティポリシーを作成する。攻撃中に Web ACL ルールを自動更新する AWS Lambda 関数を作成する。
  • ✓
    Web ACL にレートベースルールを追加する。AWS Shield Advanced を有効にする。CloudFront ディストリビューションでアプリケーションレイヤーの自動 DDoS 緩和（automatic application layer DDoS mitigation）を有効にする。

解説

【正解】D

【0からの解説】
キーワードは「レイヤー 7（アプリケーション層）」「リアルタイム」「手作業なしの自動緩和」です。

L7 DDoS（HTTP フラッドなど）への対策は AWS WAF が中心になります。
・レートベースルール：一定時間に多数のリクエストを送ってくる送信元 IP を自動でブロックでき、HTTP フラッド緩和の基本です。
・AWS Shield Advanced：CloudFront などのエッジリソースに対する高度な DDoS 保護を提供します。
・自動アプリケーションレイヤー DDoS 緩和（automatic application layer DDoS mitigation）：Shield Advanced の機能で、保護対象に関連付けた WAF Web ACL に対し、L7 攻撃を検出すると Shield が自動で WAF ルールを作成・適用して緩和します。まさに「手作業なしでリアルタイムに検出・緩和」という要件に直結します。
この 3 つを組み合わせる D が、L7 DDoS の自動検出・自動緩和を実現する最適解です。

【誤りの選択肢】
A：Shield Advanced を有効化して CloudWatch でアラートを出すだけでは「検知・通知」にとどまり、自動的な緩和（mitigation）は行われません。「手作業なしの緩和」という要件を満たしません。
B：プロアクティブエンゲージメント（DRT との連携）は、AWS の専門チームが対応を支援する仕組みで人手を介する運用です。「手作業なしの自動緩和をリアルタイムに」という要件には合致しません。
C：AWS Network Firewall はネットワーク層／トラフィック制御向けで、CloudFront 前段の L7 HTTP フラッド緩和の主役ではありません。さらに Lambda で Web ACL を自作更新する設計は複雑で、Shield Advanced の自動 L7 緩和という標準機能があるのに比べて不適切です。

【参考】
Shield Advanced のアプリケーションレイヤー自動 DDoS 緩和
AWS WAF のレートベースルール
この問題のページを開く →
問題 11この要件を満たすソリューションはどれですか。アイデンティティおよびアクセス管理
問題
ある企業は AWS Organizations の組織を使用して複数の AWS アカウントを管理しています。ユーザーは IAM ユーザーとシークレットアクセスキーを使用して各 AWS アカウントにアクセスしています。セキュリティチームは、アカウントへのすべてのアクセスについて、60 分後に失効する一時的なセキュリティ認証情報を使用することを要求しています。ユーザーは、SAML ベースの ID プロバイダー (IdP) を使用してアカウントにアクセスしなければなりません。 この要件を満たすソリューションはどれですか。

選択肢と解説

  • 1
    AWS Security Token Service (AWS STS) へのアクセスを有効化する。ユーザーが適切な有効期間を指定して get-session-token AWS CLI コマンドを実行するようにする。ユーザーに STS の一時認証情報を使用して AWS アカウントにアクセスさせる。
  • ✓
    AWS IAM Identity Center をセットアップし、外部 IdP を構成する。ユーザーに必要なアクセスを許可する許可セットを構成する。セッションの有効期間の上限を構成する。ユーザーには AWS CLI を使用して SSO 認証情報を取得させる。AWS アカウントから IAM ユーザーを削除する。
  • 3
    各 AWS アカウントに AWS Secrets Manager と Amazon Cognito をセットアップする。Cognito の ID プールが外部 IdP を使用し Secrets Manager に接続するように構成する。Secrets Manager でマネージドなシークレットローテーションを有効化する。ユーザーが get-secret-value AWS CLI コマンドを実行して AWS アカウントにアクセスするようにする。
  • 4
    組織の管理アカウントで AWS IAM Roles Anywhere を有効化する。ユーザーが認証情報ヘルパーツールをインストールするようにする。管理アカウント内に適切なセッション有効期間を持つ IAM ロールを構成する。ユーザーが認証情報ヘルパーツールから一時認証情報を取得して AWS アカウントにアクセスするようにする。

解説

【正解】B

【0からの解説】
この問題のキーワードは「複数アカウントの一元管理」「SAML ベースの IdP でのフェデレーション」「60 分で失効する一時認証情報」「永続的な IAM ユーザー/アクセスキーをやめる」の 4 つです。
AWS IAM Identity Center（旧 AWS SSO）は、まさにこのユースケースのために設計されたサービスです。外部の SAML 2.0 / OIDC ベースの IdP（Okta、Azure AD/Entra ID など）と連携でき、組織内の各アカウントへ「許可セット」という形でアクセスを割り当てられます。ユーザーは IdP で 1 度ログインすれば、各アカウント用の一時認証情報（STS 経由）が自動で発行され、セッション有効期間（例: 1 時間）を中央で強制できます。AWS CLI でも `aws configure sso` により SSO 認証情報を取得できます。さらに各アカウントから永続的な IAM ユーザーとアクセスキーを削除すれば「すべてのアクセスを一時認証情報に統一」という要件も満たせます。
したがって B がすべての要件を 1 つの仕組みで満たす最適解です。

【誤りの選択肢】
A：get-session-token はあくまで既存の IAM ユーザー（長期のアクセスキー）を前提に一時トークンを発行するもので、SAML IdP によるフェデレーションを実現しません。また永続的な IAM ユーザー/キーが残り続け、要件「SAML ベースの IdP を使う」「IAM ユーザーを廃止する」を満たしません。
C：Cognito はモバイル/ウェブアプリのエンドユーザー向け ID 連携サービスであり、開発者/運用者が AWS アカウントの管理コンソールや CLI にアクセスする用途には適しません。Secrets Manager にシークレットを格納する発想自体が「一時認証情報への統一」という方針に反します。
D：IAM Roles Anywhere は、AWS の外（オンプレミスサーバーや CI など）の「ワークロード」が X.509 証明書を使って一時認証情報を得る仕組みであり、SAML IdP による「人間ユーザー」のフェデレーションには適しません。

【参考】
AWS IAM Identity Center とは
許可セット（Permission sets）
外部 IdP への接続
この問題のページを開く →
問題 12この要件を満たすソリューションはどれですか。アイデンティティおよびアクセス管理
問題
ある企業はオンプレミスのレガシーシステムと AWS 上のリソースの両方を運用しています。AWS リソースには Amazon DynamoDB テーブルと Amazon S3 バケットが含まれます。オンプレミスのレガシーシステムは DynamoDB と Amazon S3 に定期的に接続する必要があります。 現在、企業は VPC のパブリックサブネットにあるバスティオンホストを使用しています。企業はオンプレミスに保存した SSH 秘密鍵を使用してバスティオンホストに接続しています。バスティオンホストに割り当てられたインスタンスプロファイルは Amazon S3 と DynamoDB へのフルアクセスを持っています。 セキュリティチームは、すべてのバスティオンホストを廃止することを求める新しい社内ポリシーを発行しました。このポリシーは、すべてのシステムが証明書ベースの認証を使用して認証することを求めています。 この要件を満たすソリューションはどれですか。

選択肢と解説

  • 1
    AWS Direct Connect 接続をセットアップし、必要なサービスの VPC エンドポイントにアクセスできる VPC への VPN 接続を作成する。
  • ✓
    オンプレミスシステムが AWS IAM Roles Anywhere を使用して認証するようにセットアップする。
  • 3
    AWS Private Certificate Authority を使用して SSL 証明書を発行し、オンプレミスシステムに AWS 上のリソースへのアクセスを与える。
  • 4
    IAM ロールを一時的に引き受ける権限と、一時的に引き受けたロールの認証情報を使用して必要なリソースにアクセスする権限を持つ IAM ユーザーを作成する。

解説

【正解】B

【0からの解説】
要件は (1) バスティオンホストを廃止する、(2) 証明書ベースの認証で AWS リソース（S3 / DynamoDB）にアクセスする、の 2 点です。
AWS IAM Roles Anywhere は、AWS の外にあるサーバーやワークロード（オンプレミスのレガシーシステムなど）に対して、X.509 証明書を使って AWS の一時的なセキュリティ認証情報を取得させる仕組みです。信頼アンカー（プライベート認証局や AWS Private CA）を登録し、プロファイルとロールを構成すると、オンプレミス側の「認証情報ヘルパー（credential helper）」が証明書で署名したリクエストを送り、AWS STS から一時認証情報を受け取ります。これにより、長期のアクセスキーや SSH 鍵、バスティオンホストを一切使わずに、証明書ベースで S3/DynamoDB に直接アクセスできます。要件に完全に合致するため B が正解です。

【誤りの選択肢】
A：Direct Connect と VPN はネットワーク経路（接続性）を提供するだけで、「証明書ベースの認証」という認証要件そのものを満たしません。また依然として何らかの AWS 認証情報が別途必要です。
C：AWS Private CA は証明書を発行できますが、それ単体ではオンプレミスシステムが S3/DynamoDB の API を呼び出すための AWS 認証情報（IAM 権限）にはなりません。発行した証明書を使って実際に AWS の一時認証情報へ変換する仕組みこそが IAM Roles Anywhere であり、Private CA はその「信頼アンカー」として併用されるにすぎません。
D：IAM ユーザー＋AssumeRole は一時認証情報を得られますが、その起点となる IAM ユーザーの長期アクセスキーが必要であり、「証明書ベースの認証」という要件を満たしません。

【参考】
AWS IAM Roles Anywhere とは
認証情報の取得（credential helper）
この問題のページを開く →
問題 13この要件を満たすソリューションはどれですか。検出
問題
ある企業は新しいログ分析環境を導入しようとしています。複数の AWS サービスのログをほぼリアルタイムで分析するソリューションを実装する必要があります。このソリューションはログを検索できる機能を提供しなければなりません。また、特定のログが検出ルールに一致したときに、既存の Amazon Simple Notification Service (Amazon SNS) トピックにアラートを送信しなければなりません。 この要件を満たすソリューションはどれですか。

選択肢と解説

  • ✓
    Amazon OpenSearch Service を使用してログを分析する。OpenSearch API からログを検索する。OpenSearch Service の Security Analytics を使用してログを検出ルールと照合し、SNS トピックにアラートを送信する。
  • 2
    AWS Security Hub を使用してログを分析する。Security Hub の検出結果（Findings）ページからログを検索する。カスタムアクションを作成してログを検出ルールと照合し、SNS トピックにアラートを送信する。
  • 3
    Amazon CloudWatch Logs を使用してログを分析する。サブスクリプションフィルターを使用してログを検出ルールと照合し、SNS トピックにアラートを送信する。CloudWatch Logs Insights を使用して手動でログを検索する。
  • 4
    Amazon QuickSight を使用してログを分析する。ダッシュボードにクエリ結果を一覧表示してログを検索する。クエリを実行してログを検出ルールと照合し、SNS トピックにアラートを送信する。

解説

【正解】A

【0からの解説】
要件を整理すると、(1) 複数 AWS サービスのログをほぼリアルタイムで分析、(2) ログを検索できる、(3) 検出ルールに一致したら SNS にアラート、の 3 点です。
Amazon OpenSearch Service は、大量のログを取り込んで全文検索・分析できるサービスで、(2) の「検索」を強力にサポートします。さらに OpenSearch には Security Analytics 機能があり、業界標準の Sigma 形式の検出ルール（CloudTrail、DNS、VPC Flow Logs、Windows など多数のログタイプに対応）を使ってほぼリアルタイムでログを照合し、ルールに一致すると「アラート」を生成して通知先（Amazon SNS や Amazon Chime など）に送信できます。3 つの要件をすべて 1 つのサービスで満たすため A が正解です。

【誤りの選択肢】
B：Security Hub はセキュリティ検出結果を集約・標準化するサービスであり、「生ログを取り込んで全文検索する」ログ分析プラットフォームではありません。Findings ページは検索に特化したログ分析環境とは言えず、要件に合いません。
C：CloudWatch Logs のサブスクリプションフィルターはパターンに一致したログを別サービス（Kinesis や Lambda）にストリーミングする仕組みで、SNS へ直接「アラート送信」する用途には設計されていません（通常はメトリクスフィルター＋CloudWatch アラームを使う）。また Logs Insights の検索は OpenSearch のような検出ルール照合＋アラートの統合体験を提供しません。
D：QuickSight は BI（可視化・ダッシュボード）ツールであり、検出ルールへの照合やアラート送信を行うセキュリティ分析基盤ではありません。

【参考】
Security Analytics for Amazon OpenSearch Service
Amazon OpenSearch Service とは
この問題のページを開く →
問題 14対象インスタンスを隔離するためにセキュリティエンジニアは何をすべきですか。インシデント対応
問題
ある企業のセキュリティエンジニアは、インシデント対応計画の一環として Amazon EC2 インスタンスの隔離手順を設計しています。セキュリティエンジニアは、対象インスタンスを隔離して、企業のフォレンジックチームからのトラフィックを除き、対象インスタンスへの/からのすべてのトラフィックをブロックする必要があります。企業の各 EC2 インスタンスには、それぞれ専用のセキュリティグループがあります。EC2 インスタンスは VPC のサブネットにデプロイされています。1 つのサブネットには複数のインスタンスを含めることができます。 セキュリティエンジニアは EC2 隔離の手順をテストしており、対象インスタンスへの SSH セッションを開きます。手順は攻撃者による対象インスタンスへのアクセスをシミュレートし始めます。セキュリティエンジニアは既存のセキュリティグループのルールを削除し、フォレンジックチームがポート 22 で対象インスタンスにアクセスできるようにするセキュリティグループルールを追加します。 これらの変更後、セキュリティエンジニアは SSH 接続が依然としてアクティブで使用可能なことに気づきます。セキュリティエンジニアが対象インスタンスのパブリック IP アドレスに対して ping コマンドを実行すると、ping コマンドはブロックされます。 対象インスタンスを隔離するためにセキュリティエンジニアは何をすべきですか。

選択肢と解説

  • 1
    セキュリティグループに、すべてのポートで 0.0.0.0/0 からのトラフィックを許可するインバウンドルールを追加する。すべてのポートで 0.0.0.0/0 へのトラフィックを許可するアウトバウンドルールを追加する。その後、これらのルールを直ちに削除する。
  • 2
    ポート 22 のセキュリティグループルールを削除する。フォレンジックチームが対象インスタンスにアクセスできるよう、AWS Systems Manager Session Manager 接続を許可するインスタンスロールポリシーをアタッチする。
  • ✓
    対象インスタンスのサブネットに関連付けられたネットワーク ACL を作成する。インバウンドルールセットの先頭に、0.0.0.0/0 からのすべてのトラフィックを拒否するルールを追加する。アウトバウンドルールセットの先頭に、0.0.0.0/0 へのすべてのトラフィックを拒否するルールを追加する。
  • 4
    すべてのインバウンドトラフィックとアウトバウンドトラフィックをブロックするホストレベルのファイアウォールルールを追加する AWS Systems Manager ドキュメントを作成する。対象インスタンスでそのドキュメントを実行する。

解説

【正解】C

【0からの解説】
この問題の核心は「セキュリティグループはステートフル、ネットワーク ACL (NACL) はステートレス」という違いです。
セキュリティグループはステートフルなため、いったん確立された接続（既存の SSH セッション）は、ルールを後から削除しても切断されません。インバウンド/アウトバウンドのルールは「新規の接続」にしか効かないからです。だからこそセキュリティエンジニアが SG ルールを差し替えても、攻撃者役の既存 SSH セッションは生きたまま残ったのです（ping=新規 ICMP は SG で正しくブロックされた）。
これに対し NACL はステートレスで、サブネット境界を通過するパケットを 1 つ 1 つ評価します。NACL の先頭（番号の小さい順に評価され最初に一致したルールが適用）に「すべて拒否」を置くと、確立済みのセッションを含めてすべてのパケットが落ち、既存の SSH 接続も切断されます。これにより攻撃者役の接続を確実に断ち切れます。フォレンジックチーム用のアクセスは、NACL に許可ルールを別途追加する（フォレンジック IP のみ許可するルールを拒否ルールより前に置く）ことで実現できます。よって既存セッションを断つには C が正解です。

【誤りの選択肢】
A：一瞬すべてを許可してから削除しても、ステートフルな SG では既存セッションを切る効果はなく、むしろ攻撃者に追加の通信機会を与えるだけで逆効果です。
B：Session Manager の話はフォレンジック側のアクセス手段にすぎず、すでに確立されている攻撃者の SSH セッションを切断しません。隔離（既存接続の遮断）という目的を達成しません。
D：ホストレベルのファイアウォールを SSM ドキュメントで設定する案は、(1) 侵害された（攻撃者が制御し得る）OS 上で防御を構成する点で信頼性が低く、(2) 設定が反映されるまでのタイムラグや SSM エージェントの正常動作に依存します。VPC レイヤーで確実に遮断する NACL の方がインシデント隔離として適切です。

【参考】
ネットワーク ACL（ステートレス）
セキュリティグループ（ステートフル）
EC2 インスタンスの自動隔離（インシデント対応）
この問題のページを開く →
問題 15このソリューションを実装する最も効率的な方法はどれですか。セキュリティの基盤とガバナンス
問題
あるセキュリティエンジニアは、AWS CloudTrail が万一オフにされた場合に、複数の AWS リージョンで CloudTrail を再びオンに戻すソリューションを構築する必要があります。 このソリューションを実装する最も効率的な方法はどれですか。

選択肢と解説

  • ✓
    AWS Config のマネージドルールを使用して、AWS-EnableCloudTrail の修復（remediation）を開始する。
  • 2
    cloudtrail.amazonaws.com のイベントソースと StartLogging イベント名を持つ Amazon EventBridge イベントを作成し、AWS Lambda 関数を呼び出して StartLogging API を呼ぶ。
  • 3
    cloudtrail.amazonaws.com のイベントソースと StopLogging イベント名を持つ Amazon CloudWatch アラームを作成し、AWS Lambda 関数を呼び出して StartLogging API を呼ぶ。
  • 4
    AWS Trusted Advisor を監視して CloudTrail のロギングが有効であることを確認する。

解説

【正解】A

【0からの解説】
「最も効率的（MOST efficient）」という言葉がポイントです。AWS Config には `cloudtrail-enabled`（および `multi-region-cloudtrail-enabled` など）のマネージドルールがあり、CloudTrail が無効化された状態を「非準拠」として検知できます。さらに AWS Config の自動修復（remediation）には、SSM のマネージドオートメーションドキュメント `AWS-EnableCloudTrail` を割り当てられ、非準拠を検知すると自動で CloudTrail を再有効化します。コードを書く必要がなく、検知から修復までをマネージド機能だけで完結できるため、最も効率的な実装です。よって A が正解です。

【誤りの選択肢】
B：EventBridge ＋ 自前の Lambda 関数で StartLogging を呼ぶ方法でも実現は可能ですが、Lambda コードの開発・保守が必要で、A のマネージド修復よりも手間がかかり「最も効率的」ではありません。なお StartLogging はロギングを「開始」するイベントなので、トリガーにすべきは無効化＝StopLogging です。
C：CloudWatch アラームはメトリクスのしきい値超過に対して発火するもので、「StopLogging という API イベント」を直接トリガーにはできません（それは EventBridge/CloudTrail の役割）。仕組みとして誤りです。
D：Trusted Advisor は推奨事項を提示するだけで、CloudTrail を自動的に再有効化する仕組みを持ちません。監視だけでは「再びオンに戻す」要件を満たしません。

【参考】
AWS Config マネージドルール: cloudtrail-enabled
AWS Config による自動修復
この問題のページを開く →

SCS-C03 模擬問題集についてよくある質問

SCS-C03 の練習問題は無料で試せますか？

はい。SCS-C03 は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン（月額 ¥980）または Pro プラン（月額 ¥4,980）でご利用ください。

問題は何問ありますか？

SCS-C03 は本番形式の練習テスト 2 回・全 100 問を収録しています。全問に解説が付いています。

解説は付いていますか？

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン（出題分野）別の正答率も受験後に確認できます。