難易度は Level 1（やさしめ）〜Level 5（難関） の5段階です。
AWS SCS-C03のサンプル問題（本番形式・解説付き）
AWS SCS-C03（Amazon Web Services・AWS Certified Security - Specialty（SCS-C03））の出題形式を、実際の問題で確かめられます。ここに掲載する5問は、無料の会員登録で解ける模試 第1回（65問）の冒頭から抜粋したオリジナル問題です。当サイトは全715問を本番CBT準拠の形式で収録しており、この5問はそのごく一部にあたります。
設問1
ある受託開発会社は、新しく AWS Lambda 関数をデプロイした。運用担当が CloudWatch Logs を確認したところ、この関数のロググループ自体が作られていなかった。関数の実行ロールには、開発者が独自に作成したポリシーが付いている。この症状でまず疑うべきものはどれか。
- 実行ロールに logs:PutLogEvents がないか、ログレベルが絞られている
- 実行ロールに logs:CreateLogGroup がないか、関数が一度も呼ばれていない（正解）
- 関数を呼び出す側の IAM ポリシーに、lambda:InvokeFunction がない
- VPC 内の関数から CloudWatch Logs へ到達するための NAT ゲートウェイの経路が用意されていない
解説
ロググループ自体が存在しない症状では、実行ロールに logs:CreateLogGroup がない、または関数が一度も呼ばれていないことを疑う。logs:PutLogEvents の不足はロググループはあるがログイベントが空という症状に対応する。呼び出し側の権限は実行ロールとは別で、ログが書けない原因にはならない。VPC からの経路の不足は、VPC 内 Lambda でログが出ない場合の原因である。
設問2
ある会社のプラットフォーム担当は、CloudFormation StackSets で、OU のすべてのアカウントに監視とログのベースラインを配っている。担当は、今後 OU に新しく加わるアカウントにも、手作業なしでベースラインが展開され、OU から外れたアカウントの扱いも自動で決まるようにする必要がある。この要件に合う設定として正しいものはどれか。
- self-managed permissions を使えば automatic deployment により自動展開され、OU から外れると自動削除される仕組みになっている
- self-managed permissions を使い、ターゲット側のロールを事前に作っておけば新規アカウントにも自動展開される設定になる
- 権限モデルにかかわらず、StackSets の信頼されたアクセスを有効化すれば新規アカウントに自動展開される
- service-managed permissions を使えば automatic deployment により自動展開され、OU から外れると自動削除される（正解）
解説
service-managed permissions は AWS Organizations の管理するアカウント（ルートまたは OU 単位で指定）を対象とし、automatic deployment により OU に新しく参加したアカウントへ自動展開され OU から外れると自動削除される。self-managed permissions では、ターゲット側のロールを事前に作っておいても自動デプロイはできない。StackSets の信頼されたアクセスの有効化は service-managed permissions の前提で、権限モデルにかかわらず自動展開されるわけではない。
設問3
ある EC 事業者は、AWS Shield Advanced を購読し、ALB と CloudFront を保護している。セキュリティ担当は、DDoS 攻撃でアプリケーションに影響が出た時に、Shield Response Team（SRT）から能動的に連絡を受けられる proactive engagement を使いたい。先に行うことはどれか。
- Route 53 のヘルスチェックを作り、保護対象のリソースに関連付ける（正解）
- 保護対象のリソースのタグに、SRT 向けの連絡先を書き込んでおく
- 保護対象の ALB に rate-based rule を含む web ACL を関連付ける
- 保護対象の CloudFront にフィールドレベル暗号化を設定しておく
解説
proactive engagement は、Route 53 のヘルスチェックが関連付けられた Shield Advanced の保護にだけ使える。SRT は検知したイベントの間、ヘルスチェックの状態でアプリケーションへの影響を判断する。web ACL やフィールドレベル暗号化は proactive engagement の条件ではなく、連絡先はタグではなく Shield Advanced の設定に登録する。
設問4
ある会社では、開発者がバケットポリシーで S3 バケットを外部に公開してしまう事故が続いている。今回の事故の是正はすでに済んだ。セキュリティ企画室は、同じ事故が組織内のどのアカウントでも起きないよう、恒久的な予防の統制を入れる必要がある。再発防止の統制として最も適切なものはどれか。
- IAM Policy Simulator で policy の変更を検証する
- unused access analyzer で未使用の権限を洗い出す
- SCP で
s3:PutBucketPolicyを呼ぶ条件を縛る（正解） - IAM の last accessed information で利用実績を確認する
解説
再発を防ぐ統制は、RCP で aws:PrincipalOrgID が自組織でないアクセスを拒否する、SCP で s3:PutBucketPolicy の条件を縛る、AWS Config のルールで検知して自動修復する、である。IAM Policy Simulator は policy 変更の事前検証、unused access analyzer と last accessed information は権限が付きすぎていた場合の調査で使う道具であり、外部公開の再発防止の統制ではない。
設問5
ある会社は、バージョニングを有効にした S3 バケットで重要な記録を保管している。S3 の運用担当は、オブジェクトのバージョンの完全な削除と、バージョニングの状態の変更に MFA を要求する MFA Delete を設定したいと考えている。MFA Delete の設定方法として正しいものはどれか。
- ルートユーザーの認証情報でしか設定できず、CLI からの操作になる（正解）
- 管理者の IAM ユーザーの認証情報で設定でき、マネジメントコンソールから操作する
- バケットポリシーの条件キーとして設定でき、対象のプリンシパルを限定できる
- Object Lock の retention mode の一種として設定でき、保持期間と併用できる
解説
MFA Delete を併用すると、バージョンの完全削除とバージョニング状態の変更に MFA を要求でき、これはルートユーザーの認証情報でしか設定できず CLI からの操作になる。管理者の IAM ユーザーでコンソールから設定することはできない。バケットポリシーの条件キーでもなく、Object Lock の retention mode の一種でもない。
続きは、会員登録なしでそのまま50問解けます。採点と解説つきで、上と同じ本物の問題です。
登録なしで50問解く