【全出題範囲網羅+詳細解説】AWS DOP-C02日本語実践問題225問(DevOps Engineer Pro)

DOP-C02の全ての出題範囲を網羅した実践問題集です。
AWS DOP（AWS Certified DevOps Engineer - Professional）に合格したい方はもちろんのこと、AWSでDevOps エンジニア ロールを担う方の効率的なSDLC、設定管理、デプロイ能力、トラブルシュート能力、セキュリティ能力を向上するために最適なコースです。

更新履歴

2025/2:  演習問題1~3 に対して以下の修正（レビューのフィードバック）を実施しました。
　　　　 表記ゆれの修正 、問題文と解答を照らし合わせて、問題文側に不足している文章を補足、一部選択肢の表現見直し
　　　　 古い傾向の問題を削除し、最新の傾向の問題に差し替え

2025/5: 演習問題1について大幅な解説強化を行いました。

2025/8: 演習問題2と3について大幅な解説強化を行いました。

2026/2:  出題順序固定版の演習問題を追加しました。※出題順序固定版は演習1~3と同じ問題です。

2026/4: ほぼすべての問題に図解を追加しました。

2026/8: 解説を最新のAWS仕様に合わせて全面刷新しました。

本問題集のサンプル

以下本問題集に収録されている問題サンプルです。ご自身が求めているレベルかを確認してください

問題文：

ある大手旅行予約サイトを運営する企業は、宿泊施設の空室と料金を返す予約APIを Amazon ECS と Application Load Balancer (ALB) の上で稼働させています。このAPIは1日に数十万件の検索リクエストを処理しており、DevOpsエンジニアは毎週のリリースサイクルでコンテナイメージを更新しています。

ある週のリリースで、エンジニアは料金算出の精度を上げるため、起動時に大量の宿泊施設マスタデータをメモリへ読み込む処理を追加した新しいコンテナイメージをタスク定義へ反映しました。その直後から、起動したタスクがALBのヘルスチェックを通過できなくなり、停止と再起動を際限なく繰り返す状態になりました。

この事態を収束させるには、エンジニアはどう対処すべきでしょうか？

選択肢：

A. サービスの望ましいタスク数を引き上げて、同時に起動しておくタスクの本数を増やします。

B. ALBのヘルスチェックの間隔を短縮し、健全性の確認をより頻繁に実行します。

C. ECSサービスのヘルスチェック猶予期間を延長し、タスクが応答できるようになるまでの判定を先送りします。

D. ターゲットグループのヘルスチェックのタイムアウトを延長し、ALBがタスクからの応答を待ち受ける時間を長くします。

正解：C

A. サービスの望ましいタスク数を引き上げて、同時に起動しておくタスクの本数を増やします。

不正解 望ましいタスク数はサービスが維持しようとするタスクの本数であり、数を増やすのは「起動する数」を増やすだけであって「1本あたりの起動にかかる時間」を短くするわけではありません。新しいタスクはどれも同じマスタデータ読み込みを同じ順序で実行するため、1本ずつ見れば同じタイミングでヘルスチェックに落ちて終了します。増やした分のタスクが同時に失敗しては、事態の改善にはつながりません。さらに、この値は今回のデプロイで変更した箇所ではないため、変更点と症状の因果を説明する候補にもなりません。

B. ALBのヘルスチェックの間隔を短縮し、健全性の確認をより頻繁に実行します。

不正解 間隔を短くしても、単位時間あたりのチェック回数が増えるだけで、タスクが応答できるようになるまでの時間は変わりません。初期化が猶予期間に収まらないという根本原因はそのまま残るため、準備が整う前のタスクはチェックのたびに失敗し続けます。いったん異常と判定されたタスクが正常へ戻るには正常しきい値の回数だけ連続成功が必要なので、チェックを頻繁にしても終了と再起動のサイクルは止まりません。調整すべきなのはALB側の頻度ではなく、ECS側の猶予期間です。

C. ECSサービスのヘルスチェック猶予期間を延長し、タスクが応答できるようになるまでの判定を先送りします。

