AWS SCS サンプル問題

正解：C

A　GuardDutyにはS3 Protectionがあり、S3のデータイベントを解析して異常なアクセスパターンを検出できる。S3が対象外という前提が誤り

B　GuardDutyのS3 Protectionが解析するのはCloudTrailのS3データイベントであり、S3サーバーアクセスログではない。サーバーアクセスログを有効にしても検出結果は増えない

C（正解）　正解。S3 Protectionは個別に有効・無効を切り替えられる保護プランで、これが無効だとS3のデータイベントは解析対象にならない

D　Object Lockは書き込み保護の機能で、脅威検出の可否とは無関係。GuardDutyの解析対象や検出能力には影響しない

正解：A

A（正解）　正解。対象インスタンスのEBSボリュームからレプリカを作成してGuardDuty側でスキャンするため、インスタンス上にエージェントを常駐させる必要がなく本番ワークロードへの影響も小さい

B　実現はできるがエージェントの配布・更新・スキャン中の負荷という運用コストが発生し、インスタンス性能に影響を与えたくないという制約にも反する

C　Inspectorが検出するのはソフトウェアの脆弱性やネットワーク到達性、コード上の問題であり、マルウェアそのもののシグネチャ検査は行わない

D　Macieが対象とするのはS3上の機密データの検出であり、EBSボリュームもマルウェアも対象外である

正解：D

A　コントロールプレーンのログにはKubernetes APIへの操作が記録されるだけで、コンテナ内部でどのプロセスが起動したかというOSレベルの挙動は含まれない

B　スキャンはファイルの静的な検査であり、実行中プロセスの挙動をリアルタイムに捉えるものではない。シェル起動の検知には使えない

C　Inspectorが行うのはECR上のイメージや実行中インスタンスの脆弱性評価で、実行時の挙動監視は担当しない

D（正解）　正解。Runtime Monitoringはノードやポッドにエージェントを配置してプロセス起動・ファイルアクセス・ネットワーク接続といったランタイムイベントを収集し、監査ログだけでは見えない挙動を検出できる

正解：B

A　実現はできるが、閾値やクエリを自前で設計・維持する必要があり、未知の異常パターンには追随できない。設定変更も最小限とは言えない

B（正解）　正解。RDS Protectionは対象データベースのログイン活動を直接解析し、総当たりや通常と異なる挙動のログイン成功を検出結果として通知する。データベース側でログ出力設定を変更する必要がない

C　Detectiveは既存の検出結果を深掘り調査するサービスで、それ自体が新たな脅威を検出する起点にはならない

D　Security Hubのコントロールが評価するのはリソースの設定状態であり、実行中のログイン試行という動的なイベントは扱わない

正解：C

A　抑制ルールでも雑音は減らせるが、送信元IPで条件を絞らず検出結果タイプだけで抑制すると、他の送信元からの同種の通信まで見逃すことになる

B　脅威リストは既知の悪意ある送信元を登録して検出を促す仕組みであり、逆に検出結果を増やしてしまう

C（正解）　正解。信頼するIPリストに登録された送信元からの通信については検出結果が生成されなくなる。送信元IP単位で効くため、他の送信元からの同種の通信は引き続き検出される

D　セキュリティグループは通信制御の設定であり、GuardDutyの検出ロジックには影響しない。許可されている通信でも検出結果は生成される

正解：A

A（正解）　正解。GuardDutyは検出結果をEventBridgeへほぼリアルタイムに送信するため、イベントパターンで重大度を絞れば遅延なく振り分けられ、ポーリングも不要になる

B　ポーリングを作らないという条件に反し、最大5分の遅延も生じる。どこまで取得済みかという状態を自前で管理する手間も増える

C　S3へのエクスポートは一定間隔で行われるため即時性がなく、高重大度の即時通知という要件を満たせない

D　CloudTrailに記録されるのはAPI呼び出しであって検出結果の内容ではない。重大度による振り分けの材料にならない

正解：D

A　自前実装は可能だが、取得漏れや更新反映の維持が負担になる。標準機能で実現できる要件に対して過剰な作り込みである

