AWS DOP サンプル問題

正解：B

A　SSE-S3の鍵はS3のサービス管理でクロスアカウント共有ができないため、別アカウントのロールは成果物を復号できず取得に失敗する

B（正解）　正解。クロスアカウントの成果物受け渡しではカスタマー管理キーが必須で、キーポリシーとバケットポリシーの双方で相手アカウントの利用を許可する

C　レプリケーションは非同期で実行順序を保証できず、アクションは自身のアーティファクトストアを参照するため構成として成立しない

D　長期認証情報の共有は漏洩リスクが高くベストプラクティスに反する。クロスアカウントはロールの引き受けで解決すべき

正解：C

A　アクションに個別の依存関係属性はなく、同じrunOrderのアクションは一斉に開始されるため承認も同時に走ってしまう

B　runOrderが異なる2つは直列化され、最小値を持つ承認が先頭で実行されるため要件と逆の順序になる

C（正解）　正解。同一runOrderのアクションは並列に実行され、大きいrunOrderのアクションは先行するアクションがすべて成功した後に開始される

D　ステージは必ず順番に実行されるため2つの検査が直列になり、所要時間を短縮したいという要件を満たせない

正解：A

A（正解）　正解。手動承認アクションはSNS通知、レビューURL、コメント記録を標準機能として備えており、追加開発なしで要件を満たす

B　停止と再開の制御を自作することになり、通知や承認理由の記録も別途実装が必要となって運用負荷が上がる

C　ビルドを待機させ続ける間も課金され、タイムアウト管理やコメント検知の仕組みも自作となるため非効率

D　実現は可能だが、ステートマシンとタスクトークンの管理、承認UIの用意まで必要で標準機能で足りる要件には過剰

正解：D

A　実行自体は発生するため課金と失敗通知が残り、パイプラインの成功率も汚れる。トリガー段階で抑止する方が適切

B　変更の有無に関わらず実行されるうえ、infra/の変更が最大24時間反映されないため要件を満たさない

C　モノレポの運用体制そのものを変更する大掛かりな対応であり、最小の構成変更という条件から外れる

D（正解）　正解。V2タイプのパイプラインはブランチ・タグ・ファイルパスによるトリガーフィルターに対応し、設定追加だけで不要な起動を抑止できる

正解：C

A　外部ストアと関数の作り込みが増え、同時実行時に値が混ざる危険もある。パイプラインの変数機能だけで完結できる

B　デプロイアクションは入力アーティファクトを受け取れるが、設定値として使うには追加の解析処理が必要で無駄が生じる

C（正解）　正解。CodeBuildはexported-variablesで変数を公開でき、アクションの名前空間を通じて後続アクションの設定値に埋め込める

D　コミットごとにパイプラインを書き換える運用は自動化の目的に反し、更新漏れによる誤ったイメージのデプロイを招く

正解：B

A　ポーリングは検知までの遅延が大きくAWSも非推奨としており、接続用の資格情報を別途管理する必要も残る

B（正解）　正解。接続はマネージドに保持され、プッシュ時にほぼ即座にパイプラインが起動するため遅延も資格情報の管理負荷も最小化できる

C　トークンの保管とローテーション、実行基盤の維持が必要になり、マネージドな接続を使う場合より運用負荷が高くなる

D　ミラーリングの仕組みを自作することになり、コミット情報も失われて変更のトレーサビリティが低下する

正解：A

A（正解）　正解。CodePipelineは直線的なステージ進行が基本のため、複雑な制御はStep Functionsに委譲し、パイプラインからは単一アクションとして起動するのが定石

B　アクションが失敗するとパイプラインはそこで停止するため、特定の経路だけを無視して先へ進めることはできない

C架空　そのようなサービスは存在しない。CodePipeline自体に条件分岐グラフを定義する機能はない

D　実行はできるが可観測性と再試行の粒度が失われ、失敗箇所の特定やリージョン単位の再実行が困難になる

正解：D

A　1分ごとに10%ずつ増やす設定は10%で10分間留まる要件と異なり、手動での切り戻しは復旧までの時間も長くなる

B　リリースのたびに人手が必要で夜間の異常に即応できない。CodeDeployの定型設定で同じ挙動を自動化できる

C　関数を直接呼び出す経路には効かず、切り戻しもDNSの伝播に依存するため即時性が確保できない

