AWS Certified DevOps Engineer – Professional(DOP-C02)に合格したため、振り返ろうと思います。
前提
- AWS実務経験3年ほど
- 以下の順で取得
| 受験日 | 資格 | スコア | 合否 |
|---|---|---|---|
| 2026-02-07 | SAA-C03 | 779 | 合格 |
| 2026-02-21 | SOA-C03 | 743 | 合格 |
| 2026-03-07 | CLF-C02 | 793 | 合格 |
| 2026-03-28 | DVA-C02 | 752 | 合格 |
| 2026-04-04 | SAP-C02 | 717 | 不合格 |
| 2026-04-11 | AIF-C01 | 734 | 合格 |
| 2026-04-11 | DEA-C01 | 731 | 合格 |
| 2026-05-03 | SCS-C03 | 896 | 合格 |
| 2026-05-23 | SAP-C02 | 791 | 合格 |
| 2026-05-30 | MLA-C01 | 737 | 合格 |
| 2026-06-15 | DOP-C02 | 810 | 合格 |
SAPは1回目落ちてます。セキュリティ周りが不足していたのでSCSに軌道修正し、AIFも受けて半額バウチャーを回収(合格したらバウチャーが貰えるのを知らず、CLFは後から回収)
こうやって振り返ると、綱渡りのようなギリギリのラインを攻めていますね。。
学習方法
前提に記載の通り、AWSを実務で触っているため、学習と実践のサイクルがあります(実務で触ってる時間もカウントするならば、実際は倍以上の勉強量になっていたかと思います)
基本的には、「毎日コンスタントに問題を解いていた」です。
補助的にChat GPTで、AWSの思想やDOP特有の知識体系などを整理していました。
知識を定着させるために、「3歩進んで2歩下がる」は、かなり意識していました。
- Cloud Licenseの問題を1日7問ずつ解く
- 夜に7問解く(解説はざっと流し読み程度。解説の最後の「問題の本質」はちゃんと読む)
- 次の日のお昼に前日の7問を復習する(間違いの選択肢がなぜ間違いなのかまで意識する)
- 夜に、次の7問を解く
- 繰り返し
- Chat GPTと壁打ち
- 構造で解ける問題と、暗記してないと解けない問題のパターンを洗い出す
- 構造で解ける=「AWSの思想で解ける」ことを意識しながら、問題を解いていました
- 「暗記していないと解けない問題」は、ほぼ無視していました
- あとは、「AWSは何故このサービスを作ったのか?」を壁打ちするとスッキリします
出題傾向
「こんな感じの問題が多かったなぁ」というのをまとめます。
公式の試験ガイドから出題範囲を抜粋し、それに紐づけて記載してみます。
- 第 1 分野: SDLC のオートメーション (採点対象コンテンツの 22%)
- 本質:安全・確実なコード展開と、成果物(アーティファクト)のライフサイクル管理を完全に自動化する
- 例:AWS CodeDeployを用いたデプロイ戦略において、Amazon CloudWatchアラームと連携して異常検知時に自動ロールバックをトリガーさせ、さらにライフサイクルフックを適切に選択してデプロイ前後のカスタム検証を自動化する設計。
- 例:既存のAWS CodePipelineで構築されたCI/CD環境に対して、Amazon EventBridgeを組み合わせて定期実行や特定のイベント駆動による実行を完全に自動化する手順。
- 例:AWS CodeArtifactでパッケージステータスとオリジン制御を組み合わせて環境分離とパッケージ管理を適正化しつつ、AWS SignerとAWS CodeBuildを連携させてコンテナイメージにデジタル署名を付与するセキュアな成果物パイプラインの構築。
- 本質:安全・確実なコード展開と、成果物(アーティファクト)のライフサイクル管理を完全に自動化する
- 第 2 分野: 設定管理と IaC (採点対象コンテンツの 17%)
- 本質:コードによるインフラ(IaC)定義と、マルチアカウント環境における構成管理・ガバナンス展開の自動化。
- 例:AWS CDKやAWS CloudFormation StackSetsを活用し、AWS Control Towerのガードレール化(AFT(Account Factory for Terraform)の機能フラグによる自動有効化などを含む)を伴うリソースを、マルチアカウント・マルチリージョン環境へ一括して自動展開する仕組み。
- 例:AWS CloudFormationとAWS Systems Manager Parameter Storeを動的に連携させ、テンプレートの再利用性を高めながら常に最新のAMI IDを自動的に参照・プロビジョニングするImmutable Infrastructureの設計。
- 例:既存のコンテナ環境やリレーショナルデータベースをサーバーレスアーキテクチャへ移行する際、運用オーバーヘッドとアーキテクチャの変更を最小限に抑える(最小変更の原則)ための構成管理手法の選定。
- 本質:コードによるインフラ(IaC)定義と、マルチアカウント環境における構成管理・ガバナンス展開の自動化。
- 第 3 分野: 耐障害性の高いクラウドソリューション (採点対象コンテンツの 15%)
- 本質:マルチリージョン/マルチAZにおけるデータ同期と、DNSおよびネットワーク層における高度な自動フェイルオーバー設計。
- 例:Amazon DynamoDB グローバルテーブルとAmazon Route 53のレイテンシールーティング、あるいはAWS Global Acceleratorを組み合わせ、ネットワーク経路を最適化しつつ世界規模で低レイテンシーかつ高可用なマルチリージョン環境を設計する手法。
- 例:仮想サーバー環境において、Application Load Balancer (ALB)のWebSocketやスティッキーセッション要件を維持しつつ、Amazon Route 53 Application Recovery Controller (ARC)のゾーンシフトやヘルスチェック付き加重ルーティングを用いて、AZ(アベイラビリティゾーン)単位の障害を即座に自動回避するDNS設計。
- 例:Amazon S3のクロスリージョンレプリケーションとAmazon CloudFrontのオリジンフェイルオーバー、あるいはAmazon RDS for SQL ServerのマルチAZインスタンスとクロスリージョンリードレプリカを組み合わせた、ステートフルなデータのDR(災害復旧)および高可用性アプローチ。
- 本質:マルチリージョン/マルチAZにおけるデータ同期と、DNSおよびネットワーク層における高度な自動フェイルオーバー設計。
- 第 4 分野: モニタリングとロギング (採点対象コンテンツの 15%
- 本質:分散システムの徹底的な可観測性(Observability)の確保と、大規模ログのリアルタイム集計・解析。
- 例:複雑なマイクロサービスアーキテクチャにおいて、サービスの相互依存関係から発生するパフォーマンスのボトルネックやエラーを即座に特定するための分散トレーシングの設計と実装。
- 例:Amazon CloudWatch Logsのサブスクリプションフィルターを活用し、複数のコンポーネントから出力される大量のシステムログ・アプリケーションログをリアルタイムに処理・転送するストリーミングパイプラインの構築。
- 例:Amazon CloudWatch Logsのメトリクスフィルターを設定することで、ログ内の特定の文字列パターン(エラーコードなど)を検出し、アラートや動的な自動化アクションのトリガーとなるカスタムメトリクスを作成する手法。
- 本質:分散システムの徹底的な可観測性(Observability)の確保と、大規模ログのリアルタイム集計・解析。
- 第 5 分野: インシデントとイベントへの対応 (採点対象コンテンツの 14%)
- 本質:システムやセキュリティの異常をイベントとして捉え、コード化された手順で自動的に復旧・通知を行う自己修復運用の設計。
- 例:Amazon EKSのノード参加失敗など、基盤リソースのプロビジョニングエラーや障害イベントを検知した際に、AWS Systems Manager オートメーションランブックをトリガーして自動的にトラブルシューティングと自己修復(自己復旧)を行う運用の自動化。
- 例:Amazon ECRの拡張スキャン機能とAmazon EventBridgeを連携させ、コンテナイメージの脆弱性をリアルタイムに検知し、セキュリティ管理者への通知やデプロイパイプラインの自動停止を行う仕組みの構築。
- AWS Systems Manager Patch ManagerとSystems Manager Automationを組み合わせ、組織内で稼働する大量のAmazon EC2インスタンスに対するパッチソースの一元管理と、パッチ適用運用の自動化・標準化設計。
- 本質:システムやセキュリティの異常をイベントとして捉え、コード化された手順で自動的に復旧・通知を行う自己修復運用の設計。
- 第 6 分野: セキュリティとコンプライアンス (採点対象コンテンツの 17%)
- 本質:マルチアカウント組織全体の統制(ガードレール)の厳格化と、データ保護・コンプライアンス監査の自動化。
- 例:AWS Organizationsのサービスコントロールポリシー(SCP)において、ルートユーザーの操作制限、ホワイトリスト方式の適用、およびポリシーの継承と積集合(論理積)の評価ロジックを理解し、AWS IAM Identity Centerのアクセス許可セットと組み合わせて組織全体の権限を厳格に中央管理するガバナンス設計。
- 例:IAM アクセス許可の境界(Permissions Boundary)を活用し、下位の管理者に安全に権限を委任しつつ特権昇格を防ぐ設計、およびAmazon ECRプルスルーキャッシュとVPCエンドポイントを組み合わせたセキュアな閉域網アクセスの実装。
- 例:AWS Systems Manager InventoryとAWS Configを用いて複数サーバーのコンプライアンス監査を自動化し、同時にAmazon Macieのカスタムデータ識別子をステージング環境等に導入して、個人情報などの機密データ漏洩を未然に防ぐデータプロテクション戦略。
- 本質:マルチアカウント組織全体の統制(ガードレール)の厳格化と、データ保護・コンプライアンス監査の自動化。
感想
まとめると、DOP-C02は、クラウドシステムを「作る」だけでなく、「運用し続ける」ための知識を体系的に学ぶことが出来たと感じます。
変更管理、監視、障害対応、セキュリティ、ガバナンスといった運用の全体像を理解し、それらを自動化するための思考法を身につけることができるかと思います。
(テストセンターで現地受験していたのですが、受験前に建物の周りを軽くランニングして心拍数を上げると、集中力が増したような気がします(雨の日は建物の階段を上り下り))

最近のコメント