B　委任管理者はアカウント間の集約を担うが、リージョン間の集約は別途集約リージョンの設定が必要で、指定しただけでは実現しない

C　レポート用途にはなるが、検出結果の状態更新やワークフロー管理といった運用機能が失われ、日々のトリアージには適さない

D（正解）　正解。アカウント間の集約は委任管理者、リージョン間の集約は集約リージョンの設定という2つの仕組みを組み合わせることで単一画面での確認が実現する。なお、この機能を提供する従来のSecurity Hubは2025年10月にAWS Security Hub CSPMへ改称され、同名の新しい統合サービスAWS Security Hub（2025年12月GA）と併存している

正解：C

A　実現はできるがアーキテクチャの大規模な変更を伴い、NATゲートウェイのコストや設計変更も必要になる。要件に対して重い

B　関数が明示的にログ出力しない限り通信先は記録されない。コードを変更しないという条件下では情報が得られない

C（正解）　正解。Lambda Protectionは関数のネットワークアクティビティログを解析し、VPC接続の有無にかかわらず不審な通信先への接続を検出できる

D　Inspectorのコードスキャンは静的解析で脆弱なコードを指摘するもので、実行時にどこへ通信したかという事実は把握できない

正解：D

A　分析自体は可能だが、テーブル定義やクエリの作成が必要で、平常時との比較も自前で行う必要がある。素早い可視化という要件に対して手間が大きい

B　Security Hubのコントロールは設定のコンプライアンス評価であり、ロールの過去の振る舞いや呼び出し頻度の推移は扱わない

C　未使用アクセスの分析は使われていない権限の洗い出しが目的で、時系列の挙動比較や異常性の可視化には向かない

D（正解）　正解。Detectiveはログを自動で取り込んで挙動グラフを構築し、対象の平常時のベースラインと当該期間の比較を用意された画面で確認できる

正解：C

A　Detectiveはログの出力先設定に依存せず自らデータソースを取り込むため、フローログの出力先が有効化の可否を左右することはない

B　Detectiveの委任管理者は他サービスと別に指定でき、Security Hubの委任管理者と一致している必要はない

C（正解）　正解。DetectiveはGuardDutyが一定期間（48時間）継続して有効になっていることを前提とする。有効化直後のアカウントでは条件を満たさずエラーになる

D　有効化はIAMロールでも実施でき、IAMユーザーの有無は前提条件ではない

正解：A

A（正解）　正解。カスタムアクションはアナリストが選択した検出結果をイベントとしてEventBridgeへ送るため、人の判断を挟んだ連携が自然に実装できる。なお、この機能を提供する従来のSecurity Hubは2025年10月にAWS Security Hub CSPMへ改称され、同名の新しい統合サービスAWS Security Hub（2025年12月GA）と併存している

B　対応が必要なものだけを登録したいという要件に反し、大量の不要チケットが発生して運用が破綻する

C　ワークフロー状態の変更で外部システムを直接呼び出す設定はSecurity Hubに存在しない。状態変更を検知する仕組みは別途必要になる

D架空　このような名称のサービスは存在しない。検出結果と外部システムの連携はイベント駆動の仕組みで実装する

正解：C

A　アクセスは止まるが、ユーザーに紐づくポリシーや所属情報が失われて事後調査がしにくくなる。まず無効化して調査の余地を残すのが定石である

B　既に流出したキーは有効なままで、進行中の不正アクセスは止まらない。リポジトリの清掃は必要だが最初の一手ではない

C（正解）　正解。キーの無効化は即座に不正利用を遮断でき、ユーザーやポリシーは残るため調査を継続できる。無効化したキーは調査後に削除すればよい

D　拒否ポリシーで一時的に遮断はできるが、キーが有効なまま残るためポリシーの適用漏れや解除で再び悪用される余地がある。キー自体の無効化が本筋である

正解：B

A　停止するとメモリ上の情報が失われる。揮発性の証拠を取得する前に停止してはならない

B（正解）　正解。稼働状態を保ったまま通信だけを遮断すればメモリ上の証拠を失わずに済む。隔離用セキュリティグループは調査に必要な経路だけを許可する設計にする