D（正解）　正解。この設定は最初の10%を10分間維持してから残りを移行し、アラーム発報時のロールバックを有効にすれば自動で旧バージョンへ戻る

正解：C

A　起動に失敗するタスクが入れ替わり続けるだけで停滞は解消せず、稼働タスクが減ってサービス断のリスクも高まる

B　完全なサービス断を伴ううえ、不具合があった場合に自動で元へ戻る仕組みも得られない

C（正解）　正解。サーキットブレーカーは新しいタスクの起動失敗が続くとデプロイを打ち切り、直前に安定していたデプロイへ自動的に戻す

D　個々のタスクの終了が早まるだけで、デプロイ全体を失敗と判定して切り戻す仕組みにはならない

正解：A・C

A（正解）　正解。キャッシュにより依存パッケージやベースレイヤーの再取得を回避でき、2回目以降のビルドが大幅に短縮される。buildspecへの追記だけで済む点も要件に合致する

B　タイムアウトはビルドを強制終了するまでの上限にすぎず、延長しても各工程の所要時間は1秒も短くならない。むしろ異常な長時間ビルドの検知を遅らせる副作用がある

C（正解）　正解。依存関係を焼き込んだイメージを使えば、ビルドのたびにダウンロードする工程そのものを削減できる。ビルド定義の変更は環境イメージの指定のみで済む

D　コンピュートを小さくするとCPU・メモリ・ネットワーク帯域がいずれも減るため、ダウンロード中心の処理はさらに遅くなり、ビルド時間は悪化する

E　権限の広さはビルド速度と無関係であり、最小権限の原則にも反する。ボトルネックは依存関係の取得であって、IAMの権限評価ではない

正解：B・D

A　パブリック公開はセキュリティを大きく損なうだけで、クロスアカウントの権限問題は解決しない。必要なのは特定のロールへの明示的な許可

B（正解）　正解。成果物は開発アカウントのS3バケットに保管されるため、本番アカウントのロールに対しバケットポリシーで読み取りを許可する必要がある

C　VPCピアリングはネットワーク到達性の話であり、CodePipelineの成果物取得の可否はS3とKMSの権限設定で決まる

D（正解）　正解。既定のAWS管理キーでは他アカウントから復号できないため、カスタマー管理キーのキーポリシーで相手ロールに復号を許可する

E　長期アクセスキーの平文保管は資格情報漏えいのリスクが高く、クロスアカウントはロールの引き受けで実現するのが正しい方法

正解：A

A（正解）　正解。変更セットは追加・変更・削除されるリソースと置換の要否を実行前に一覧化するため、承認者が破壊的変更を判断してから適用できる

B　ドリフト検出はテンプレートと実リソースの現時点の差分を示すだけで、これから行う更新が置換を伴うかどうかは判定できない

C　cfn-lintは構文やベストプラクティスの静的検査であり、稼働中のスタックに対して実際に置換が起きるかまでは分からない

D　削除と再作成はデータベースを確実に失ううえ長いダウンタイムも生じ、事故防止どころか被害を拡大する対応

正解：B

A　Retainは削除時に残すだけで、置換時の挙動はUpdateReplacePolicyが制御する。手作業が残る点も要件に反する

B（正解）　正解。前者がスタック削除時、後者が更新で置換される時の挙動を制御し、いずれの場合も自動でスナップショットが作成される

C　終了保護はスタック削除操作を防ぐだけで、更新による置換は止められず、スナップショットも作成されない

D　置換を伴う更新自体が失敗するようになるだけで、正当な変更まで阻害され、データ保全の手段にもならない

正解：C

A　猶予期間の延長は異常インスタンスの置換を遅らせるだけで、初期化未完了のインスタンスへの振り分けもスタックの誤った成功判定も防げない

B　台数を増やしても新規インスタンスの初期化完了は待たれないため、初期化中のインスタンスにトラフィックが向かう問題は解消しない

C（正解）　正解。初期化完了後に送られるシグナルをCloudFormationが待つため、準備できたインスタンスだけが投入され、更新の成否も正しく判定される

D　稼働中インスタンスを維持しない設定であり、入れ替え中にサービスが完全に停止するためダウンタイムなしの要件に反する

正解：D

