AWS Certified DevOps Engineer - Professional (DOP-C02) Study Guide

AWS Certified DevOps Engineer - Professional (DOP-C02) Study Guide

Issuing body: Amazon Web Services (AWS) Jurisdiction: Global (vendor certification — not a legal license to practice) Level: Professional Prerequisites: None formal. AWS recommends 2+ years of experience provisioning, operating, and managing AWS environments. (Source: catalogue record software-cert-002.) Renewal: Valid 3 years; recertify by passing the current Professional-level exam.

1. What this exam is

DOP-C02 is the automation-and-operations counterpart to SAP-C02. Where the Solutions Architect exam asks "what should we build," DOP asks "how do we ship it safely, repeatedly, and recover when it breaks." The exam rewards engineers who think in pipelines, policies, and runbooks rather than consoles. Roughly a third of the questions are incident-response and monitoring scenarios; another third is CI/CD and IaC; the rest is security automation and resilience.

2. Pathway and exam format

• Typical path: AWS Certified Developer – Associate (DVA) or SysOps Administrator – Associate (SOA) first, then 2+ years running production workloads, then DOP-C02. The Associate exams teach the service surface; DOP teaches the operational judgment.
• Format: 75 multiple-choice / multiple-response questions, 180 minutes, scored 100–1000, passing 750. $300 USD via Pearson VUE.
• The stems are operationally dense: "deployments fail intermittently," "mean time to recovery must drop below 15 minutes," "developers need self-service environments with guardrails." The correct answer is almost always the one that automates the toil away rather than adding manual process.
• Bias toward managed services and automation. If an option says "write a custom script on a cron job on an EC2 instance" and another says "EventBridge → Systems Manager Automation / Lambda," the managed/automated one wins unless a constraint forbids it.

3. Knowledge domains (with theory)

AWS publishes approximate domain weightings: SDLC Automation (~22%), CloudFormation / IaC (~23%), Resilient Cloud Solutions (~15%), Monitoring & Logging (~15%), Incident & Event Response (~14%), Security & Compliance (~12%). Approximate public figures; learn all six.

SDLC automation: the deployment theory

Deployment strategies and their failure semantics:

• All-at-once (in-place): fastest, zero extra capacity, but a bad deploy takes down everything and rollback is a second deploy. Only acceptable for dev.
• Rolling: N-batch replacement; capacity dips during deploy; rollback = rolling back. CodeDeploy's default for EC2.
• Blue/green: two identical environments, traffic flips (Route 53 weighted, ALB target groups). Near-zero downtime, instant rollback (flip back), but doubles capacity cost during deploy. The exam's default right answer for "zero downtime + instant rollback."
• Canary: shift 10% → 50% → 100% with CloudWatch alarms auto-rollback. Best for detecting subtle regressions; requires good metrics.
• Linear: 10% every N minutes — canary with a fixed schedule.
• Immutable: new ASG/AMI each deploy; old infra untouched until healthy. Pairs with CodeDeploy + Auto Scaling.

Pipeline architecture (CodePipeline): source (CodeCommit/GitHub/CodeStar connection) → build (CodeBuild, buildspec.yml) → test → deploy (CodeDeploy) → optional manual approval gates. Artifacts are immutable and versioned — a release is a specific artifact hash, never "latest." Know buildspec phases (install, pre_build, build, post_build) and where caching (S3/local/Docker layer cache) cuts build time.

Safe deployment theory — the four gates: (1) automated tests in pipeline, (2) deployment strategy limiting blast radius, (3) automated rollback on alarm (CloudWatch alarms wired to CodeDeploy auto-rollback), (4) post-deploy verification (synthetics). The exam tests whether you include all four.

IaC: CloudFormation deep knowledge

Template anatomy: Parameters (inputs, with AllowedValues/AllowedPattern constraints) → Mappings (region→AMI lookups) → Conditions → Resources (Type, Properties) → Outputs (Export for cross-stack references). Intrinsic functions: Ref, Fn::Sub, Fn::Join, Fn::GetAtt, Fn::ImportValue, Fn::FindInMap, Fn::If.

Change sets preview mutations before execution — the answer to "how to safely update production stacks." Stack policies prevent updates to critical resources (e.g., Deny Update:Replace on the database). Drift detection finds out-of-band changes; StackSets deploy across accounts/regions from a management account. Nested stacks for reuse; custom resources (Lambda-backed) when CloudFormation lacks a resource type.