C　終了するとインスタンスストアもメモリも失われ、原因究明が不可能になる。復旧を優先するとしても証拠保全の後に行う

D　ロールを削除しても外部との通信は止まらない。またロールを消すと調査時のログ取得や証拠転送にも支障が出る

正解：B・C

A　証拠となるファイルやタイムスタンプが失われ、攻撃の経路や範囲が追えなくなる

B（正解）　正解。外部との通信を止めつつ、メモリ上の揮発性の情報を失わずに調査を進められる

C（正解）　正解。本番環境に手を加えずに解析でき、解析作業による証拠の汚染も避けられる。暗号化キーの共有許可も併せて必要になる

D　メモリ上の情報が失われ、攻撃者の痕跡も消える。侵害の原因が残っていれば再び悪用される

E　証拠が完全に失われる。復旧を優先する場合でも証拠保全の後に行うべきである

正解：A・C

A（正解）　正解。侵害の判明後に設計から始めると封じ込めが遅れるため、隔離の手段と解析の場は平時に用意して手順を確認しておく

B　有効化した時点より前の記録は残らないため、最も知りたい侵害前後の挙動が失われる。ログは平時から取得しておく必要がある

C（正解）　正解。平時は使わない強い権限を用途と主体を限って用意し、利用そのものを検知できるようにしておくことで、緊急時の初動と事後の説明責任を両立できる

D　判断のばらつきと対応の遅れを招く。想定される事案ごとに手順を用意し、訓練で検証しておくのが基本になる

E　メモリやインスタンスストア上の証拠が失われ、原因究明が不可能になる。証拠保全を経てから復旧するのが原則である

正解：B

A　既定の形式にセキュリティグループIDは含まれない。どのルールで落ちたかがそのまま記録されるわけではない

B（正解）　正解。両者の状態管理の違いが記録のされ方に現れる。受信は許可されているのに戻り方向に拒否レコードが出ている場合はネットワークACLを疑うといった切り分けができる

C　フローログは許可と拒否の両方を記録でき、フィルターで選択もできる。CloudTrailはネットワーク通信を記録しない

D　アクション欄に記録されるのは許可か拒否かだけで、どのリソースが拒否したかは記録されない

正解：B

A　実際に流れた通信のメタデータしか残らないため、まだ使われていない到達経路は見つけられない

B（正解）　正解。到達してはならない経路をスコープとして宣言すると、構成を静的に解析して条件に一致する経路を検出結果として示すため、通信の実績がなくても過剰なアクセスを洗い出せる

C　脅威の兆候を知らせる仕組みで、構成上の到達可能性を網羅的に点検する用途ではない

D　ルートテーブルやゲートウェイまで含めた組み合わせを人手で追うことになり、規模が大きくなると点検漏れが避けられない

正解：B

A　台数変動には耐えるが、同じサブネットに別の用途のリソースが配置されると意図しない通信まで許可される。層の境界を正確に表現できない

B（正解）　正解。セキュリティグループを送信元に指定すれば、そのグループに属するインスタンスが増減してもルールの変更が不要で、層の境界を論理的に表現できる

C　ネットワークACLはステートレスで戻り方向のエフェメラルポートの管理が必要になるうえ、セキュリティグループを全許可にすると多層防御が失われる

D　台数が変わるたびにルールの追加・削除が必要で運用負荷が高く、ルール数の上限にも当たりやすい

正解：C

A　拒否ルールがない点は正しいが、ネットワークACLはステートレスであるという基本を取り違えている

B　外部からの攻撃を止めるなら受信ルールでの拒否が中心になる。送信ルールだけでは受信を止められない

C（正解）　正解。ネットワークACLはルール番号の小さい順に評価され、拒否ルールを書ける唯一のレイヤーとしてサブネット単位の遮断に使える。番号順の設計が要点になる

D　WAFはHTTP/HTTPSを扱うレイヤーで、対象がWeb以外の通信を含む場合には適用できない。ネットワークACLで遮断できるという前提も誤っている

正解：D

A　セキュリティグループのルールで指定できるのはIPアドレス範囲やセキュリティグループなどで、ドメイン名は指定できない