A　参照エラーは消えるが環境ごとの再利用性が失われ、値の変更時に全テンプレートの改修が必要になり運用負荷が増える

B　本番アプリケーションの停止を伴う破壊的な手順であり、更新のたびに繰り返す必要があるため恒久的な解決にならない

C　ネストは1つのライフサイクルにまとめる構成であり、アプリケーションを個別に更新したいという要件とは逆方向の結合強化になる

D（正解）　正解。Exportと異なり参照中でも値を変更でき、ネットワーク側とアプリケーション側を独立したライフサイクルで更新できる

正解：A

A（正解）　正解。CloudFormationは応答が届くまで待ち続けるため、成功・失敗いずれの経路でもS3の事前署名URLに結果を返す実装が必須

B　関数自体は完了しており実行時間は問題ではない。応答が返らない限り、リソースを増やしても待ち続ける状況は変わらない

C　DependsOnは依存順序を制御するだけで、応答が届かないことによるスタックの待機とタイムアウトには影響しない

D　失敗が判明するまでの時間が短くなるだけで根本原因は残り、カスタムリソースは同じ理由で失敗し続ける

正解：C

A　Configは作成された後の検出と修復であり、非準拠バケットが一時的にせよ存在してしまうため事前阻止の要件を満たさない

B架空　このような機能はCloudFormationに存在しない。プロビジョニング前の検査はHooksが担う

C（正解）　正解。Hooksはプロビジョニング前にリソース構成を検査して不適合な操作を失敗させるため、テンプレート側を変更せず横断的に強制できる

D　暗号化の有無に関わらず作成をすべて止めるため開発を阻害し、手動作業を増やして運用負荷も大きくなる

正解：B

A　リソースが作り直されて識別子が変わり、切り替えに伴う影響も避けられないため、再作成禁止という制約に反する

B（正解）　正解。インポートは既存リソースを再作成せずにCloudFormationの管理下へ取り込む機能で、稼働を止めずに識別子も維持される

C　リストアは新しいリソースを生成する操作であり、既存リソースがそのまま管理対象になるわけではない

D　ドリフト検出はスタックに含まれるリソースが対象であり、スタック外のリソースを管理下に取り込む手段ではない

正解：D

A　UPDATE_ROLLBACK_FAILEDのスタックでは通常の更新操作を受け付けないため、変更セットの実行自体ができない

B　削除が許されないという制約に反し、本番リソースの再作成による停止も発生するため選べない

C　ドリフト検出は情報を提供するだけで、失敗したロールバックを再開したりスタックの状態を遷移させたりはしない

D（正解）　正解。ContinueUpdateRollbackにResourcesToSkipを指定してロールバックを再開すると、UPDATE_ROLLBACK_COMPLETEへ戻せる

正解：D

A　OUの構成を変更できないという制約に反する。運用都合で組織階層を動かすことにもなり影響範囲が読みにくい

B　自動デプロイによって再作成されるため恒久的な除外にならず、削除作業も繰り返し発生する

C　スタックインスタンス自体は作成されて管理対象に残り、アカウントが増減するたびに条件の保守が必要になる

D（正解）　正解。サービスマネージド型のデプロイターゲットはOU指定に加えてアカウントフィルターを持ち、特定のアカウントだけを対象から差し引ける

正解：B

A　登録解除の遅延は正常なターゲットを外す際に処理中のリクエストを待つための設定で、異常インスタンスの置き換えとは無関係。実効容量の目減りは解消しない

B（正解）　正解。ELBのヘルスチェック結果をAuto Scalingが異常とみなして置き換えるようになる。猶予期間を起動時間より長くしないと、起動途中のインスタンスが誤って終了される

C　終了ポリシーはスケールイン時にどのインスタンスを選ぶかの規則にすぎず、異常検知の契機にはならない。応答しないインスタンスが残る問題は解決しない

D　判定を緩めると異常なターゲットにリクエストが送られ続け、利用者への影響がむしろ悪化する。自動復旧の仕組みにもならない

正解：C

A　しきい値を下げても障害時には結局EC2の起動が必要になり、APIのスロットリングや容量不足という根本原因は残る

B　自動化しても復旧が制御プレーンの成否に依存する点は変わらない。AZ障害時は起動要求が集中し、必要な速度で容量が揃う保証がない

