The AWS DevOps Engineer Professional (DOP-C02) is the hardest AWS exam outside of specialties. It tests your ability to design and implement CI/CD pipelines, automate infrastructure, ensure high availability, and build resilient systems at enterprise scale. This is a professional-level exam — it expects you to have already passed Developer Associate or SysOps Associate and to have real operational experience. The questions are scenario-heavy and require trade-off analysis, not just service knowledge.
Practice this topic
DOP-C02 goes deep on pipeline design. CodePipeline orchestrates stages: Source (CodeCommit, S3, GitHub, ECR) > Build (CodeBuild) > Test (CodeBuild test stage, or invoke Lambda) > Deploy (CodeDeploy, ECS, Lambda, CloudFormation, Elastic Beanstalk) > Approval (manual gate). Advanced patterns: parallel actions within a stage (build and test simultaneously), cross-account deployment (use cross-account roles, share CodeArtifact packages), feature branch pipelines (EventBridge triggers pipeline on branch push), pipeline-as-code (store pipeline definition in CloudFormation or CDK). Testing strategy in CI/CD: unit tests (fast, run on every commit), integration tests (run against a deployed test environment), smoke tests (post-deployment sanity check in production), canary testing (route 5% of traffic to new version, monitor error rates, auto-rollback on threshold). CodeArtifact: private artifact repository for npm, Maven, PyPI, NuGet — caches upstream packages and ensures build reproducibility.
Infrastructure as Code at DevOps Professional level means designing reusable, maintainable templates. CloudFormation advanced features: Custom Resources (Lambda-backed — extend CloudFormation with any API call), Macros (transform template sections before deployment), StackSets (deploy stacks across multiple accounts and regions in one operation — use with AWS Organisations SCPs for governance), Condition functions (deploy different resources in different environments from the same template), Outputs and Exports (cross-stack references). AWS CDK (Cloud Development Kit): define infrastructure in Python, TypeScript, Java, or Go — synthesises to CloudFormation. CDK constructs at three levels: L1 (raw CloudFormation — verbose), L2 (higher-level with sensible defaults — most common), L3 / Patterns (complete solutions like serverless REST API). Systems Manager Automation: runbooks automate multi-step operational tasks — patch, backup, incident response workflows.
Observability at DevOps Professional level requires correlating metrics, logs, and traces. AWS X-Ray: distributed tracing for microservices and serverless — trace requests through Lambda, API Gateway, ECS, and DynamoDB, identify latency bottlenecks and error sources with service maps. CloudWatch Container Insights: metrics and logs for ECS and EKS — per-task and per-container CPU, memory, network, and disk. CloudWatch Application Insights: automatically discovers and monitors application components (EC2, RDS, Elastic Load Balancers), identifies correlating events during incidents. EventBridge rules trigger automated remediation: CloudTrail event (API call) > EventBridge rule > Lambda (automated fix). Chaos engineering: fault injection to validate resilience — AWS Fault Injection Simulator (FIS) introduces CPU stress, network latency, API error injection into running workloads. Operational runbooks: automate response to known incident patterns — SSM Automation runbooks integrate with OpsCenter for incident management.
DOP-C02 tests DR design at depth. RTO and RPO targets drive architecture decisions: RTO (how long until service is restored), RPO (how much data can you lose). Four DR strategies in increasing cost/complexity: Backup and Restore (highest RTO/RPO — restore from backups when disaster occurs), Pilot Light (core infrastructure pre-provisioned in DR region — minimal cost, moderate RTO), Warm Standby (scaled-down running copy — faster failover), Active/Active Multi-Region (traffic split across regions — lowest RTO/RPO, highest cost). Route 53 failover routing: health checks monitor primary endpoint, automatic failover to secondary when primary is unhealthy. Global Accelerator: routes users to the nearest healthy endpoint using AWS's global network — reduces latency and improves failover speed. DynamoDB Global Tables: multi-region active/active replication — last-writer-wins conflict resolution.
DevOps security (DevSecOps) integrates security into the pipeline. AWS Config: continuously evaluates resource configurations against Config Rules — built-in managed rules (S3 bucket public access, MFA enabled on root, EC2 instances using approved AMIs) and custom rules (Lambda-backed). Config Conformance Packs: deploy sets of rules across an Organisation from a single YAML template. AWS Security Hub: aggregates findings from GuardDuty, Inspector, Macie, Config, and partner tools — prioritised by severity, ASFF (Amazon Security Finding Format). Inspector v2: continuous vulnerability assessment of EC2 AMIs and container images — integrates with ECR for image scanning on push. SCPs (Service Control Policies): Organisations-level guardrails — restrict what actions any account in an OU can perform regardless of IAM policies. Preventive controls (SCPs) are stronger than detective controls (Config rules) — use both.
DevOps is just about CI/CD pipelines
DevOps is about culture and organisational practices as much as tooling. The AWS DevOps exam tests monitoring, resilience, security automation, and incident response — not just pipeline configuration.
Multi-region Active/Active is always the right DR strategy
Active/Active has significantly higher complexity and cost. It is appropriate when RTO must be near-zero and business requirements justify the cost. Backup/Restore or Pilot Light is sufficient for most workloads at a fraction of the cost.
CloudFormation StackSets require individual account deployment
StackSets with service-managed permissions (AWS Organisations integration) can deploy to all accounts in an OU automatically, including newly created accounts — no manual deployment to each account.
AWS Config rules prevent non-compliant resource creation
Config rules are detective — they identify non-compliant resources after creation. To prevent non-compliant resources, use SCPs (Organisations) or IAM permission boundaries as preventive controls.
Try free AWS DevOps Professional practice questions with explanations, topic links and progress tracking.