B　IPアドレスが頻繁に変わる前提では維持できない。ルール数の上限にも当たりやすい

C　通信の制限にならないどころか、インスタンスをインターネットへ露出させる危険な変更である

D（正解）　正解。Network Firewallはドメイン名によるフィルタリングに対応しており、IPアドレスの変動に影響されずに許可対象を表現できる。出口を1か所に集約する設計とも相性が良い

正解：C

A　セキュリティグループを送信元に指定できるのは、そのグループに属するENIからの通信を許可する用途である。グループに属さない社外拠点のCIDRを間接的に参照する使い方はできない

B　ネットワークACLはステートレスで戻り方向の管理が必要になるうえ、セキュリティグループを全許可にすると多層防御が失われる

C（正解）　正解。参照先のプレフィックスリストを1か所更新すれば、それを参照するすべてのセキュリティグループへ反映されるため、拠点の増減に個別の修正が不要になる。ほかのアカウントへ共有して使わせることもできる

D　セキュリティグループのルールに書かれたCIDRの値を判定できる条件キーは用意されていないため、ルールの中身を根拠にした予防的な拒否は表現できない

正解：C

A　インスタンスをインターネットへ露出させることになり、セキュリティ上の後退である。接続内容の記録も残らない

B　経路の保護にはなるが、鍵の管理は残り、OS内での操作記録も別途仕組みが必要になる。踏み台の課題の一部しか解消しない

C（正解）　正解。受信ポートも鍵も不要で、IAMで接続権限を制御でき、セッションの操作内容をログとして残せる。踏み台の維持コストもなくなる

D　シリアルコンソールは障害復旧向けの手段で、日常の運用アクセスの代替としては機能や記録の面で不適切である

正解：B

A　ピアリングはCIDRが重複していると確立できず、また経路とセキュリティグループの設定次第で他リソースへの到達余地が残る

B（正解）　正解。PrivateLinkによる接続はCIDRの重複に影響されず、公開したサービスにのみ到達できるため、他リソースへのアクセスを構造的に遮断できる

C　CIDR重複の問題が残り、顧客同士や自社ネットワークとの経路設計も複雑になる。外部顧客との接続には過剰である

D　通信がインターネットを経由し、顧客のIP変更のたびに設定が必要になる。プライベート接続を求める要件にも合わない

正解：D

A　NATゲートウェイはIPv4アドレスの変換を担う仕組みで、IPv6の外向き通信を担当するものではない

B　IPv6アドレスはグローバルに到達可能なため、経路を通した時点で外部から到達し得る構成になる。設定ミスが即座に露出につながる

C　ネットワークACLはステートレスなので戻り方向の許可が必要になり、外部からの接続開始を構造的に防げるわけではない

D（正解）　正解。Egress専用インターネットゲートウェイはステートフルに動作し、VPC内から開始した通信のみを許可して外部からの接続開始を遮断する。IPv6のための仕組みである

正解：C

A　管理ポリシーは対象を限定しないため、すべてのロググループが閲覧可能になり要件に反する

B　保持期間はアクセス制御ではない。他のロググループも保持期間内は閲覧できてしまう

C（正解）　正解。CloudWatch LogsのアクションはロググループARNをリソースとして指定できるため、対象を限定した最小権限のポリシーで要件を満たせる

D　暗号化キーの権限は補助的な制御にはなるが、ログ読み取りアクション自体を許可していれば他のロググループは依然として閲覧できる

正解：A

A（正解）　正解。エンドポイント識別子や送信元IPを条件にした拒否を書けば、正しい認証情報を持っていても経路が条件に合わなければアクセスできなくなる

B　匿名の公開アクセスは防げるが、認証済みの利用者がインターネット経由でアクセスすることは防げない

C　S3はVPC内に配置するサービスではないため、この操作自体が成立しない

D　VPC専用のアクセスポイント経由の制限にはなるが、バケット本体のエンドポイントへ直接アクセスされる経路が残るため、バケットポリシー側の制限が必要になる

正解：B

A　エンドポイント経由のリクエストではプライベートIPが送信元として評価されず、この判定は意図どおりに機能しない

