Q1 — 単一選択企業では、社員は既存の企業IdPを使って複数のAWSアカウントへアクセスし、EC2上のアプリケーションはAmazon S3へアクセスする。人にもワークロードにも長期アクセスキーを配布したくない。最も適切な組み合わせはどれか。
A. 社員は企業IdPとのフェデレーションとAWS IAM Identity Centerなどを通じて一時的な認証情報を利用し、EC2アプリケーションはIAMロールを利用する
B. 社員ごとに各AWSアカウントへIAMユーザーを作成し、EC2アプリケーションにも同じユーザーのアクセスキーを保存する
C. 社員アクセスにはAmazon Cognitoだけを利用し、EC2アプリケーションは共有ルートユーザーのアクセスキーを利用する
D. 社員とEC2アプリケーションの両方で1つのIAMユーザーを共有し、アクセスキーを定期的に手動ローテーションする
答えと解説
答え:A
人のアクセスとワークロードのアクセスは認証主体を分けて設計します。社員は企業IdPとのフェデレーションにより一時的な認証情報を利用し、EC2上のワークロードはIAMロールを利用することで、固定アクセスキーの配布を避けられます。
Q2 — 単一選択Amazon EC2上のアプリケーションがAmazon S3からオブジェクトを取得する。アプリケーションへ長期アクセスキーを保存したくない。最も適切なのはどれか。
A. アプリケーション専用IAMユーザーのアクセスキーをSecrets Managerへ保存し、インスタンス起動時に取得する
B. アプリケーション専用IAMユーザーのアクセスキーをSystems Manager Parameter StoreのSecureStringへ保存する
C. アプリケーション専用IAMユーザーのアクセスキーを定期ローテーションし、インスタンスメタデータとは別経路で配布する
D. EC2へIAMロールをインスタンスプロファイルとして割り当て、一時的な認証情報を利用する
答えと解説
答え:D
認証情報の保管場所を変えるのではなく、EC2へIAMロールを割り当てて一時的な認証情報を利用することで長期認証情報の配布を避けます。
Q3 — 単一選択古い外部ツールがAWS APIへアクセスする必要がある。このツールは一時的な認証情報、フェデレーション、ロールベースの認証情報取得に対応しておらず、固定アクセスキーしか利用できない。最も適切な対応はどれか。
A. ツール専用IAMユーザーへPowerUserAccessを付与し、アクセスキーを定期ローテーションする
B. 複数のレガシーツールで共有するサービス IAMユーザーを作成し、必要サービスへの権限をまとめて付与する
C. 運用担当者用IAMユーザーのアクセスキーを認証情報ボールトへ保存し、ツールから参照する
D. 必要最小限の権限を持つツール専用IAMユーザーを例外的に作成し、アクセスキーを管理する
答えと解説
答え:D
一時的な認証情報に対応できない明確な制約がある場合だけIAMユーザーを例外的に検討し、専用アイデンティティ・最小権限・ローテーションを前提にします。
Q4 — 単一選択社員は企業IdPによるサインインには成功している。しかしec2:TerminateInstancesを実行するとアクセス拒否になる。主に確認すべき設計領域はどれか。
A. 認可
B. 認証
C. フェデレーション
D. アイデンティティプロビジョニング
答えと解説
答え:A
サインイン自体は成功しているため認証ではありません。認証済みプリンシパルが対象アクションを実行できるかという認可を確認します。
Q5 — 単一選択AWS Lambda 関数がDynamoDBへアクセスしている。現在は関数の環境設定に長期アクセスキーを設定している。改善として最も適切なのはどれか。
A. アクセスキーをSecrets Managerへ移し、自動ローテーションする
B. アクセスキーをSystems Manager Parameter StoreのSecureStringへ移す
C. Lambda 実行ロールへ必要な権限を付与する
D. アクセスキーをKMSで暗号化した環境変数へ保存し、定期ローテーションする
答えと解説
答え:C
固定認証情報の保存場所や暗号化方法を改善するより、Lambda 実行ロールへ必要権限を付与してワークロードアイデンティティへ移行します。
Q6 — 単一選択アプリケーションにはcompany-reports バケットのオブジェクト取得だけが必要である。現在のポリシーはAction: s3:GetObject、Resource: *である。最も適切な改善はどれか。
A. Resource: * は維持し、aws:ResourceAccount 条件だけを追加する
B. Resource を必要なバケット/オブジェクト ARNへ限定する
C. Resource: * は維持し、権限境界で s3:GetObject だけに限定する
D. 同じポリシーをアプリケーション専用ロールへ移し、Resource: * は維持する
答えと解説
答え:B
アクションが必要最小限でもリソースが全対象では最小権限になりません。必要なバケット/オブジェクト ARNへ範囲を絞ります。
Q7 — 単一選択特定のS3 バケットへのGetObjectは許可したいが、指定したVPCエンドポイントを経由するリクエストだけに制限したい。アクションとリソースはすでに適切である。追加で主に利用するポリシー要素はどれか。
A. Effect
B. アクション
C. リソース
D. 条件
答えと解説
答え:D
アクセス元など追加の利用条件を指定する場合は条件を使用します。
Q8 — 単一選択あるリクエストについて、適用されるポリシーの1つがアクションを許可し、別の適用されるポリシーが同じリクエストを明示的に拒否している。結果として正しいものはどれか。
A. 明示的な拒否によって拒否される
B. 許可が存在するため許可される
C. 先に作成されたポリシーが優先される
D. 2つのポリシーが相殺されて再評価される
答えと解説
答え:A
適用される明示的な拒否は許可より優先します。
Q9 — 単一選択IAM プリンシパルがあるAWS APIを呼び出した。適用されるポリシーにはそのアクションへの明示的な拒否はないが、許可も存在しない。結果はどれか。
A. 明示的な拒否がないため許可として評価される
B. 認証済みプリンシパルであればデフォルト許可になる
C. 明示的な許可が存在しないため、暗黙的な拒否として評価される
D. リソースベースのポリシーの有無に関係なくリソース所有者の権限を継承する
答えと解説
答え:C
AWSの権限評価では明示的な許可がないリクエストは暗黙的な拒否です。明示的な拒否がないこと自体は許可を意味しません。
Q10 — 複数選択:3つ選択エンタープライズアクセスの基本設計として適切なものを3つ選択してください。
A. 人アクセスではIAMユーザー + MFAを標準とし、フェデレーションは多数アカウントの場合だけ利用する
B. ワークロードでは固定アクセスキーをSecrets Managerへ保存し、自動ローテーションする方式を標準にする
C. 人アクセスではフェデレーションと一時的な認証情報を基本にする
D. AWSワークロードではIAMロールを基本にする
E. 長期認証情報が不可避な用途だけIAMユーザーを限定検討する
答えと解説
答え:C / D / E
人・ワークロード・レガシー制約を分けて認証情報方式を選択します。フェデレーション/ロールを基本とし、長期認証情報は例外へ限定します。
Q11 — 複数選択:3つ選択IAMポリシーを最小権限へ近づけるとき、直接評価すべきポリシー要素を3つ選択してください。
A. アクション
B. リソース
C. 条件
D. Sid
E. バージョン
答えと解説
答え:A / B / C
最小権限では許可するアクション、対象リソース、利用条件を必要範囲へ絞ります。Sidやポリシーバージョンは権限範囲そのものを狭めません。
Q12 — 単一選択AWS Organizations配下の多数のメンバーアカウントについて、長期ルート認証情報を減らしながら、必要な特権操作には対応できるようにしたい。現在のAWSで最も適切な基本方針はどれか。
A. 各メンバーアカウントのルート認証情報を維持し、通常管理にも利用できる緊急用認証情報として中央保管する
B. ルートアクセスを一元管理し、不要なメンバーアカウントのルート認証情報を削除して、対応する特権操作は短期の特権ルートセッションで実行する
C. 全メンバーアカウントのルート認証情報を管理アカウントへ移管し、管理アカウントのルートユーザーから子アカウントへ直接サインインする
D. AWS IAM Identity Centerの権限セットへルート権限を割り当て、ルート専用操作を通常のSSOセッションとして実行する
答えと解説
答え:B
AWS Organizationsのメンバーアカウントでは、IAMでルートアクセスを一元管理し、不要な長期ルート認証情報を削除できます。対応する特権操作は短期の特権ルートセッションで実行し、ルートサインインが必要な例外操作だけ必要に応じて認証情報を復旧します。