The update-replacement trap: some property changes force resource replacement (new physical ID) — changing an RDS engine version is fine, changing certain subnet properties replaces. Know that replacement can mean data loss unless DeletionPolicy: Retain/Snapshot is set. Exam questions love "update the stack, keep the data" — answer: DeletionPolicy + Snapshot.

Beyond CloudFormation: CDK (constructs synthesize to CFN — know L1/L2/L3 construct levels), Terraform is third-party (know when the scenario mandates it, but AWS-native answers usually win), SAM for serverless (transform: AWS::Serverless-2016-10-31).

Resilient solutions: designing for failure operationally

Multi-AZ vs multi-region (same theory as SAP-C02, operational angle): health checks must test dependency depth — an ALB health check returning 200 from a static page while the DB is down is a lie. Route 53 health checks with CloudWatch alarm integration; failover routing for active-passive.

Auto Scaling theory: target tracking (keep a metric at a value — simplest, best for most), step scaling (bands), scheduled scaling (known patterns), predictive scaling (ML on history). Warm pools cut scale-out latency for slow-booting apps. Lifecycle hooks let instances warm up (user-data, config management) before entering service — the fix for "new instances fail health checks on scale-out."

Chaos/fault injection: AWS Fault Injection Simulator (FIS) for game days. The exam treats "we test failover quarterly with FIS" as the mature answer.

Monitoring, logging, incident response

The observability stack: CloudWatch Metrics (1-min standard, 1-sec high-res; 15-month retention) → Alarms (static, anomaly detection, composite) → Dashboards; CloudWatch Logs (log groups, metric filters turning log patterns into metrics, Logs Insights query language, subscription filters → Lambda/Kinesis); X-Ray (distributed tracing, sampling rules, service maps); CloudTrail (API audit, org trails, log file validation); Config (resource configuration history + rules).

Metric math for alarms: know m1 + m2, anomaly detection bands, and composite alarms (AND/OR across alarms to cut noise). Alarm on symptoms, page on user impact: the exam distinguishes "notify the team" (SNS) from "page" (incident response) from "auto-remediate" (EventBridge → SSM Automation).

Incident response runbooks: Systems Manager Automation documents (multi-step, cross-account via delegated administration), Incident Manager (runbooks, engagement plans, post-incident analysis templates), OpsCenter/OpsItems for tracking. Blameless postmortems and the "5 whys" appear as process answers.

Event-driven operations: EventBridge rules matching Config/CloudTrail/Health events → targets (Lambda, SSM Automation, SNS). Example: "when an EC2 instance is terminated, snapshot its volumes" — EventBridge on EC2 state-change → Lambda. This pattern family is ~10% of the exam by itself.

Security automation

Pipeline security: CodeBuild with least-privilege service roles; artifact signing (Signer); image scanning (Inspector/ECR scanning) as a pipeline gate; secrets from Secrets Manager/Parameter Store (never env vars in buildspec). SSDF (NIST SP 800-218) maps here: provenance, signed artifacts, dependency scanning.

Detective automation: Security Hub findings → EventBridge → automated remediation (e.g., revoke public S3 ACL via Lambda). GuardDuty for threat detection; Macie for S3 PII. IAM Access Analyzer for unused access and policy generation — the answer to "right-size permissions automatically."

4. Key formulas and operational math

• Error budget (SRE): budget = (1 − SLO) × total events/time. 99.9% SLO over 30 days = 43.2 min. If burn rate consumes the budget, freeze deploys — the exam's framing for "when to stop shipping."
• Deployment risk: risk ∝ batch size × blast radius / rollback speed. Canary reduces blast radius; blue/green maximizes rollback speed.
• MTTR decomposition: MTTR = detect + diagnose + mitigate + verify. Automation attacks detect (alarms) and mitigate (runbooks); that's why they're weighted.
• Retry with backoff: wait = min(cap, base × 2^attempt) + jitter. In pipelines: CodeBuild/CodeDeploy retries must be bounded — unbounded retries turn a bad deploy into a billing event.
• Pipeline lead time: commit → production time = sum of stage durations − parallelizable overlap. The exam's "speed up releases" questions are answered by parallelizing test stages and caching builds, not by skipping gates.
• Log cost math: CloudWatch Logs ingestion ($/GB) + retention; S3 + Athena is ~10× cheaper for cold logs — know when to tier logs to S3 via subscription filters or Kinesis Firehose.

5. Worked examples