B（正解）　正解。S3のバケットポリシーではエンドポイント識別子やVPC識別子を条件に指定でき、経路に基づいたアクセス制御が表現できる

C　経路を示す条件キーは実際に存在し、ネットワークACLではS3のバケット単位の制御はできない

D　この条件キーが判定するのは通信がHTTPSかどうかであり、経路の判定には使えない

正解：D

A　エージェントの起動・停止を人手で行う運用は破綻しやすく、停止中は正常な管理機能も失われる

B　長時間の接続は防げるが、承認外の時間帯に接続を開始すること自体は防げない

C　事後の検知にとどまり、時間帯を限定するという要件を予防的には満たさない

D（正解）　正解。時刻を条件にしたポリシーであれば、承認された時間帯以外の接続要求そのものを拒否できる。対象インスタンスをタグ等で限定する条件と組み合わせると統制がさらに明確になる

正解：C

A　許可の広さが拒否を上書きすることはない。評価の基本原則を取り違えている

B　識別ベースのポリシーがリソースベースのポリシーの明示的な拒否を上書きすることはない

C（正解）　正解。どのポリシー種別であっても明示的な拒否が1つでもあれば最終結果は拒否になる。明示的拒否は評価の最初に判定され、他の許可では覆せない

D　ポリシーの更新時刻が評価に影響することはない。そのような優先規則は存在しない

正解：B

A　事後の是正であり、検知までの間は過大な権限が有効なままになる。予防的な統制になっていない

B（正解）　正解。許可境界は作られるロールが行使できる権限の上限を定め、境界の付与を条件にすることで境界なしのロール作成そのものを防げる

C　特定のポリシー名を拒否しても、同等の権限を持つ独自ポリシーを作られると回避される

D　ロールを自由に作らせたいという前提が成立しなくなる

正解：D

A　1つのロールに集約する方針に反し、長期認証情報の管理という重い課題を抱え込む

B　同時に複数の利用者が存在する環境では競合し、書き換えの遅延で誤った権限が付与される危険がある

C　アプリの実装に不備があれば他利用者のデータへ到達できる。権限の境界がAWS側で担保されない

D（正解）　正解。セッションポリシーはロールの権限とセッションポリシーの重なりだけを有効にするため、共通ロールを保ちながらセッション単位の最小権限が実現できる

正解：A

A（正解）　正解。NotActionを許可と組み合わせると列挙外のすべてが許可対象になる。禁止を表現したいのであれば明示的な拒否で書くべきである

B　NotActionは識別ベースのポリシーでも使用でき、無効になるわけではない

C　サイズ上限とNotActionの使用に直接の関係はない

D　NotActionは対象の指定方法であって、効果を拒否に変える働きはない

正解：C

A　プロジェクトの増加に比例してポリシーが増え、リソース追加のたびに更新が必要になる。避けたい運用そのものである

B　分離の観点では強力だが、同一アカウントを共有するという前提を変える大きな移行を伴い、要件への回答としては過剰である

C（正解）　正解。プロジェクトが増えてもタグを付けるだけで済み、ポリシーの追加や書き換えが不要になる。タグ付けの統制を併せて設計する必要がある

D　管理対象が最も増える方式で、要望と正反対の運用になる

正解：B

A　ユーザー名は組織外でも自由に付けられるため、組織の内外を区別する根拠にならない

B（正解）　正解。組織IDを条件にすればアカウントの追加や削除に追随でき、アカウントIDの列挙が不要になる

C　Principal要素に組織を指定する記法はなく、指定できるのはアカウントやロールなどのプリンシパルに限られる

D　SCPは自組織のアカウント内の主体にしか適用されないため、組織外からのアクセスを拒否する制御にはならない

正解：A

A（正解）　正解。ログファイル検証を有効にすると各ログのハッシュを含む署名付きダイジェストファイルが定期的に出力され、ファイルの変更・削除の有無を後から検証できる

B　上書きからの復元には有効だが、ファイルが改ざんされていないことをAWSの署名で証明する手段にはならない

C　アクセスの記録は残るが、個々のログファイルの内容が元のままであることの証明にはならない