正解 タスクがRUNNINGへ遷移した後も一定時間、サービススケジューラがunhealthyの判定を受け付けないようにするのがヘルスチェック猶予期間です。この間にタスクが初期化を終えて応答できるようになれば、そのままHealthyへ移行します。注意すべきは、猶予期間が止めるのはALBのチェックではなくECS側の評価だけだという点です。ALBは引き続きチェックを投げ続けますが、その結果をスケジューラが無視します。今回の原因は、新しいイメージで起動時に読み込むマスタデータが増えて初期化が長引き、サービスに設定されていたヘルスチェック猶予期間を超えてしまったことです。猶予期間を実測の起動時間に合わせて延ばせば、終了と再起動のループを断ち切れます。

D. ターゲットグループのヘルスチェックのタイムアウトを延長し、ALBがタスクからの応答を待ち受ける時間を長くします。

不正解 タイムアウトが効くのは「応答は返るものの時間がかかっている」状態までです。今回のタスクは、新しいイメージが大量のマスタデータを読み込んでいる間、リクエストをまだ一切受け付けません。この段階で起きているのは応答の遅延ではなく応答の不存在なので、待ち時間をどれだけ延ばしてもヘルスチェックは成功に変わりません。また、エンジニアが今回変更したのはタスク定義のコンテナイメージだけであり、ターゲットグループのタイムアウト設定には一切触れていません。変更していない設定をいじっても、変更点と症状を矛盾なく説明できません。

全体的な説明

問われている要件

• Amazon ECSとALBで運用する宿泊予約APIが、コンテナイメージの更新直後からヘルスチェックに失敗し続け、タスクが終了と再起動を繰り返す状態に陥っていること

• 原因が「新しいイメージで起動時のマスタデータ読み込みが増えて初期化が長引いたこと」にあると特定できること

• 変更点（新イメージの適用）と症状（ヘルスチェック失敗の継続）の因果関係から、調整すべき設定を特定すること

• DevOpsエンジニアとして、この問題を解決する対応を選ぶこと

前提知識 ECSタスクの状態遷移 ECSのタスクは、起動から停止まで以下の状態を遷移します。

1. PROVISIONING: タスクに必要なリソースを確保している状態

2. PENDING: コンテナインスタンスへの配置を待っている状態

3. ACTIVATING: RUNNINGへ移る前の、ターゲットグループへの登録やサービスディスカバリ設定などの追加処理

4. RUNNING: コンテナが実行され、サービスを提供している状態

5. DEACTIVATING: 停止に伴うターゲットグループからの登録解除などの処理

6. STOPPING: SIGTERM送信などの終了処理を待機している状態

7. DEPROVISIONING: リソースを解放している状態

8. STOPPED: 停止済み

ヘルスチェックに失敗し続けたタスクは、サービススケジューラによって異常と判断されて停止され、新しいタスクへ自動で置き換えられます。この置き換えの仕組みが、本問で観測されている「終了して再起動を繰り返す」挙動の正体です。 ALBのヘルスチェック機構 ALBはターゲットグループに登録されたターゲットへ定期的にリクエストを送り、健全性を評価します。主な設定は次のとおりです。

• パス: チェック対象のエンドポイント（例：/status）

• 間隔: チェックを実行する頻度

• タイムアウト: 応答を待つ時間

• 正常しきい値: 異常と判定されたターゲットが復帰するために必要な連続成功回数

• 異常しきい値: 異常と判定されるまでに必要な連続失敗回数

• 新規登録と復帰の非対称: 新規に登録されたターゲットは1回の成功で正常と判定されます。一方、一度異常になったターゲットの復帰には正常しきい値分の連続成功が必要です（間隔30秒・しきい値5回のデフォルトでは、復帰に最大150秒を要します）

ECSサービスのデプロイと猶予期間

• 最低正常率／最大率: デプロイ中に維持・許可されるタスク数の範囲を、望ましいタスク数に対する割合で指定します

• ヘルスチェック猶予期間: タスクが起動してから一定時間、サービススケジューラがElastic Load Balancing・VPC Lattice・コンテナのヘルスチェックの異常結果を無視する期間です。この間もALB自体はチェックを続け、ECS側の評価だけが猶予されます。未指定時の既定値は0秒で、最大2,147,483,647秒まで指定できます

