DOP（DevOpsエンジニア プロフェッショナル）の問題集を初めて開いたとき、問題文の長さに面食らう方がほとんどです。1問あたり200〜400文字のシナリオが続き、選択肢も4つすべてが「それっぽい」構成になっています。SAA（ソリューションアーキテクト アソシエイト）の知識がある方でも、DOPの問題形式には別の読み方が必要です。
私がDOP（DevOpsエンジニア プロフェッショナル）を受験したとき、ECSの設定問題が想定以上に出て少し焦りました。ただ、「複数サービスの連携の中でどれが最も運用コストを下げるか」という問いの軸さえ掴んでいれば、初見のシナリオでも絞り込めます。782点で合格できた理由は、知識量より「消去の基準」を持っていたことだと考えています。
この記事ではDOP-C02の解法テクニック3つと、D1〜D6の各分野から選んだ例題6問を実演する構成です。
DOP対策記事の一覧
この記事はDOP（DevOpsエンジニア プロフェッショナル）対策シリーズの1本です。
テーマ | 記事 |
|---|---|
DOPの全体像 | |
勉強方法と難易度 | |
サンプル問題の解き方 | この記事 |
→ この記事では「DOPのサンプル問題と解き方」を、分野別の例題で実演します。
DOP問題の特徴：75問・180分・6分野
DOP-C02は75問・180分の試験です。1問あたり2分24秒が目安ですが、実際はシナリオを読むだけで1分以上かかる問題が普通にあり、最初の5問で20〜30分使ってしまう人も少なくありません。体感としては最後まで余裕がない試験です。
試験ガイドが定める6分野の配点はこうなっています。
分野 | 配点 | 主なテーマ |
|---|---|---|
D1 SDLCのオートメーション | 22% | CodePipeline・CodeBuild・CodeDeploy |
D2 設定管理とIaC | 17% | CloudFormation・CDK・Systems Manager |
D3 耐障害性の高いクラウドソリューション | 15% | Auto Scaling・Route 53・マルチリージョン |
D4 モニタリングとロギング | 15% | CloudWatch・X-Ray・OpenSearch |
D5 インシデントとイベントへの対応 | 14% | EventBridge・Lambda・Systems Manager Automation |
D6 セキュリティとコンプライアンス | 17% | Organizations・SCP・Secrets Manager |
出典: AWS Certified DevOps Engineer – Professional (DOP-C02) 試験ガイド
配点が最も高いD1は SDLC（ソフトウェア開発ライフサイクル）のオートメーション、2番目のD2は設定管理とIaC（Infrastructure as Code）です。つまりCI/CDとインフラ自動化の設計判断がこの試験の中心テーマになります。
DVA（デベロッパー アソシエイト）との最大の違いは出題スタイルです。DVAは「このAPIの動作は？」のようなサービス単体の理解を問います。一方DOPは複数サービスが連携するシナリオの中で「最もコスト効率が高い構成」や「最も運用負荷が低い方法」を選ぶ形式が中心です。知識を問う試験から判断を問う試験へ、という感覚の違いに最初戸惑いました。
比較項目 | DVA（デベロッパー アソシエイト） | DOP（DevOpsエンジニア プロフェッショナル） |
|---|---|---|
問題スタイル | サービスの機能・APIを問う | 複数サービスの連携シナリオを問う |
問題文の長さ | 比較的短い | 長い（1問200〜400文字が普通） |
選択肢の内容 | 機能の正誤 | 運用コスト・実装工数・最適な組み合わせ |
難易度 | アソシエイト | プロフェッショナル |
問題文を読むだけで時間を消費してしまうのはこの長さのためです。次のセクションの解法テクニックを使えば読解時間を短縮できます。
解法テクニック3つ
テクニック1：「最小権限・最小工数」で消去する
DOPの設問には「最もコスト効率が高い」「最も運用負荷が低い」「最小工数で」というフレーズが繰り返し登場します。このフレーズが出たら、手動操作・自前実装・個別設定が含まれる選択肢は真っ先に除外してください。
除外の判断基準はシンプルです。
- 「100アカウントに個別に設定する」→ 手動・個別 → 除外
- 「Lambda関数を自作して監視する」→ 自前実装 → AWSマネージドサービスが正解になりやすい
- 「手動実行して確認する」→ DevOpsの文脈では自動化が前提 → 除外
4択を2択まで絞れれば、残りは具体的なサービス知識で決めます。
テクニック2：マネージドサービスを優先する
「最小工数」「最もコスト効率」と聞かれたら、完全マネージドサービスを選ぶのが正解になりやすいパターンです。
典型的な置き換えパターン:
- EC2上のJenkins → CodePipeline + CodeBuild（マネージド）
- EC2上の監視スクリプト → AWS Config + Systems Manager Automation
- 手動ドリフト検知 → AWS Config ルールによる継続的評価
DOPのタスクステートメントでは運用負荷の最小化が繰り返し求められており、インフラ管理の手間を減らす方向の選択肢が正解になるパターンが多いです。
テクニック3：IaCの一貫性を意識する
CloudFormationやCDKで管理しているインフラに手動変更が加わったとき、DOPでは「どうやって検知・修正するか」という問いが頻出です。
以下の3パターンを押さえてください。
- 差異の検知 → AWS Config（継続的評価）
- 差異の修正 → Systems Manager Automation ドキュメント
- 手動変更の防止 → SCPs（Organizations）でAPI操作を制限
「IaCで定義した状態と実際の状態が一致していること」を維持するためにどのサービスを組み合わせるか、という問いの軸を意識すると消去が速くなります。
例題6問：分野別の思考プロセス実演
例題1：D1 SDLCのオートメーション — Blue/Greenデプロイとカナリアテスト
ある企業が、ALBを前面に配置したAuto ScalingグループのEC2インスタンスにデプロイされているレガシーアプリケーションの新バージョンをデプロイする計画を立てています。サービスの中断を避けるため、すべてのトラフィックが新バージョンに移行される前にカナリアテストを実施する必要があります。この要件を満たすソリューションはどれですか？
A. Blue/Green環境として新バージョンのALB + Auto Scalingスタックを準備し、Route 53の加重エイリアスAレコードで2つのALBへのトラフィックを調整する
B. Blue/Green環境として新バージョンのALB + Auto Scalingスタックを準備し、CloudFront Webディストリビューションで2つのALBへのトラフィックの重み付けを調整する
C. CodeDeployのLambda用カナリアデプロイメント設定（Canary10Percent30Minutes）を使用してカナリアデプロイメントを実行する
D. API GatewayのALBとのプライベート統合を設定し、新バージョン用に別ステージを準備してカナリアリリースデプロイメントを実行する
思考プロセス
設問の軸は「サービス中断なし」と「カナリアテスト（段階的トラフィック移行）」の2条件です。
最初に私が目を引かれたのはCでした。「Canary10Percent30Minutes」という具体的な設定名が正解っぽく見えたためです。でも設問の対象がEC2 + ALBであることを再確認して除外しました。
消去していきます。
- C：Lambda用のカナリア設定であり、EC2 + ALBのアプリケーションには使えない → 除外
- D：API Gatewayのプライベート統合は過剰な設計。既存のALB構成にAPI Gatewayを挟む必要はない → 除外
- B：CloudFrontにはALB間の重み付けルーティング機能がない。オリジンフェイルオーバーはあるが、トラフィック比率の調整はできない → 除外
正解：A（Blue/Green + Route 53 加重ルーティング）
新バージョンのスタックを並行稼働させ、Route 53の加重エイリアスレコードでトラフィック比率を制御します。最初は10%だけ新環境に流し、問題なければ段階的に100%へ移行する運用が可能です。
「EC2 + ALB構成のカナリアテスト → Route 53 加重ルーティング」のパターンを覚えてください。CodeDeployのカナリア設定はECSやLambda用で、EC2 + ALB構成には適用できません。Route 53はDNSレベルでのトラフィック分割を担います。
例題2：D2 設定管理とIaC — CloudFormation AMI自動取得
企業がAWS CloudFormationでAuto ScalingグループのEC2インスタンスを管理しています。新しいAMIが利用可能になるたびにCloudFormationテンプレートを手動で更新しており、人的ミスと管理オーバーヘッドが発生しています。このプロセスを自動化する最もコスト効率の良いソリューションはどれですか？
A. CloudFormationテンプレート内でLambdaをバックエンドとしたカスタムリソースを使用して最新のAMI IDを取得し、起動テンプレートリソースブロックで参照する
B. CloudFormationテンプレートの条件文で新しいAMIを確認し、cfn-initヘルパースクリプトで新しいAMI IDを取得して起動テンプレートで参照する
C. AMIマッピングを使用し、EventBridge + Lambdaで1時間ごとにAMIを検出してマッピングを更新する
D. EC2インスタンスでカスタムシェルスクリプトを1時間ごとに実行し、新しいAMI検出時にCloudFormationテンプレートの起動テンプレートを直接更新する
思考プロセス
設問の軸は「AMI更新の自動化」「人的ミスの排除」「最もコスト効率」の3条件です。
消去していきます。
- D：EC2インスタンスでシェルスクリプトを実行する自前実装。インスタンスの運用コストもかかる → 除外
- C：EventBridge + Lambdaの定期実行でマッピングを更新する方式は動作しますが、CloudFormationテンプレート自体を外部から書き換えるのはIaCの原則に反する → 弱い
- B：cfn-initはインスタンス起動時の設定ツールであり、AMI IDの動的取得には適していない → 除外
正解：A（CloudFormation カスタムリソース + Lambda）
CloudFormationのカスタムリソースはスタック作成・更新時にLambda関数を呼び出し、その戻り値をテンプレート内の他のリソースで参照できます。Lambda関数がEC2 APIで最新のAMI IDを取得し、起動テンプレートに渡すフローが最もIaCの原則に沿った自動化です。
「CloudFormationで外部データを動的に取得 → カスタムリソース（Lambda）」のパターンはD2で頻出します。テンプレートを外部スクリプトで直接書き換える方式はIaCの一貫性を壊すので、DOPでは選ばないのが原則です。
出典：AWS CloudFormation — カスタムリソース
例題3：D3 耐障害性 — マルチリージョン災害復旧
ALB + Auto Scaling + RDS MySQLで構成されるアプリケーションをCloudFormationで管理しています。災害復旧シミュレーションで復旧時間が長くデータ損失が過大だったため、IT監査に不合格となりました。最短の復旧時間と最小のデータ損失を実現するマルチリージョンDR計画はどれですか？
A. 別リージョンでCloudFormationスタックを起動し、S3クロスリージョンレプリケーションを有効化する。ALBで他リージョンにトラフィック分散し、RDSマルチAZで可用性を確保する
B. 別リージョンでスタックを起動し、別リージョンにRDSスタンバイDBを作成する。S3クロスリージョンレプリケーションを有効化し、フェイルオーバー時にスタンバイDBを自動昇格させる
C. 別リージョンでスタックを起動し、EventBridge + Lambdaで日次のRDSクロスリージョンスナップショットを取得する。S3をGlacierにレプリケーションし、障害時にスナップショットから復元する
D. 別リージョンでスタックを起動し、RDSリードレプリカを別リージョンに作成する。S3クロスリージョンレプリケーションを有効化し、フェイルオーバー時にリードレプリカをマスターに昇格させる
思考プロセス
設問の軸は「最短の復旧時間（RTO）」と「最小のデータ損失（RPO）」の2条件です。
消去していきます。
- A：RDSマルチAZは同一リージョン内の冗長化。リージョン障害には対応しない → 除外
- C：日次スナップショットではRPOが最大24時間。「最小のデータ損失」を満たさない。S3→Glacierは復元に時間がかかる → 除外
- B：「スタンバイDBを自動昇格」という仕組みはRDSのクロスリージョン構成には存在しない。マルチAZのフェイルオーバーとの混同 → 除外
正解：D（RDSクロスリージョンリードレプリカ + S3クロスリージョンレプリケーション）
RDSクロスリージョンリードレプリカは非同期レプリケーションでデータを別リージョンに常時複製します。障害時にリードレプリカをマスターに昇格させることで、RTOとRPOの両方を最小化できます。S3のクロスリージョンレプリケーションで静的コンテンツも同期する構成です。
「マルチリージョンDR + 最小RTO/RPO → RDSクロスリージョンリードレプリカ」のパターンはD3の定番です。マルチAZ（同一リージョン）とクロスリージョン（別リージョン）を混同しないこと、日次スナップショットではRPOが長すぎることを押さえてください。
例題4：D4 モニタリングとロギング — 集中ログソリューション
急成長中の企業がAWS Organizationsで複数のAWSアカウントを管理しています。コンプライアンス目的で、すべてのサブアカウントからのVPCフローログとCloudWatch Logsを専用の監査アカウントに集約する必要があります。ログは検索・分析のために適切にインデックス化される必要があります。最も適切なソリューションはどれですか？
A. 監査アカウントでKinesis Data Streamsにストリームを作成し、Lambda関数でOpenSearchクラスターに送信する。CloudWatchサブスクリプションフィルターでサブアカウントのログをKinesisにストリーミングする
B. 監査アカウントでSQS FIFOキューを作成し、ログをOpenSearchクラスターにプッシュする。CloudWatchサブスクリプションフィルターでサブアカウントのログをSQSに送信する
C. 監査アカウントの大きなEC2インスタンス上にセルフホスト型OpenSearchクラスターを構築し、Lambda関数でログをプッシュする
D. 監査アカウントでLambda関数を作成し、サブアカウントのCloudWatchサブスクリプションフィルターから直接ログを受信してOpenSearchに送信する
思考プロセス
設問の軸は「マルチアカウント集約」「検索・分析可能なインデックス化」「最も適切」の3条件です。
消去していきます。
- B：SQS FIFOキューからOpenSearchへの直接プッシュはネイティブに対応していない → 除外
- C：EC2上のセルフホスト型OpenSearchは運用負荷が高い。マネージドサービスが存在する以上、選ばない → 除外
- D：Lambda関数で直接受信する方式はアカウント数が増えるとサブスクリプションフィルターの管理が複雑になる。Kinesisを介した方がスケーラブル → 弱い
正解：A（Kinesis Data Streams + Lambda + OpenSearch）
Kinesis Data Streamsがバッファとして機能し、Lambda関数がデータをOpenSearchに送信するパイプラインです。CloudWatchサブスクリプションフィルターで各アカウントのログをKinesisにストリーミングする構成が、マルチアカウント環境で最もスケーラブルです。
「マルチアカウントの集中ログ → CloudWatch Logs サブスクリプションフィルター + Kinesis（またはData Firehose）」のパターンはD4で頻出します。SQSは非同期処理向きでログストリーミングには適していない点、セルフホスト型はマネージドの代替がある限り選ばない点を押さえてください。
出典：Amazon CloudWatch Logs — サブスクリプションフィルター
例題5：D5 インシデントとイベントへの対応 — S3イベント駆動のECSタスク制御
企業がAWS Fargate上でバッチジョブを実行しています。S3バケットにZIPファイルがアップロードされるたびにジョブがトリガーされます。コスト削減のためECSタスクの最小数を1に設定し、S3にオブジェクトが再アップロードされたときのみタスク数を増やしたいです。処理完了後はバケットを空にしてすべてのECSタスクを停止します。バケットではオブジェクトレベルのログ記録が有効です。最も簡単な実装方法はどれですか？
A. EventBridgeルールでS3のPUT操作を検出し、Lambda関数でECSキャパシティプロバイダーの希望タスク数を更新する。別のEventBridgeルールでDELETE操作を検出し、Lambdaでキャパシティプロバイダーをスケールダウンする
B. EventBridgeルールでS3のPUT操作を検出し、ECSクラスターをターゲットとして新しいECSタスクを実行する。別のEventBridgeルールでDELETE操作を検出し、Lambda関数ですべてのECSタスクを停止する
C. CloudTrailに記録されるS3操作に対してCloudWatch Alarmsを設定する。ECSタスク数を増減するための2つのLambda関数を作成し、アラームのターゲットとして設定する
D. CloudTrailに記録されるS3操作に対してCloudWatch Alarmsを設定する。アラームアクションでECSタスク数をスケールアウト/スケールインする
思考プロセス
設問の軸は「S3イベント駆動」「ECSタスクのスケール制御」「最も簡単」の3条件です。
AとBの差がわかりにくい問題でした。どちらもEventBridge + S3 PUT検出で始まる同じ構造に見えたため、少し迷いました。違いは「Lambdaを経由するかどうか」の1点で、Bの方がLambda関数を1つ省略できる点が決め手です。EventBridgeがECSクラスターを直接ターゲットにできることを知らないと判断が難しい問題です。
消去していきます。
- C・D：CloudTrail + CloudWatch Alarmsの組み合わせは間接的で遅延が大きく、構成も複雑 → 除外
- A vs B：AはLambda関数でキャパシティプロバイダーの設定を更新する間接的な方式。BはEventBridgeからECSクラスターを直接ターゲットにしてタスクを起動できるため、Lambda関数が1つ少なくて済む
正解：B（EventBridge → ECSクラスター直接ターゲット + Lambda停止）
EventBridgeはECSクラスターを直接ターゲットとしてRunTaskを実行できます。タスク起動時にLambda関数が不要な分、Aより実装がシンプルです。タスク停止時はStopTask APIの呼び出しが必要なのでLambda関数を使います。
「EventBridgeのネイティブターゲット」を知っていると消去が速くなります。ECSクラスター（RunTask）やStep Functionsは直接ターゲットに指定できるため、Lambda関数を介す必要がありません。「Lambda不要の選択肢があれば、そちらが最小工数」と判断してください。
例題6：D6 セキュリティとコンプライアンス — CloudFormationデプロイのガバナンス
企業がCloudFormationでインフラをデプロイしています。デプロイを2つの特定リージョンに制限し、厳格なタグ付け要件を実装する必要があります。開発者は同じアプリケーションの様々なバージョンをデプロイでき、かつリソースがビジネスポリシーに準拠してデプロイされることを保証したいです。最も適切なソリューションはどれですか？
A. 承認済みのCloudFormationテンプレートを使用してStackSetsを起動する
B. CloudFormationドリフト検出オペレーションで未承認のStackSetsを検出し修正する
C. AWS Trusted Advisorチェックで未承認のStackSetsを検出し修正する
D. AWS Service Catalogを使用し、承認済みのCloudFormationテンプレートで製品を作成する
思考プロセス
設問の軸は「リージョン制限」「タグ付け強制」「開発者の柔軟性」「ポリシー準拠」の4条件です。「制限」と「柔軟性」の両立がポイントです。
消去していきます。
- B：ドリフト検出はデプロイ後の差異を検知する機能で、デプロイ前のポリシー制御はできない → 除外
- C：Trusted Advisorはベストプラクティスのチェックツールであり、CloudFormation StackSetsの制御機能はない → 除外
- A：StackSetsはマルチアカウント・マルチリージョンのデプロイに使うが、リージョン制限やタグ付け強制のガバナンス機能は持っていない → 弱い
正解：D（AWS Service Catalog）
Service Catalogは承認済みのCloudFormationテンプレートを「製品」として管理し、開発者に提供できます。ポートフォリオに対してリージョン制限やタグ付け要件を設定でき、開発者はその範囲内でバージョンを選んでデプロイできます。「制限」と「柔軟性」の両立が可能です。
「CloudFormationのガバナンス（リージョン制限・タグ強制・承認済みテンプレートの提供）→ Service Catalog」のパターンはD6で頻出します。StackSetsは「どこにデプロイするか」を制御し、Service Catalogは「何をデプロイしてよいか」を制御するという違いを押さえてください。
出典：AWS Service Catalog — 管理者ガイド
AWS公式サンプル問題の所在
DOP-C02の公式サンプル問題はAWS認定のページで無料公開されています。本番に近い形式で作られているため、まずここで感触をつかむのが最短ルートです。
- DOP-C02 公式サンプル問題（PDF） — 10問・日本語
公式サンプルを解いた後、「あ、この長さが普通なのか」と実感してから問題集に入ると心理的な準備ができます。先に問題集だけ解き始めると、本番の問題文の長さに面食らうかもしれません。
よくある質問
Q. DOPの問題はDVAと比べてどのくらい難しいですか？
問題文の長さと判断の深さが違います。DVAは「このAPIで何ができるか」の知識問題中心ですが、DOPでは「複数サービスの組み合わせでどれが最もコスト効率・運用効率に優れるか」を選ぶ設計判断が必要です。知識量より「消去の基準」を持っているかどうかで合否が決まります。実際の試験では「4つの選択肢が全部正しく見える」瞬間が何度もあり、そこで軸を持っているかどうかが効いてきます。
Q. 問題文が長くて時間が足りなくなりそうです。対策はありますか？
問題文を頭から全部読むと時間を使います。最後の設問文（「最も適切な方法はどれですか？」など）を先に読んでから選択肢に目を通すと、読む量を絞れるのでおすすめです。「最小工数」「最もコスト効率」「継続的に」などのキーワードを先に把握すると、本文を読みながら消去の基準が立ちます。私も本番では「1分迷ったらフラグ立てて次へ」を徹底し、後半に回す問題を切り分けていました。
Q. Tutorials Dojoと日本語問題集はどちらがいいですか？
どちらか一方ではなく、両方使うのが効果的です。Tutorials Dojo（英語）を使ったRedditユーザーの多くが「本番より難しかった」と言います。難しい問題集で練習することで、本番の問題が相対的に解きやすく感じられます。日本語問題集は解説の丁寧さが強みなので、理解を深める段階で使うといいでしょう。
Q. DOPの合格点は何点ですか？
AWS公式は合格スコアを非公開としていますが、受験者の報告から720〜750点付近が目安とされています。1,000点満点のスケールドスコアで採点されます。
出典：AWS認定 FAQs
次に読む
この記事の例題6問が解けた方は、勉強方法の全体像に戻って計画を整えてみてください。
- AWS DOPの勉強方法と難易度 — 合格までのロードマップ
- AWS DOP完全ガイド — 試験の全体像と受験要件
この記事を書いた人 — スピードスタディ編集部。AWS認定資格（CLF/SAA/SOA/DVA/SAP/DOP）を保有するエンジニアが、AWS資格対策の学習プラットフォーム「スピードスタディ」を開発・運営しています。私はDOP（DevOpsエンジニア プロフェッショナル）を782点で取得しました。
記事内の試験情報はAWS公式ドキュメントに基づいています。最新情報はAWS公式の認定ページでご確認ください。
関連記事:
Speed Study編集部
AWS認定資格の学習をサポートするSpeed Study公式編集部です。