D　暗号化は機密性を守る仕組みで、完全性の検証手段ではない。復号できる権限があれば書き換えたうえで再暗号化もできてしまう

正解：D

A　バケットポリシーは権限を持つ者が変更できるため、管理者による削除を技術的に防ぐ保証にならない

B　誤削除の抑止にはなるが、ルートユーザーがMFAを使えば削除でき、期間内の変更不可を保証する仕組みではない

C　ストレージクラスの移行はコスト最適化の手段で、削除を防ぐ効果はまったくない

D（正解）　正解。コンプライアンスモードではルートユーザーを含む誰も保持期間中のオブジェクトを削除・上書きできず、保持期間の短縮もできないため規制要件を技術的に満たせる

正解：A

A（正解）　正解。データ保護ポリシーは取り込み時に機密データを検出し、既定では閲覧時にマスク表示する。解除には別途の権限が必要なため、暫定的な露出低減策として機能する

B　保持期間中は依然として閲覧できるうえ、調査に必要なログまで失われる

C　暗号化してもログを閲覧できる利用者には平文が見えるため、特定の機密項目だけを隠す要件は満たせない

D　MacieはS3を対象とするサービスでCloudWatch Logsは扱えず、検出箇所を書き換える機能も持たない

正解：C

A　パブリックIPを割り当ててもインターネットゲートウェイがなければ通信できず、方針にも反する

B　実現の余地はあるが、オンプレミス側の経路と機器に依存する複雑な構成になり、AWS内で完結する標準的な解決策がある

C（正解）　正解。セッション管理やメッセージングに必要なエンドポイントをVPC内に作成すれば、インターネットへの経路なしにエージェントがサービスへ到達できる

D　S3向けのエンドポイントは一部の機能で必要になるが、それだけではSystems Manager本体のエンドポイントへ到達できない

正解：C

A　都度の書き換えが必要で、複数の委譲が並行すると衝突しやすい。書き換えの取り消し漏れも起きる

B　エイリアスは参照用の別名で、権限を分離する仕組みではない

C（正解）　正解。グラントはキーポリシーを変更せずに一時的で限定的な権限を委譲でき、取り消しによって即座に権限を失わせられる。多数の一時的な委譲を扱う用途に適している

D　長期の認証情報が増え、期間を限定した委譲という要件にも合わない

正解：D

A　既存の単一リージョンキーを後からマルチリージョンキーへ変換することはできない。作成時に選択する属性である

B　権限の付与はできるが、復号のたびに元リージョンのKMSへ依存する構成が残り、要望に反する

C　KMSで生成したキーマテリアルをエクスポートすることはできない

D（正解）　正解。マルチリージョンキーは同じキーマテリアルを持つため、一方で暗号化したデータを他方で復号でき、リージョン間の依存を持たずに処理を継続できる

正解：A

A（正解）　正解。インポートしたキーマテリアルであれば原本を自社で保持でき、有効期限の設定や必要時の削除による無効化も自社の判断で行える。自動ローテーションが使えない点は運用設計で補う

B　KMSが生成したキーマテリアルはエクスポートできないため、この運用は成立しない

C　AWS管理キーはキーポリシーを編集できず、鍵の生成を自社管理下で行うという要件も満たさない

D　鍵を平文でストレージへ置くことになり、保護の観点で大きく後退する

正解：B

A　S3やEBSの標準的な暗号化統合はCloudHSMのAPIを直接利用する構成に対応しておらず、アプリケーション側の作り込みが大量に発生する

B（正解）　正解。鍵はCloudHSMのクラスターに保管されつつ、利用側はKMSのキーとして扱えるため、サービス統合をそのまま活かして規制要件に対応できる

C　AWS管理キーのキーマテリアルを別の場所へ保管する仕組みはなく、要件も満たさない

D　マルチリージョンキーはリージョン間での利用のための機能で、単一テナントのハードウェアという要件とは無関係である

正解：C

A　既存のデータが自動的に再暗号化されることはない。再暗号化が必要なら利用者側で実施する

B　キーIDやARNは変わらず、アプリケーションの参照を変更する必要はない