初期化時間を変える要因 コンテナイメージを差し替えると、応答可能になるまでの時間は次のような要因で変わります。

• データベース接続、キャッシュのウォームアップ、設定読み込みなどの起動時処理

• イメージサイズと依存関係の数（ダウンロードと展開の時間に影響します）

• タスクに割り当てたメモリ／CPUの余裕

新しいイメージの初期化が以前より長くなり、猶予期間を超えると、タスクは準備が整う前にunhealthyと評価されて終了と置き換えのサイクルへ落ちます。 ヘルスチェックのチューニング観点

• 猶予期間は実測の起動時間に基づき、余裕（例：平均+10〜20秒）を持って設定します

• チェックエンドポイントは軽量にし、重要なコンポーネントの健全性だけを確認します

• 起動待ちの猶予はALBの間隔ではなくECSの猶予期間で確保するのが正しい分担であり、両者は独立した設定です

• タイムアウトの延長は応答の遅いタスクを許容するだけで、起動が間に合わないことへの対処にはなりません

ヘルスチェック猶予期間の延長は、初期化時間が長くなった場合の最も直接的な対処であり、タスクが応答可能になるまでの窓口をECS側で確保します。

アーキテクチャ図の解説

★本編にはアーキテクチャ図が貼付されます★

猶予期間は ALB のチェックを止めるのではなく、ECS 側の判定を一時的に無視する仕組みです。DevOpsエンジニアが新しいタスク定義を適用すると（①）、ECS Serviceは新イメージでタスクを起動し（②）、タスクはTarget Groupへ登録されます（③）。ALBは登録直後から継続的にヘルスチェックを行い（④）、判定結果をECS Serviceへ報告します（⑤）。猶予期間内に初期化が完了すればタスクはHealthyとして安定し（⑥）、経過後もUnhealthyなら強制終了されて置き換え（⑦⑧）の再起動ループへ入ります。よくある誤読は、猶予期間中ALBもチェックを控えると考えることです。実際にはチェックは止まらず、無視するのはECS側の判定だけなので、ALBの間隔やしきい値を調整しても初期化時間の不足は解消されません。

解くための考え方 変更点と症状の因果から見ます。

変更点と症状を特定する：

• 変更点は、タスク定義を新しいコンテナイメージへ更新したことだけです

• 症状は、ヘルスチェックに失敗し続けてタスクが終了と再起動を繰り返すことです

症状の発生機序を考える：

• 新しいイメージの初期化が重く、猶予期間内に応答可能にならなければunhealthyと判定されます

• unhealthyなタスクは終了・置き換えられ、置き換え先のタスクも同じ失敗を繰り返してサイクルになります

選択肢を評価する：

• 起動から応答可能までの時間を確保する対処かどうか

• 変更点と整合するかどうか（今回変更されていない設定は原因になりません）

新しいイメージの初期化窓口を確保できるのは、ECS側のヘルスチェック猶予期間です。ALB側の頻度やタイムアウトの調整、タスク数の増加は、いずれも1タスクあたりの初期化にかかる時間を変えません。

★本編にはAWS公式ドキュメント公式ドキュメントへのリンクが記載されます★

• Application Load Balancer ヘルスチェックの設定

• Amazon ECS タスクのヘルスチェック

• Amazon ECS サービスの定義パラメータ

• Amazon ECS タスクの起動時間を最適化する

• Amazon ECS のロードバランサーのヘルスチェックパラメータを最適化する

DOP-C02の特徴

実践的なシナリオベースの出題です。単にAWSサービスの機能を理解しておくだけでは点数を取ることは難しいです。長文の問題文を読解し、問われている要点を把握することが大切です。また、どのような要件で各AWSサービスを用いればよいのかを説明できるように力をつけておくことが大切です。

本問題集の特徴

• DOP-C02の出題形式に沿った本番ライクな問題

• 全問題に詳細な解説とAWS公式ドキュメントへのリンクを記載

• 不正解選択肢の理由についての解説

• 長文の問題文から問われている要点を解説