AWS SCS-C03のサンプル問題（本番形式・解説付き）

解説

本文は要件の6軸として、対象・検出対象・検出までの時間・通知先と経路・保持期間・コストを挙げている。暗号化方式と責任分界点は6軸に含まれない。リージョン数やアカウント数は「対象」の中身であって独立した軸ではなく、担当者数も挙げられていない。可用性目標と復旧手順も、この6軸の並びには含まれていない。

解説

本文の表は、数秒〜1分の検出時間に EventBridge ルールから SNS や Lambda へ渡す構成を対応させており、findings やイベントが発生した時点で押し出されることを理由に挙げている。AWS Config rules の評価は数十分〜数時間の帯に置かれている。Athena の定期クエリと Macie の sensitive data discovery jobs は、いずれも日次以上の帯であり、分析コストと引き換えに深く見る用途とされている。

解説

本文は、Event history がリージョン内の過去90日間の CloudTrail management events を閲覧・検索・ダウンロードできる不変の記録であるとしている。data events は既定で記録されず、Event history では扱えない。無期限の保持は S3 への配送で実現するものであり、Event history の機能ではない。複数アカウントの集約は組織 trail の役割で、Event history にはできないと明記されている。

解説

本文は、event data store の保持期間について、One-year extendable retention pricing なら最大3,653日（約10年）、Seven-year retention pricing なら最大2,557日（約7年）としている。したがって約10年を求めるなら前者を選ぶ。Event history に保持期間の延長機能はなく、過去90日で固定されている。trail 側には保持期間の指定という設定がなく、保持は配送先の S3 やロググループの設定で決まる。

解説

本文は、ログの保管先をワークロードとは別の専用アカウントに置き、そのバケットに対する削除権限をワークロード側の管理者から外す形を、組織レベルの監視設計の基本形としている。同一アカウント内に置く案は、その管理者が侵害されれば消せてしまうため要件を満たさない。findings だけを残す案は生ログという証拠を失う。置き場所を毎日入れ替える運用は本文に示されておらず、配送設定の複雑化を招くだけである。