C（正解）　正解。過去のデータを復号できるよう古いキーマテリアルが保持されるため、ローテーションを有効にしても既存データの読み取りに影響しない

D　古いキーマテリアルは削除されない。この前提での事前作業は不要である

正解：B

A　招待ベースの関連付けは各アカウントの手作業が必要で、新規アカウントの自動有効化もできない。管理アカウントを日常運用に使わない方針にも反する

B（正解）　正解。委任管理者に指定すれば管理アカウントを使わずに組織全体を管理でき、新規アカウントの自動有効化と検出結果の集約の両方を満たせる

C　SCPは操作を禁止できるが有効化を強制することはできない。有効化されていないアカウントは無効のまま残り、集約も実現しない

D　検出結果の集約は部分的に実現できるが、コンソール上での一元管理や新規アカウントの自動有効化は解決しない。構成の維持コストも高い

正解：B

A　組織全体での無効化は他アカウントでも評価が止まってしまい、他アカウントでは評価を続けたいという要件に反する

B（正解）　正解。コントロールの有効・無効はアカウントとリージョンの単位で制御できるため、当該アカウントだけ評価対象から外し、他アカウントの評価は維持できる。なお、この機能を提供する従来のSecurity Hubは2025年10月にAWS Security Hub CSPMへ改称され、同名の新しい統合サービスAWS Security Hub（2025年12月GA）と併存している

C　個々の検出結果は非表示にできるが、コントロールは評価され続けるため新しいリソースが作られるたびに再び検出結果が生成され、恒久的な例外にならない

D　一部のコントロールのために全体の可視性を失うことになり、他の重要な検出まで得られなくなる過剰な対応である

正解：C

A　未使用アクセスの分析は定期的な棚卸し向けで、数分以内の検知には対応しない

B　アクセスキーの存在という設定状態を見るだけで、ルートユーザーがログインして操作したという事象は検知できない

C（正解）　正解。管理イベントはEventBridgeへ配信されるため、ユーザー種別がルートであることをパターンに指定すれば追加の集約基盤を作らずに即時通知できる

D　管理アカウントのルートユーザーにはSCPが適用されないため制御できない。そもそも緊急時の利用を残す方針とも矛盾する

正解：A

A（正解）　正解。Configは対応リソースの構成をスナップショットとして記録し、いつどの項目がどう変わったかを変更前後の差分として提示できるため、追加の加工が不要である

B　理論上は可能だが、変更のたびの差分を人手でつなぎ合わせる必要があり、作業量が大きい

C　コントロールは準拠しているかどうかを示すだけで、設定値そのものの変遷は分からない

D　通信の傾向から設定を推定するのは根拠が弱く、監査に耐える資料にならない

正解：A

A（正解）　正解。未使用のセキュリティグループや制限のないルールを評価するマネージドルールが用意されており、集約器を使えば多数アカウントの結果を1か所で確認できる

B　実現はできるが、判定ロジックの実装と多数アカウントへの配布・保守が負担になる。標準機能で賄える要件である

C　フローログにセキュリティグループの識別子は含まれず、通信がないことと関連付けがないことも別の話である

D　一部の指摘は得られるが、組織全体の継続的な評価と非準拠一覧の集約という運用には設計されていない

正解：D

A　アカウントや主体の追加のたびに漏れが生じ、管理者権限を持つ利用者が自ら外せてしまう

B　リージョンの有効・無効はアカウント単位の設定で、組織のガードレールとしては一元的に強制されない

C　グローバルサービスの操作は特定のリージョンを起点に記録されるため、単純な拒否では正当な操作まで止まってしまう

D（正解）　正解。リージョン条件による拒否に、グローバルに扱われるサービスのアクションを除外する記述を組み合わせることで、業務を止めずに範囲を限定できる

正解：A

A（正解）　正解。管理アカウントはSCPの対象外であり、これが管理アカウントで日常の運用作業を行わない設計が推奨される理由でもある

B　ルートへの適用も有効で、配下の組織単位とアカウントに継承される

C　そのような設定は存在しない。管理アカウントが対象外であるという仕様自体を変更できない

D　そのような反映遅延の仕様はない