C（正解）　正解。静的安定性の考え方で、障害時に制御プレーンの操作（インスタンス起動）へ依存しないよう、あらかじめ余剰容量を各AZに確保しておく

D　予約を1つのAZに集中させると、そのAZが失われたときに予約ごと使えなくなる。キャパシティ予約はAZごとに分散して保持する必要がある

正解：D

A　昇格対象からは外れるが、インスタンスとレプリケーションの追加コストおよび運用が発生し、追加コストをかけないという要件に反する

B　インスタンスエンドポイントを直接指定すると、フェイルオーバー後も接続先が旧ライターのままとなり可用性がむしろ低下する

C　分析基盤の作り直しが必要なうえ、昇格順序という根本問題は解決しない。Serverless v2のリーダーも昇格対象になり得る

D（正解）　正解。昇格階層は0〜15で数値が小さいリーダーが優先的に昇格するため、分析用を15などにすれば同クラスの本番用リーダーが先に選ばれる

正解：A

A（正解）　正解。NLBはクロスゾーン負荷分散が既定で無効のためAZ単位で均等配分される。有効化すると全ターゲットへ均等に分散される（AZ間転送料が発生する）

B　ルーティングアルゴリズムはAZ内でのターゲット選択方法を変えるだけで、AZ単位に均等配分するという既定動作は変わらない

C　NLBは単一のDNS名でAZごとのノードIPを返すため、台数変動のたびに重みを保守する必要があり運用が複雑になる

D　クライアント改修と二重管理が必要になる。設定1つで解決できる問題に対して過剰かつ複雑な対応

正解：C

A　二重書き込みはアプリケーション改修が前提で要件に反する。整合性の担保や切り替えロジックも自前で持つ必要がある

B　シャード分割はスループットと容量のスケール手段であり、レプリカがなければノード障害でそのシャードのデータは失われる

C（正解）　正解。プライマリエンドポイントを維持したままレプリカが自動昇格するため、接続先を変えずに単一障害点を除去できる

D　最大1時間分のセッションが失われ、復元とエンドポイント切り替えの間はダウンタイムも生じる。可用性対策としては不十分

正解：D

A　ブルー/グリーンとしては成立するが、グループとターゲットグループの二重管理や切り戻し手順を自前で組む必要があり運用負荷が高い

B　既定バージョンの更新は新規起動にしか効かず、既存インスタンスは置き換わらない。完了時期も容量維持も制御できない

C　実行中インスタンスとAMIがドリフトし、次に起動するインスタンスは古いままになる。不変インフラの方針にも反する

D（正解）　正解。インスタンスリフレッシュは最小正常率（90%）を保ちながら段階的に置き換え、チェックポイントで一時停止して検証・中断できる

正解：B

A　運用負荷が大きいうえ、スポット中断やヘルスチェック異常による自動終了は防げないため取りこぼしは残る。要件のスケールイン継続にも反する

B（正解）　正解。Terminating:Waitでインスタンスを保留し、その間にログ退避を実行してCompleteLifecycleActionで解放できる。ハートビートで延長も可能

C　クールダウンはスケーリング動作の間隔を制御するだけで、個々のインスタンスが終了するまでの猶予時間は生まれない

D　終了保護はスケールイン対象から除外する設定であり、そもそも縮退できなくなる。ログ退避の仕組みにはならない

正解：C

A架空　そのような機能は存在しない。事前初期化にはウォームプール、需要の先読みには予測スケーリングという実在の機能を使う

B　猶予期間は起動直後の誤った異常判定を防ぐだけで、容量が揃う速度は変わらない。エラー率の上昇は解消しない

C（正解）　正解。ウォームプールは初期化を終えたインスタンスを停止（または休止）状態で保持し、スケールアウト時は起動するだけで投入できる。停止中の課金はEBSなどに限られる

D　クールダウンを詰めても1台あたり12分という起動時間は短縮されず、過剰なスケールアウトを招くだけになる

正解：C

A　ポーリング実装をアカウントごとに配布・保守する必要があり、APIのスロットリングや重複取得の制御も自作になるため運用負荷が高くなる

B　エクスポートタスクはバッチ処理で完了まで時間がかかり、準リアルタイム要件を満たさない。アカウントごとのスケジュール管理も残る

