以下はご指定の形式に従った出力です。
■ 問題文（文字列を編集せずに出力してください。）
セキュリティエンジニアは、ユーザーがキーに直接触れることなく Amazon S3 オブジェクトをシームレスに暗号化できるソリューションを実装しています。このソリューションは、継続的な管理を必要とせず、高度にスケーラブルである必要があります。さらに、組織は暗号化キーを即座に削除できる必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（文字列を編集せずに出力してください。）
A. AWS CloudHSM を使用してキーを保存し、必要に応じて CloudHSM API または PKCS11 ライブラリを使用してキーを削除します。
B. AWS がインポートしたキーマテリアルで KMS を使用し、必要に応じて DeleteImportedKeyMaterial API を使用してキーマテリアルを削除します。
C. Systems Manager Parameter Store を使用してキーを保存し、必要に応じてサービス API オペレーションを使用してキーを削除します。
D. AWS マネージドキーで AWS KMS を使用し、PendingWindowInDays を 0 に設定した ScheduleKeyDeletion API を使用して、必要に応じてキーを削除します。
■ 問題文の要件の概要
- ユーザーがキーに触れる必要がない（キー管理の抽象化）
- Amazon S3 オブジェクトの暗号化（S3との連携）
- 継続的な管理が不要（自動管理・省力化）
- 高スケーラビリティ（大規模対応）
- 暗号化キーを即時に削除できること
■ 正解の選択肢と解説
正解：B
AWS がインポートしたキーマテリアルで KMS を使用し、必要に応じて DeleteImportedKeyMaterial API を使用してキーマテリアルを削除します。
解説：
AWS KMS で外部からインポートしたキーマテリアルを使用することで、暗号化キーをAWSに直接保存せずにS3暗号化を実現できます。DeleteImportedKeyMaterial API を使用すれば、即座にキーマテリアルを削除可能です。
この方法ではキーが削除されてもKMSキーID自体は残りますが、キーマテリアルが無効化されるため暗号化操作ができなくなります。加えて、KMSはフルマネージドかつ高スケーラブルなサービスであるため、「継続的な管理不要」「スケーラビリティ」の要件にも適合します。
■ 不正解の選択肢の理由
A. AWS CloudHSM を使用してキーを保存し…
→ CloudHSM はハードウェアベースのキー管理であり、インフラ管理や専用設定が必要です。「継続的な管理が不要」という要件を満たしません。また、CloudHSMはスケーラブルではなく、高度な管理負荷があります。
C. Systems Manager Parameter Store を使用してキーを保存し…
→ Parameter Store はセキュアなパラメータの保管には有用ですが、暗号化専用の設計ではなく、S3オブジェクトのシームレスな暗号化や即時削除の仕組みを持ちません。スケーラビリティや即時性にも課題があります。
D. AWS マネージドキーで KMS を使用し…
→ ScheduleKeyDeletion はキー削除の予約操作であり、PendingWindowInDays に最小でも7日の待機期間が必要です。即時削除の要件を満たさず不適です。
■ SCS試験で押さえておくべきポイント
- KMSのインポートキーマテリアルでは
DeleteImportedKeyMaterialAPIを用いて即時削除が可能であること。 - KMSの通常のキー削除（ScheduleKeyDeletion）では最短7日待機が必要であり、即時削除はできないこと。
- CloudHSMはフルマネージドではなく、継続的な運用管理が必要なため、KMSと比較してスケーラビリティや利便性で劣る。
- Parameter Storeは暗号化キーの保管用ではない。KMSやCloudHSMとは異なる用途。
- 「即時削除」「スケーラビリティ」「キーに直接触れない」といった要件に基づいた設計判断が求められる。
次の問題も同じ形式で対応いたしますので、続けてHTMLをお送りください。
以下はご指定の形式に沿った「問題2」の詳細な解説です。
■ 問題文（文字列を編集せずに出力してください。）
ある会社が新しい Software as a Service (SaaS) アプリケーションをリリースしました。rdsstorage-encrypted AWS Config マネージドルールは、コンプライアンスに準拠していないリソースについて、会社のセキュリティチームに通知するアラートを生成します。非準拠のリソースは、新しくリリースされたアプリケーションの一部としてデプロイされた Amazon RDS for MySQL データベースです。
エンドユーザーのアプリケーションの可用性への影響を最小限に抑えながら、コンプライアンス違反をどのように解決する最適な方法を選択してください。
■ 選択肢（文字列を編集せずに出力してください。）
A. アプリケーションにパッチを導入し、非準拠のデータベースへの書き込みを停止します。AWS CLI を使用してストレージの暗号化を有効にします。アプリケーションに再度パッチを適用して、データベースへの書き込みを復元します。
B. 非準拠の DB インスタンスにリードレプリカを追加します。リードレプリカでストレージの暗号化を有効にします。リードレプリカが利用可能になったら、ライター DB インスタンスからリードレプリカにカットオーバーします。カットオーバー後に暗号化されていない DB インスタンスを削除します。
C. 非準拠の DB インスタンスのスナップショットを作成します。暗号化が設定された同じ AWS リージョンでスナップショットのコピーを作成します。スナップショットを新しい DB インスタンスとしてリストアします。アプリケーションエンドポイントを、新しく復元されたデータベースにカットオーバーします。
D. AWS Database Migration Service (AWS DMS) を使用して、フルロードと変更データキャプチャ (CDC) を、非準拠データベースとストレージを暗号化した新しいデータベース間で使用します。フルロードが終了したら、新しい暗号化されたデータベースへのすべてのアプリケーションエンドポイントをカットオーバーします。
■ 問題文の要件の概要
- 新しい SaaS アプリで使用している RDS for MySQL が暗号化されていない
- AWS Config のルール
rdsstorage-encryptedに違反 - 可用性（ダウンタイム）への影響を最小限に抑えたい
- したがって、暗号化状態に是正する方法で 可用性が高い方法 を選ぶ必要がある
■ 正解の選択肢と解説
正解：D
AWS Database Migration Service (AWS DMS) を使用して、フルロードと変更データキャプチャ (CDC) を、非準拠データベースとストレージを暗号化した新しいデータベース間で使用します。フルロードが終了したら、新しい暗号化されたデータベースへのすべてのアプリケーションエンドポイントをカットオーバーします。
解説：
AWS DMS を使えば、暗号化されていない RDS から新しい暗号化された RDS にデータを移行しつつ、**変更データキャプチャ（CDC）**によってリアルタイムで変更も追跡・同期できます。
この方法は、フルロード中も旧DBが使えるためダウンタイムが最小限で済み、要件に最も合致します。最終的にエンドポイントを切り替えれば、暗号化された新DBにスムーズに移行できます。
■ 不正解の選択肢の理由
A.
「AWS CLI を使用してストレージの暗号化を有効にします」
→ 既存の RDS インスタンスに後から暗号化を有効化することは不可能です。RDS のストレージ暗号化はインスタンス作成時にのみ設定できます。
B.
「リードレプリカを追加し、暗号化を有効にする」
→ 暗号化されていない RDS から暗号化されたリードレプリカを作成することはできません。リードレプリカはマスターの暗号化状態を継承します。
C.
「スナップショットを暗号化してリストアする」
→ 技術的には可能ですが、スナップショットの作成やリストアにかかる時間＝ダウンタイムが発生するため、「可用性への影響を最小限に」という要件に適していません。
■ SCS試験で押さえておくべきポイント
- RDS ストレージ暗号化は作成時のみ有効化可能で、既存のインスタンスには後付け不可
- DMS（Database Migration Service）は、フルロード＋CDCによりダウンタイムを最小限にしてDBを移行可能
- 暗号化の継承制限：
- 非暗号化 RDS → 暗号化リードレプリカ ❌ 不可
- 暗号化スナップショットからの新規復元 ✅ 可
- 可用性の観点が問われる問題では「リアルタイム同期」「段階的移行」などを意識する
次の問題があれば、引き続きご提供ください。逐次この形式で解析いたします。
以下はご指定の形式に従った「問題3」の解説です。
■ 問題文（文字列を編集せずに出力してください。）
ある会社は、AWS CodeDeploy を使用して、VPC 内の複数の Amazon EC2 インスタンスに同時にコードをデプロイすることを計画しています。会社は、CodeDeploy API 操作のためにパブリックなインターネットを介さずに、CodeDeploy サービスが VPC 内のインスタンスと通信できるようにする必要があります。
この要件を満たす最適な方法を選択してください。
■ 選択肢（文字列を編集せずに出力してください。）
A. CodeDeploy API 操作にゲートウェイ VPC エンドポイントを使用します。
B. VPC で NAT ゲートウェイを使用します。
C. CodeDeploy API 操作にインターフェース VPC エンドポイントを使用します。
D. VPC への VPN 接続を使用します。
■ 問題文の要件の概要
- VPC 内の EC2 に AWS CodeDeploy でコードを配信したい
- インターネットを経由せずに CodeDeploy API と通信したい
- つまり、プライベートネットワーク内で CodeDeploy の API 呼び出しを行う必要がある
■ 正解の選択肢と解説
正解：C
CodeDeploy API 操作にインターフェース VPC エンドポイントを使用します。
解説：
インターフェース型の VPC エンドポイント（AWS PrivateLink） は、VPC と AWS のサービス間のプライベート接続を提供します。
CodeDeploy はインターフェースエンドポイントに対応しており、これを使用することで インターネットを経由せずに VPC 内のインスタンスから CodeDeploy API にアクセス可能です。
この仕組みを利用すれば、VPC に NAT ゲートウェイやインターネットゲートウェイを追加することなく、安全に API 操作が実行できます。
■ 不正解の選択肢の理由
A. ゲートウェイ VPC エンドポイントを使用する
→ S3 と DynamoDB 専用です。CodeDeploy などの多くの AWS サービスには使えません。
B. NAT ゲートウェイを使用する
→ これにより VPC 内のインスタンスがインターネットに出て CodeDeploy API にアクセスできますが、インターネット経由での通信になるため要件を満たさない。
D. VPN 接続を使用する
→ VPN 接続は オンプレミスネットワークと VPC をつなぐための手段です。CodeDeploy API との通信には無関係であり不適切です。
■ SCS試験で押さえておくべきポイント
- **インターフェース VPC エンドポイント（PrivateLink）**は、S3/DynamoDB以外のAWSサービス（CodeDeploy、KMS、SSMなど）にプライベートアクセスするために使う
- ゲートウェイエンドポイントは S3 / DynamoDB 専用
- NAT ゲートウェイを使うと通信はインターネット経由になるので、セキュリティやプライベートアクセスの要件には適さない
- AWS の各種サービスがどのエンドポイントタイプに対応しているかは試験で頻出する
次の問題も対応可能ですので、続けてHTMLを貼り付けてください。
以下はご指定の形式に従った「問題4」の解説です。
■ 問題文（文字列を編集せずに出力してください。）
企業のオンプレミスネットワークは、AWS Direct Connect ゲートウェイを使用して VPC に接続されています。同社のオンプレミスアプリケーションは、既存の Amazon Kinesis Data Firehose 配信ストリームを使用してデータをストリーミングする必要があります。同社のセキュリティポリシーでは、プライベートネットワークを使用して転送中にデータを暗号化する必要があります。
これらの要件を満たす最適な方法を選択してください。
■ 選択肢（文字列を編集せずに出力してください。）
A. AWS Certificate Manager (ACM) で新しい TLS 証明書を作成します。パブリック向けの Network Load Balancer (NLB) を作成し、新しく作成した TLS 証明書を選択します。すべてのトラフィックを Kinesis Data Firehose に転送するように NLB を設定します。NLB に接続するようにアプリケーションを構成します。
B. Kinesis Data Firehose の VPC エンドポイントを作成します。VPC エンドポイントに接続するようにアプリケーションを構成します。
C. IAM ポリシーを設定して、送信元 IP 条件を使用して Kinesis Data Firehose へのアクセスを制限します。既存の Firehose 配信ストリームに接続するようにアプリケーションを構成します。
D. Direct Connect を使用して、オンプレミスネットワークを Kinesis Data Firehose VPC とピアリングします。既存の Firehose 配信ストリームに接続するようにアプリケーションを構成します。
■ 問題文の要件の概要
- オンプレミスアプリが Kinesis Data Firehose にアクセスしたい
- すでに Direct Connect ゲートウェイで VPC に接続済み
- プライベートネットワークを使用し、転送中は暗号化が必要
■ 正解の選択肢と解説
正解：B
Kinesis Data Firehose の VPC エンドポイントを作成します。VPC エンドポイントに接続するようにアプリケーションを構成します。
解説：
Kinesis Data Firehose は インターフェース型の VPC エンドポイント（AWS PrivateLink） をサポートしており、これを使うと オンプレミス → VPC → Firehose の経路をすべてプライベートな AWS ネットワーク内で確立できます。
Direct Connect と組み合わせることで、インターネットを経由せず、かつ HTTPS で暗号化された通信を行うことができ、セキュリティポリシーの要件を完全に満たします。
■ 不正解の選択肢の理由
A. パブリック向けの NLB を使って TLS 通信する
→ NLB 自体がパブリックであるため、トラフィックはインターネット経由になり、「プライベートネットワークでの転送」という要件に違反します。
C. IAM ポリシーで送信元IPを制限する
→ アクセス制御は可能ですが、ネットワーク経路がプライベートであることや転送中の暗号化を保証するものではありません。
D. Direct Connect と Firehose VPC をピアリング
→ VPC ピアリングは VPC と VPC 間でのみ利用可能であり、オンプレミスネットワークと VPC を直接ピアリングすることは できません。
■ SCS試験で押さえておくべきポイント
- Kinesis Data Firehose は AWS PrivateLink（インターフェース型 VPC エンドポイント）をサポート
- PrivateLink + Direct Connect 経由でのアクセスは、プライベートネットワーク経由かつ暗号化（HTTPS）での通信が可能
- IAM ポリシーはアクセス制御には有効だが、ネットワーク経路のセキュリティや暗号化とは別の観点
- VPC ピアリングは AWS 内部の VPC 同士の接続に限定され、オンプレミスとは直接ピアリングできない
次の問題も引き続き対応可能です。HTML形式でお送りください。
以下はご指定の形式に従った「問題5」の解説です。
■ 問題文（文字列を編集せずに出力してください。）
ある企業は、Amazon Elastic Container Service (Amazon ECS) を使用して、AWS 上でコンテナベースのアプリケーションを実行しています。同社は、コンテナイメージに深刻な脆弱性が含まれていないことを確認する必要があります。また、特定の IAM ロールと特定の AWS アカウントのみがコンテナイメージにアクセスできるようにする必要があります。
これらの要件を最も少ない管理オーバーヘッドで満たすソリューションを選択してください。
■ 選択肢（文字列を編集せずに出力してください。）
A.
パブリックコンテナレジストリからイメージを取得します。集中管理された AWS アカウントで構成されたスキャンオンプッシュで、Amazon Elastic Container Registry (Amazon ECR) リポジトリにイメージをプルします。CI/CD パイプラインを使用して、イメージを別の AWS アカウントにデプロイします。リポジトリポリシーと ID ベースのポリシーを使用して、どの IAM プリンシパルとアカウントがイメージにアクセスできるかを制限します。
B.
パブリックコンテナレジストリからイメージを取得します。集中管理された AWS アカウントで構成されたスキャンオンプッシュで Amazon Elastic Container Registry (Amazon ECR) リポジトリにイメージをプルします。CI/CD パイプラインを使用して、イメージを別の AWS アカウントにデプロイします。ID ベースのポリシーを使用して、どの IAM プリンシパルがイメージにアクセスできるかを制限します。
C.
パブリックコンテナレジストリからイメージを取得します。集中管理された AWS アカウントの Amazon EC2 インスタンスでホストされているプライベートコンテナレジストリにイメージをプルします。Amazon ECS を実行する EC2 インスタンスに、ホストベースのコンテナスキャンツールをデプロイします。HTTPS 経由の基本認証を使用して、コンテナイメージへのアクセスを制限します。
D.
パブリックコンテナレジストリからイメージを取得します。集中管理された AWS アカウントの AWS CodeArtifact リポジトリにイメージをプルします。CI/CD パイプラインを使用して、イメージを別の AWS アカウントにデプロイします。リポジトリポリシーと ID ベースのポリシーを使用して、どの IAM プリンシパルとアカウントがイメージにアクセスできるかを制限します。
■ 問題文の要件の概要
- コンテナイメージに脆弱性がないことを確認（＝スキャン機能が必要）
- 特定の IAM ロールと特定の AWS アカウントのみがアクセスできるようにする（＝アクセス制御）
- 管理オーバーヘッドを最小限にしたい（＝マネージドサービスの活用が望ましい）
■ 正解の選択肢と解説
正解：A
パブリックコンテナレジストリからイメージを取得し、スキャンオンプッシュ機能を有効にした Amazon ECR に登録、CI/CD により他アカウントへデプロイし、IAM + リポジトリポリシーでアクセスを制限
解説：
Amazon Elastic Container Registry (ECR) は、スキャンオンプッシュ機能（基本または拡張）を提供しており、脆弱性を自動的に検出できます。また、リソースベースの リポジトリポリシーとIDベースのIAMポリシーを併用することで、「特定のロール＋アカウント」のみがアクセスできるよう厳格に制御可能です。
さらに、ECR はマネージドサービスであるため、プライベートリポジトリ構築などの管理オーバーヘッドが不要です。
■ 不正解の選択肢の理由
B.
IAMポリシーのみでアクセス制御しているため、「特定のアカウント」の制限ができない。また、IAMポリシー単体ではリポジトリごとの細かい制御がしにくい。
C.
独自のプライベートレジストリを EC2 上に構築して管理しており、管理オーバーヘッドが非常に大きい。スキャンもホストベースであり、自動化・スケーラビリティに欠ける。
D.
CodeArtifact はコンテナレジストリではなく、ソフトウェアパッケージ管理専用サービス。Docker イメージの保存・配信には使用不可。
■ SCS試験で押さえておくべきポイント
- Amazon ECR は脆弱性スキャン（スキャンオンプッシュ、拡張スキャン）に対応している
- リポジトリポリシー + IAM ポリシーでアカウント＋ロールレベルの細かなアクセス制御が可能
- AWS CodeArtifact は Docker レジストリではない
- マネージドサービスを使うことで管理負担を減らせるかどうかが選択のポイント
- セキュリティ要件（アクセス制御・脆弱性スキャン）＋運用要件（オーバーヘッド最小化）のバランスを考慮する
次の問題も引き続き対応可能です。HTML形式で貼り付けてください。
以下はご指定の形式に従った「問題6」の解説です。
■ 問題文（文字列を編集せずに出力してください。）
監査の結果、ある企業の Amazon EC2 インスタンスのセキュリティグループが、無制限の着信 SSH トラフィックを許可することにより、企業ポリシーに違反していることが判明しました。セキュリティエンジニアは、このような違反を管理者に通知する、ほぼリアルタイムの監視とアラートのソリューションを実装する必要があります。
これらの要件を最も高い運用効率で満たすソリューションを選択してください。
■ 選択肢（文字列を編集せずに出力してください。）
A.
毎日実行され、Network Reachability パッケージを使用する定期的な Amazon Inspector 評価実行を作成します。評価実行の開始時に AWS Lambda 関数を呼び出す Amazon CloudWatch ルールを作成します。評価実行が完了したときに、評価実行レポートを取得して評価するように Lambda 関数を構成します。無制限の着信 SSH トラフィックに違反がある場合は、Amazon Simple Notification Service (Amazon SNS) 通知を発行するように Lambda 関数も構成します。
B.
準拠していないセキュリティグループの設定変更によって呼び出される restricted-ssh AWS Config マネージドルールを使用します。AWS Config 修復機能を使用して、Amazon Simple Notification Service (Amazon SNS) トピックにメッセージを公開します。
C.
VPC の VPC フローログを設定し、Amazon CloudWatch Logs グループを指定します。新しいログエントリを解析し、ポート 22 で成功した接続を検出し、Amazon Simple Notification Service (Amazon SNS) を通じて通知を公開する AWS Lambda 関数に CloudWatch Logs グループをサブスクライブします。
D.
毎日実行され、セキュリティのベストプラクティスパッケージを使用する、定期的な Amazon Inspector 評価実行を作成します。評価実行の開始時に AWS Lambda 関数を呼び出す Amazon CloudWatch ルールを作成します。評価実行が完了したときに、評価実行レポートを取得して評価するように Lambda 関数を構成します。無制限の着信 SSH トラフィックに違反がある場合は、Amazon Simple Notification Service (Amazon SNS) 通知を発行するように Lambda 関数も構成します。
■ 問題文の要件の概要
- SSH (TCP 22) ポートが 0.0.0.0/0 に開放されているセキュリティグループを即時検出
- 通知を管理者に送る必要がある
- できるだけ運用負荷が少ない（＝定期実行や手動の排除）
- リアルタイム性が求められている
■ 正解の選択肢と解説
正解：B
準拠していないセキュリティグループの設定変更によって呼び出される
restricted-sshAWS Config マネージドルールを使用します。AWS Config 修復機能を使用して、Amazon SNS トピックに通知を送ります。
解説：
AWS Config の restricted-ssh マネージドルールは、セキュリティグループが SSH（TCP 22）に対して 0.0.0.0/0（全世界）からのアクセスを許可しているかを検出し、非準拠状態を評価します。
Config ルールは 設定変更時にトリガーされるため、リアルタイムに近いタイミングで検知・評価が可能。さらに 修復アクションとして SNS へ通知を送ることができるため、管理者に即時アラートを送信する仕組みが容易に構築できます。
また、Inspector や Lambda を使わずマネージドルールだけで済むため、運用効率も高いです。
■ 不正解の選択肢の理由
A / D. Amazon Inspector（定期評価）を使う方法
→ Inspector はリアルタイムではない。定期スキャン（たとえば1日1回）であり、即時性に欠けるため要件を満たさない。
C. VPC フローログを監視してポート22の接続を検出
→ VPC フローログはトラフィックベースであり、セキュリティグループの設定状態を直接監視できない。また、実際に通信が発生しないと検知できず、リアルタイムの構成監視としては不適切。
■ SCS試験で押さえておくべきポイント
- AWS Config は構成変更の検出・評価・通知が可能
- restricted-ssh ルールはポート22を全世界に開放していないかを監視
- Config ルールは SNS や自動修復と連携可能
- Inspector は定期スキャン型であり、構成監視には向かない
- VPC フローログはトラフィック監視であり、設定違反検知には非効率
次の問題もお送りください。HTML形式で引き続き対応します。
以下は「問題7」に関する解説です。AWS Certified Security – Specialty 試験対策として重要なポイントを整理しています。
■ 問題文（文字列を編集せずに出力してください。）
セキュリティチームは、AWS CloudTrail のログ記録が無効になっているというアラートを Amazon GuardDuty から受け取りました。セキュリティチームのアカウントでは、AWS Config、Amazon Inspector、Amazon Detective、および AWS Security Hub が有効になっています。セキュリティチームは、誰が CloudTrail を無効にし、CloudTrail が無効になっている間にどのようなアクションが実行されたかを特定したいと考えています。
この情報を取得するための最適な方法を選択してください。
■ 選択肢（文字列を編集せずに出力してください。）
A.
GuardDuty を使用して、CloudTrailLoggingDisabled イベントを生成したユーザーを見つけます。Security Hub を使用して、イベントに関連するアクティビティのトレースを見つけます。
B.
Detective を使用して、GuardDuty から CloudTrailLoggingDisabled イベントの詳細 (ユーザー名と、CloudTrail が無効になったときに発生したすべてのアクティビティを含む) を検索します。
C.
AWS Config を使用して、CLOUD_TRAIL_ENABLED イベントを検索します。設定レコーダーを使用して、CloudTrail が無効になっているときに発生したすべてのアクティビティを見つけます。
D.
Amazon Inspector を使用して、GuardDuty から CloudTrailLoggingDisabled イベントの詳細 (ユーザー名と CloudTrail が無効になっているときに発生したすべてのアクティビティを含む) を見つけます。
■ 問題文の要件の概要
- CloudTrail を無効にした「ユーザー」を特定
- CloudTrail 無効期間中に実行された「すべてのアクション」を確認
- 使用可能なサービスは：Detective、GuardDuty、Security Hub、Inspector、Config
■ 正解の選択肢と解説
正解：B
Detective を使用して、GuardDuty から CloudTrailLoggingDisabled イベントの詳細 (ユーザー名と、CloudTrail が無効になったときに発生したすべてのアクティビティを含む) を検索します。
解説：
Amazon Detective は、CloudTrail、VPC Flow Logs、GuardDuty などからのログデータを集約・解析し、セキュリティインシデントの根本原因の調査に最適化されたサービスです。
このケースでは、CloudTrail が無効にされた状況で誰が何をしたのかを視覚的に追跡でき、異常なユーザーの動作や API 呼び出しの分析が可能です。
GuardDuty の検出（CloudTrailLoggingDisabled）をトリガーとして、Detective で詳細調査に進むのが推奨パターンです。
■ 不正解の選択肢の理由
A. GuardDuty + Security Hub
- GuardDuty は検出（例：CloudTrailLoggingDisabled）は可能ですが、CloudTrail が無効だった期間中の全アクティビティを追跡できない。
- Security Hub は各サービスの検出統合ダッシュボードであり、追加のログ調査や相関分析は提供しない。
C. AWS Config
CLOUD_TRAIL_ENABLEDはリソースの状態に関するルールであり、「誰が無効にしたか」や「無効期間中のアクティビティ」は確認できない。- そもそも Config 自体が CloudTrail に依存しているため、CloudTrail が無効だと一部記録が取れない可能性がある。
D. Amazon Inspector
- Inspector は 脆弱性スキャンとネットワークアクセス検出に特化したサービスであり、ログやユーザーアクションの監査には不向き。
- CloudTrail の操作履歴分析やユーザー特定は機能外。
■ SCS試験で押さえておくべきポイント
- Amazon Detective は CloudTrail、GuardDuty、VPC Flow Logs からデータを統合し、不審なユーザーのアクティビティの調査に最適
- GuardDuty は「検出」に特化し、詳細調査には Detective を用いる
- Security Hub は検出イベントの集約・可視化に特化し、個別の詳細調査機能はない
- Config や Inspector は構成管理や脆弱性管理には適していても、CloudTrail のような監査ログ分析には使えない
- CloudTrail が無効な状態での調査には、CloudTrail に依存しないサービス（Detective）が必要
続けて問題があれば、引き続きHTML形式でご提供ください。丁寧に解析いたします。
