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

正解：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　失敗が判明するまでの時間が短くなるだけで根本原因は残り、カスタムリソースは同じ理由で失敗し続ける

正解：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 時間分のセッションが失われ、復元とエンドポイント切り替えの間はダウンタイムも生じる。可用性対策としては不十分

正解：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 ライフサイクルで 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 上に保持される期間は要件どおりの暗号化がされず、保管時暗号化の要求を満たさない

正解：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 呼び出し以外のサービスイベントは記録対象にならない

正解：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 を条件に含めると、その値を知る呼び出しだけがロールを引き受けられるため、第三者による混乱した代理問題を防止できる