C（正解）　正解。クロスアカウントのデスティネーションはアクセスポリシーで組織全体に共有でき、送信側はサブスクリプションフィルタを付けるだけで準リアルタイムに転送される

D　CloudWatch Agentはホスト上のログやメトリクスを送信するエージェントであり、他アカウントのロググループを引き抜く用途には使えない

正解：B

A　自作スクリプトの保守、認証情報の配布、API呼び出しのリトライ制御まで自前になり、標準化された収集基盤に比べて負荷が大きくなる

B（正解）　正解。エージェント設定をParameter Storeで一元管理し、Systems Managerからハイブリッド有効化したオンプレサーバーを含めて一斉に配布・更新できる

C　詳細モニタリングは1分粒度になるだけでメモリやディスク使用率は取得できず、オンプレサーバーのOSメトリクスも対象外である

D　Inventoryはソフトウェア構成や設定情報の棚卸しが目的で、継続的なメトリクスやアプリケーションログの収集機能ではない

正解：D

A　検索性は残るが、7年分をCloudWatch Logsに置き続けるためS3へ退避する構成よりも保管コストが大幅に高くなる

B　エクスポートタスクは同時実行数の上限やタスク管理の作りこみが必要で、取りこぼし時の再実行制御も自作になるため継続転送より運用負荷が高くなる

C　請求アラームはコストの通知にすぎず、7年保持の要件を満たすアーカイブそのものは実現されない。手動運用も現実的ではない

D（正解）　正解。CloudWatch Logs側は短期保持でコストを抑え、Firehoseによる継続配信でS3へ集約できる。S3側でライフサイクルルールによりGlacierストレージクラスへ移行すれば、7年分をさらに安価にアーカイブできる

正解：A

A（正解）　正解。FireLensはFluent Bitの設定でフィルタと複数出力を定義できるため、アプリを変更せずタスク定義だけでルーティングを実現できる

B　コンテナに設定できるログドライバーは1つだけで、awslogsの出力先はCloudWatch Logsのロググループのみである

C　メトリクスフィルタはログをメトリクス化するだけで、ログ本文を他サービスへ配信する機能はない。転送にはサブスクリプションフィルタが必要

D　永続ボリュームを介したバッチ転送はリアルタイム性がなく、タスク終了時のログ喪失リスクもあり、コンテナのログ収集手段として不適切である

正解：C

A　SSE-S3はS3の暗号化オプションであり、CloudWatch Logsのロググループに設定するものではない。キー管理の監査要件も満たせない

B　暗号化は実現できるが、Logs Insightsでの検索やメトリクスフィルタが機能しなくなり、アプリ改修も必要なため要件に対して過剰かつ運用性を損なう

C（正解）　正解。CloudWatch Logsはassociate-kms-keyでカスタマー管理キーを指定でき、キーポリシーとCloudTrailによって利用の管理と監査が可能になる

D　転送後は暗号化されるが、CloudWatch Logs上に保持される期間は要件どおりの暗号化がされず、保管時暗号化の要求を満たさない

正解：B

A　Lambdaはレスポンス返却後に処理が凍結されるためバッファの取りこぼしが起き、同時実行が多い環境ではスロットリングも解消しない

B（正解）　正解。EMFはAPIを呼ばずログ出力だけでメトリクスを生成でき、高カーディナリティの項目はログのプロパティとして保持できる

C　呼び出し回数と実行時間の課題が残るうえコストも増え、高カーディナリティ次元によるカスタムメトリクス料金の増大も解決しない

D　メトリクスストリームはCloudWatchに取り込み済みのメトリクスを外部へ送り出す機能であり、送信元のPutMetricData呼び出しは減らない。スロットリングも実行時間も改善しない

正解：D

A　検知が遅れ重大障害への対応が遅延する。通知数の集中も根本的には解消されず、監視の感度だけを落とすことになる

B　CPU使用率やレイテンシなど単位の異なるメトリクスを演算しても意味のある値にならない。個々のアラームを調査用に残したいという要件にも反する

C　配信ポリシーは配信失敗時の再試行制御であり、別々のアラームから発生する複数通知を束ねる機能ではない

D（正解）　正解。複合アラームは子アラームの状態を論理式で評価し、通知を1本に集約できる。子アラームは調査用にそのまま残せる

正解：A