Example 1 — Flaky deploys, slow rollback. Scenario: A team deploys to EC2 via scripts; failed deploys take 45 min to roll back; MTTR target is 15 min. Solution: CodeDeploy blue/green with a cloned Auto Scaling group; CloudWatch alarms (5xx rate, latency p99) wired to automatic rollback; deployment lifecycle hooks run smoke tests before traffic shifts. Rollback becomes a target-group flip (~1–2 min). Add a pipeline manual-approval gate before production. This directly addresses the MTTR budget: detect (alarms) + mitigate (flip) < 15 min.

Example 2 — Self-service environments with guardrails. Scenario: 200 developers need ephemeral test environments; security requires no public S3, encrypted volumes, and cost caps. Solution: Service Catalog portfolio of CloudFormation/Terraform products with launch constraints (IAM role limiting actions) and template constraints (rules blocking non-compliant parameters); SCPs denying unencrypted EBS and public S3 org-wide; StackSets or Service Catalog + Lambda for scheduled teardown (nuke dev stacks nightly); cost anomaly detection + budgets with auto-shutdown. Guardrails are preventive (SCP/template constraints), not wiki pages.

Example 3 — Database schema migration in CI/CD. Scenario: Weekly schema changes to Aurora; must roll back application + schema atomically on failure. Solution: Expand-contract (expand/migrate/contract) migrations — never destructive DDL in a deploy; migration tool (Flyway/Liquibase) as a CodeBuild step with versioned scripts; blue/green at the app tier; Aurora backtrack or snapshot before migration for DB rollback; feature flags decouple deploy from release. The trap: "rollback the CodeDeploy deployment" doesn't roll back the schema — that's why expand-contract exists.

Example 4 — Automated incident response. Scenario: Requirement: any GuardDuty "high" finding for EC2 must isolate the instance within 5 minutes, notify security, and preserve forensic state. Solution: EventBridge rule on GuardDuty findings (severity ≥ 7) → Step Functions workflow: (1) snapshot EBS volumes (forensics), (2) attach quarantine security group (isolate), (3) detach IAM instance profile, (4) SNS to security, (5) create OpsItem in Systems Manager. Everything logged to CloudTrail. This is the canonical "event-driven remediation" pattern the exam repeats.

Example 5 — Multi-account pipeline with separation of duties. Scenario: Dev, test, and prod accounts; developers can't touch prod; every prod change needs approval and full audit. Solution: Separate tools/shared-services account hosting CodePipeline; cross-account IAM roles assumed by the pipeline (dev role can deploy to test; only pipeline + approvers touch prod); manual approval action before prod stage; CloudTrail org trail + Config for audit; artifacts promoted unchanged through stages (same immutable artifact, environment-specific parameter overrides via SSM Parameter Store hierarchies). Separation of duties is enforced by account boundaries + roles, not by asking nicely.

6. Standards and regulations cross-reference

• NIST SP 800-218 (SSDF) — the most directly tested standard: secure pipeline practices (signed artifacts via Signer, provenance, vulnerability scanning gates, secrets management). When a scenario says "software supply chain," think SSDF → signing + SBOM + scanning.
• SOC 2 — change management and audit trails: every production change via pipeline with approvals (evidence in CodePipeline execution history + CloudTrail); access reviews via IAM Access Analyzer.
• ISO/IEC 27001:2022 — Annex A controls map to detective/preventive automation: A.8.9 configuration management (Config rules), A.8.15 logging (CloudTrail/CloudWatch), A.8.32 change management (pipelines + change sets).
• PCI DSS v4.0.1 — for payment workloads: deployment pipelines must not expose cardholder data (mask in logs, tokenize in test); Requirement 6 (secure development) and 11 (vulnerability scanning) are pipeline gates.
• EU Cyber Resilience Act — vulnerability handling and SBOMs for products with digital elements: Inspector/ECR scanning + automated patching (SSM Patch Manager) as the operational answer.
• GDPR — log data containing personal data: retention policies, regional log storage, and erasure procedures for logs (often forgotten — CloudWatch Logs retention + S3 lifecycle + documented runbook).

7. Pitfalls, traps, and exam strategy

Trap patterns:

1. The manual-process trap: any answer involving "the operator will SSH in and fix it" loses to automation, always.
2. The custom-script trap: "a cron job on an EC2 instance" loses to EventBridge + Lambda/SSM Automation.
3. The rollback trap: answers that roll back the app but not the data/schema. Expand-contract or snapshot first.
4. The alarm-noise trap: "page on every CPU spike" — correct answers use composite alarms, anomaly detection, and symptom-based alerting.
5. The deployment-strategy trap: blue/green for zero-downtime + instant rollback; canary for gradual validation; in-place is never the answer for production.
6. The CloudFormation trap: DeletionPolicy/Snapshot for stateful resources; change sets before production updates; StackSets (not manual replication) for multi-account.

Strategy: same pacing as SAP-C02 (2.4 min/question). Operational questions are often shorter — bank time there for the long pipeline/IaC scenarios. Memorize: the five deployment strategies and their trade-offs, CloudFormation intrinsic functions and the update behaviors (No interruption / Some interruption / Replacement), CodePipeline/CodeBuild/CodeDeploy stage order, and the EventBridge → target pattern family. Everything else derives from "automate it, make it reversible, make it observable."

8. Practice problems

P1. A deployment pipeline takes 55 minutes, mostly in a serial test stage running 400 integration tests. The team wants faster feedback without reducing coverage. Propose two changes and estimate the effect. Answer: (1) Shard the test stage into parallel CodeBuild batch builds (e.g., 8 parallel jobs → ~7 min if tests parallelize cleanly, Amdahl-limited by the longest shard). (2) Enable Docker layer + dependency caching (cuts build/install time 50–80%). Combined: 55 min → ~12–15 min. Keep a nightly full serial run if any tests are order-dependent.

P2. During a rolling deployment, new instances fail ELB health checks because the app needs 3 minutes to warm its cache, and the ASG terminates them as unhealthy. Give the two-part fix. Answer: (1) Add an Auto Scaling lifecycle hook (launching:wait) with a heartbeat, so instances stay in Pending:Wait while warming. (2) Increase the health check grace period to >180 s and make the warm-up script send complete-lifecycle-action on success. Root cause: the ASG was judging instances before they were ready — the fix separates "alive" from "ready."

P3. A CloudFormation stack update will replace an RDS instance (exam-style: a property change forces replacement). The database holds production data. List the exact safeguards, in order. Answer: (1) Set DeletionPolicy: Snapshot on the DB resource (auto-snapshot on delete/replace). (2) Run a change set first to confirm replacement is planned. (3) Take a manual snapshot immediately before. (4) Consider a stack policy denying replacement until reviewed. (5) After update, verify data, then clean up the pre-change snapshot per retention policy. Never rely on "I'll be careful."

P4. Design alerting for a checkout API with SLO 99.95% (21.6 min/month budget). The team currently pages on CPU > 80%. What's wrong and what's the replacement? Answer: CPU is a cause-metric, not a symptom — it pages during harmless traffic spikes and misses real outages (e.g., downstream payment failures with low CPU). Replace with: burn-rate alerts on 5xx rate + p99 latency (multi-window: fast-burn 1h/5% budget → page; slow-burn 6h/10% → ticket), composite alarm requiring both elevated error rate AND latency, and an SLO dashboard showing budget remaining. Freeze deploys when the budget is exhausted.

P5. A company runs 40 AWS accounts and developers routinely create expensive resources in dev accounts. Design the automated cost guardrail. Answer: Preventive: SCPs in dev OUs denying expensive instance families/regions (deny ec2:RunInstances with condition on instance type); Service Catalog as the only provisioning path with cost-tagged products. Detective: AWS Budgets with alert actions (auto-apply restrictive IAM policy at 100% of budget); Cost Anomaly Detection → SNS. Remediation: scheduled Lambda via EventBridge stopping/terminating untagged or off-hours dev instances. Tagging enforcement via Config rule + auto-remediation.

P6. An S3 data-lake bucket must never become public, across all accounts, and any violation must be fixed within minutes without human intervention. Give the layered answer. Answer: Preventive: SCP denying s3:PutBucketPolicy/PutBucketAcl that grant public access + S3 Block Public Access enabled at the account level (org-wide via Control Tower guardrail). Detective: Config rule s3-bucket-public-read-prohibited aggregated org-wide. Remediation: EventBridge on Config compliance-change → SSM Automation/Lambda that re-applies block-public-access and strips the policy. Note the layering: prevention stops most, detection catches drift, remediation fixes it — the exam wants all three named.

Original ETS reference writing, verified against public sources on 2026-09-30. Thin sourcing is flagged inline. Not legal advice — confirm current editions with the issuing body.