A（正解）　正解。データポイントが存在しない期間を「しきい値内」として扱うため、トラフィックのない時間帯に状態が変化せず誤通知を防げる

B　ignoreは直前の状態を維持するため、既にALARMだった場合に解除されないまま残る。評価期間の延長も検知遅延を招く

C　通知先を分けるだけで発報自体は続く。むしろINSUFFICIENT_DATAでの通知を明示的に増やす設定であり逆効果である

D　検知の即時性が失われ、クエリ基盤の構築という大きな変更が必要になる。最小の変更という要件に反する

正解：A

A（正解）　正解。S3のEventBridge通知は1本のイベント配信で済み、条件変更もターゲット追加もルール側の変更だけで完結する

B　宛先を増やすたびにバケット設定の変更が必要になり、抽出条件もプレフィックスとサフィックスに限定されるため拡張性が低い

C　オブジェクトレベルのデータイベントは記録コストが大きく配信遅延も増える。ネイティブな通知で足りる場面でCloudTrailを経由させる必然性がない

D　SNSの属性フィルターは発行側がメッセージ属性を設定している前提だが、S3通知はオブジェクトキーを属性として持たないため .pngだけを抽出できない

正解：A

A（正解）　正解。入力トランスフォーマーは入力パスで取り出した値をテンプレートに差し込めるため、追加の実行基盤なしで通知文を整形できる

B　入力パスは値の切り出しだけを行い、複数の値を1つの文章に組み立てることはできない。整形にはテンプレートを伴う入力トランスフォーマーが要る

C　Security Hubには通知本文のテンプレートを定義する機能がなく、検出結果の集約先を増やしても本文の見た目は変わらない

D　フィルターポリシーはメッセージを配信するかどうかを判定するだけで、本文の一部を削ったり書き換えたりする用途には使えない

正解：A

A（正解）　正解。リプレイは期間と再生対象のルールを指定できるため、影響を受けたサービスにだけ過去のイベントを再配信できる

B　再投入したイベントはバス上の全ルールに一致し得るため、正常に処理済みだったほかのサービスにも重複配信されてしまう

C　DLQに入るのはターゲットへの配信自体に失敗したイベントだけで、配信後にサービス内部で処理が失敗したイベントは含まれない

D　EventBridgeは配信済みのイベントをバスに保持しないため、ルールを操作しても過去のイベントが再送されることはない

正解：B

A　EventBridgeのクロスアカウント配信をそのまま使えば済むところに、独自の転送基盤と再試行処理の保守が発生してしまう

B（正解）　正解。イベントバスのリソースポリシーで組織単位のPutEventsを許可し、転送ルールをStackSetsの自動デプロイで配ればアカウント追加時の作業がなくなる

C　ルールは自分のアカウントのイベントバス上のイベントしか評価できず、他アカウントのバスを直接参照する設定は存在しない

D　CloudTrailの配信は数分の遅延があり、インスタンスの状態変化のようなAPI呼び出し以外のサービスイベントは記録対象にならない

正解：C

A　再試行を止めると一時的な障害でも即座に失敗が確定し、通知は届いてもイベント本体を後から再処理する手段が残らない

B　期間指定のリプレイでは成功していたイベントも再配信されるため、処理が冪等でない限り二重処理を引き起こす

C（正解）　正解。ターゲット単位の再試行ポリシーで粘り強く再試行させ、上限に達したイベントはDLQに退避されるので後から再処理できる

D　エラーを隠すとEventBridgeもLambdaも失敗を検知できず、再投入をログからの手作業に頼ることになり運用負荷が上がる

正解：D

A　件数の増加に比例して毎分のスキャンコストが膨らみ、通知の精度も実行間隔に依存するためスケール特性が悪い

B　SQSの配信遅延は最大15分のため、1時間先の通知には再投入のループを自前で組む必要があり実装と失敗時の追跡が複雑になる

C　上限を引き上げても数十万件のルールを管理するのは非現実的で、ルールの棚卸しや削除漏れの運用が破綻する

D（正解）　正解。Schedulerは数百万件規模の一回限りスケジュールを扱え、完了後の自動削除により後始末も不要になる

正解：C

A　実装は可能だがインスタンスの入れ替えが必要で、しきい値の調整のたびにAMIを作り直す運用が発生する

B　ステータスチェックはOSやハードウェアの疎通を見るもので、ディスク使用率の逼迫は検知できず再起動でログも消えない

C（正解）　正解。アラームからAutomationランブックを直接起動でき、実行履歴がSystems Managerに残るため追跡も容易になる

D　ディスク使用率はログの本文ではなくメトリクスとして取得するものであり、台数を増やしても既存インスタンスの空き容量は回復しない

正解：B

A　共通ロールの権限は全関数が必要とする権限の和集合になり、最小権限から大きく乖離する。委任という要件も満たさない

B（正解）　正解。アクセス許可境界の付与を条件で強制すると、作成されたロールの実効権限は境界の範囲内に制限されるため、権限昇格を防ぎつつロール作成を委任できる

C　IAMFullAccessは自身の権限を拡大できるため権限昇格を許す。Configは発見的統制であり、危険なロールが作られる瞬間を止められない

D　ロール作成を委任するという目的に反し、基盤チームの負担も現状のまま変わらない。ガードレールとしては機能するが課題の解決にならない

正解：A

A（正解）　正解。OIDCフェデレーションで長期キーが不要になり、sub条件でリポジトリとブランチを限定することで意図したワークフローだけがロールを引き受けられる

B　audだけではGitHub上の任意のリポジトリのワークフローがロールを引き受けられてしまう。subによる絞り込みが欠かせない

C　ローテーションしても長期認証情報が存在し続けるため、廃止という要件を満たさない。ブランチ単位の制限も実現できない

D　GitHubホストランナーのIP範囲は広大かつ変動し、他の利用者とも共有される。長期キーも残るため要件を満たさない

正解：C

A　最終アクセス情報は原則としてサービス単位の粒度であり、サービス内のどのアクションが使われたかまでは特定できない

B　外部アクセス分析は組織外と共有されているリソースを検出する機能で、ロールの権限使用実績とは無関係

C（正解）　正解。ポリシー生成は指定期間のCloudTrailから実際に呼び出されたアクションを抽出し、アクション単位のIAMポリシーを自動生成する

D　技術的には可能だが、クエリ作成とポリシーの手書きが必要で手作業が多く、最小の手間という要件に反する

正解：D

A　ベンダーの自動化処理はMFAを提示できないため運用が成立しない。そもそも混乱した代理問題への対策ではない

B　ベンダーは自社組織の外部にいるため、この条件を課すとすべてのアクセスが拒否され、連携そのものが成立しない

C　権限と有効期間は狭められるが、ベンダーが顧客を取り違えて自社アカウントを操作する事象そのものは防げない

D（正解）　正解。外部IDを条件に含めると、その値を知る呼び出しだけがロールを引き受けられるため、第三者による混乱した代理問題を防止できる

正解：B

A　集約はできるが共有アカウントに長期キーが残る。各アカウントのロールとポリシーを手作業で同期する必要もある

B（正解）　正解。権限セットを職務ごとに定義して複数アカウントへ割り当てられ、CLIも一時認証情報で動作するため長期キーを完全に廃止できる

C　ローテーションしても長期キーは存在し続け、アカウントごとの棚卸し負荷と権限管理の分散も解消されない

D　Cognitoはアプリケーションのエンドユーザー向けのIDサービスであり、従業員による管理アクセスの標準的な仕組みではない

正解：C

A　SCPにアタッチ先による優先順位という概念はなく、反映は通常ごく短時間。時間の経過では解決しない

B　SCPの明示的なDenyはIAM側の許可があっても最終的に拒否される。IAMポリシーの変更では回避できない

C（正解）　正解。SCPはルートから対象アカウントまでの各階層すべてで許可されて初めて有効になり、いずれかの明示的なDenyが最優先される

D　複数のSCPは同時に評価され、統合は不要。評価が停止するという動作は存在しない

正解：A

A（正解）　正解。RCPはリソース側に組織全体の上限を課すポリシーで、個々のバケットポリシーを変更せずに組織外プリンシパルからのアクセスを拒否できる

B　SCPは組織内アカウントのプリンシパルの権限にしか作用しないため、組織外からのアクセスを制御する用途には使えない

C　パブリック公開は防げるが、特定の外部アカウントを指定したクロスアカウント共有は依然として可能なため要件を満たさない

D　評価と修復は作成後に行われる発見的統制であり、予防的にアクセスを止めるという要件を満たさない