AWS Certified DevOps Engineer — Professional (DOP-C02)

A documentation-first study guide. AWS writes the exam from its own documentation, so reading the docs is the highest-leverage thing you can do. This guide is a curated index into the canonical references, FAQs, and a selection of whitepapers — organised around the six exam domains, not around services.

Maps to the published AWS Certified DevOps Engineer — Professional (DOP-C02) exam guide. Domain weights and task statements are quoted from that PDF (version 1.6).


About the exam

Current exam code: DOP-C02 (released March 2023, exam guide version 1.6). No C03 announcement as of July 2026.

Format: 75 questions (65 scored + 10 unscored) · 180 minutes · $300 USD · scaled score 100–1000, pass at 750.

The six domains:

  • Domain 1 — SDLC Automation — 22%
  • Domain 2 — Configuration Management and IaC — 17%
  • Domain 3 — Resilient Cloud Solutions — 15%
  • Domain 4 — Monitoring and Logging — 15%
  • Domain 5 — Incident and Event Response — 14%
  • Domain 6 — Security and Compliance — 17%

Primary official sources (bookmark these):

Whitepapers worth reviewing:

Priority tiers: The published domain weights (22/17/15/15/14/17) tell you how the exam is balanced across the six domains, but they don't tell you that within each domain a handful of services account for most of the questions. Every section in this guide carries a tier badge based on triangulating the AWS exam guide, the experience reports of recent test takers, and the patterns that appear in the practice-exam community:

  • ★★★ Core Heavily tested. Multiple questions will lean on this. Spend hours, not minutes — if you don't know it well, you fail.
  • ★★ Important Reliably tested, usually one or two questions. Read every linked page in the section, do the FAQ, understand the comparison points. A few hours per topic.
  • ★ Light Known to appear, but typically as one distinguishing question or as wrong-answer distractors. Skim the docs, learn the one-line distinction, move on. Twenty minutes to an hour.

For an 8–12 week prep cycle the rough split that the data supports is about 60% of your time on Core topics, 30% on Important, and 10% on Light. The biggest single concentration of questions across the whole exam is the cluster around CodePipeline/CodeBuild/CodeDeploy + CloudFormation (including StackSets) + CloudWatch + EventBridge + Auto Scaling + Systems Manager + AWS Config + Organizations — know those cold and you have the foundation of a pass. This is a Professional-level exam: questions are long scenarios with four plausible answers, and the difference between right and wrong is usually one operational detail (a lifecycle hook, an alarm-based rollback, a permission scope). Reading speed and elimination discipline matter as much as knowledge.

How to use this guide:

  • Each section opens with a one-paragraph summary explaining what to focus on, then has up to three link sections: Core docs (user/developer guides — the canonical reference), FAQ (exam writers love edge cases from FAQs — do not skip), and Deeper reading (whitepapers, blog posts, prescriptive guidance).
  • If a link 404s, AWS has reorganised the docs. Search the page title to find the new location — the content almost always still exists.
  • The What's New feed is worth a weekly scan in the last month before your exam; the exam lags new features by ~12 months but recent launches are a good prompt to revisit older chapters.

Part I — Domain 1: SDLC Automation (22%)

The largest domain by weight and the heart of the exam. CI/CD pipelines, automated testing, artifact management, and deployment strategies across EC2, containers, and serverless. Expect roughly a quarter of the exam to be pipeline scenarios.

Chapter 1 — CI/CD pipelines

Maps to Task Statement 1.1 — Implement CI/CD pipelines

Knowledge of:

  • Software development lifecycle (SDLC) concepts, phases, and models
  • Pipeline deployment patterns for single- and multi-account environments

Skills in:

  • Configuring code, image, and artifact repositories
  • Using version control to integrate pipelines with application environments
  • Setting up build processes (for example, AWS CodeBuild)
  • Managing build and deployment secrets (for example, AWS Secrets Manager, AWS Systems Manager Parameter Store)
  • Determining appropriate deployment strategies (for example, AWS CodeDeploy)

1.1 AWS CodePipeline ★★★ Core

CodePipeline is the orchestrator and the single most tested service on DOP-C02. Know stages, actions, and artifacts cold; manual approval actions; cross-region and cross-account actions (artifact bucket + KMS key + role in each target); EventBridge-based triggers vs polling; and Lambda invoke actions for custom steps. Multi-account pipeline patterns (tooling account deploys to workload accounts by assuming roles) come up repeatedly. Expect 5-8 questions directly on CodePipeline mechanics.

Core docs

FAQ

Deeper reading


1.2 AWS CodeBuild ★★★ Core

CodeBuild runs builds and tests. Know buildspec.yml structure (phases, artifacts, reports, cache), environment variable sources (plaintext vs Parameter Store vs Secrets Manager — the exam loves "how do I keep this secret out of the buildspec"), VPC connectivity for private resources, batch builds, and local caching modes. Understand how CodeBuild assumes its service role and how to grant it ECR/S3 access. Expect 3-5 questions.

Core docs

FAQ


1.3 Source control and connections ★★ Important

Pipelines start from a source. Know CodeConnections (formerly CodeStar Connections) for GitHub/GitLab/Bitbucket sources, S3 as a source (versioning required), and legacy CodeCommit (closed to new customers since July 2024 but still in the exam pool). Understand triggering builds from pull requests and branch filters, and cross-account access to repositories. Expect 1-3 questions, usually embedded in a pipeline scenario.

Core docs

Deeper reading


Chapter 2 — Automated testing in pipelines

Maps to Task Statement 1.2 — Integrate automated testing into CI/CD pipelines

Knowledge of:

  • Different types of tests (for example, unit tests, integration tests, acceptance tests, user interface tests, security scans)
  • Reasonable use of different types of tests at different stages of the CI/CD pipeline

Skills in:

  • Running builds or tests when generating pull requests or code merges (for example, CodeBuild)
  • Running load/stress tests, performance benchmarking, and application testing at scale
  • Measuring application health based on application exit codes
  • Automating unit tests and code coverage
  • Invoking AWS services in a pipeline for testing

2.1 Test stages and strategies ★★ Important

Know which test belongs at which stage: unit tests and static analysis in the build stage, integration tests after deploy to a test environment, load tests before production, canary/synthetic tests after production deploy. Understand exit-code-based health (a non-zero exit code fails the CodeBuild phase and stops the pipeline), test reports in CodeBuild, and invoking Step Functions or Lambda from a pipeline for custom validation. Expect 2-3 questions.

Core docs

Deeper reading


2.2 Amazon CodeGuru ★ Light

CodeGuru Reviewer does automated code review (security findings, resource leaks) on pull requests; CodeGuru Profiler finds runtime performance hotspots. On the exam it is the answer when a scenario asks for machine-learning-driven code quality or security scanning inside the development workflow. Usually one question or a distractor.

Core docs

FAQ


Chapter 3 — Artifact management

Maps to Task Statement 1.3 — Build and manage artifacts

Knowledge of:

  • Artifact use cases and secure management
  • Methods to create and generate artifacts
  • Artifact lifecycle considerations

Skills in:

  • Creating and configuring artifact repositories (for example, AWS CodeArtifact, Amazon S3, Amazon Elastic Container Registry [Amazon ECR])
  • Configuring build tools for generating artifacts (for example, CodeBuild, AWS Lambda)
  • Automating Amazon EC2 instance and container image build processes (for example, EC2 Image Builder)

3.1 AWS CodeArtifact ★★ Important

CodeArtifact hosts private package repositories (npm, pip, Maven, NuGet, generic). Know domains vs repositories, upstream repositories with external connections to public registries (cache and control open-source dependencies), and cross-account sharing via domain resource policies. It is the answer when a scenario wants approved/curated dependencies for builds. Expect 1-2 questions.

Core docs

FAQ


3.2 Amazon ECR ★★ Important

ECR stores container images. Know image scanning (basic on-push vs enhanced continuous scanning via Inspector), lifecycle policies to expire old/untagged images, cross-region and cross-account replication, immutable tags, and pull-through cache. Repository policies for cross-account pulls appear in multi-account pipeline questions. Expect 2-3 questions.

Core docs

FAQ


3.3 EC2 Image Builder ★★ Important

Image Builder automates golden AMI and container image pipelines: recipes (components + base image), build/test phases, distribution to multiple regions and accounts, and scheduled rebuilds when the base image updates. It is the answer when a scenario wants automated, tested, patched AMIs shared across an organization — replacing hand-rolled Packer/Lambda pipelines. Expect 1-2 questions.

Core docs

FAQ


Chapter 4 — Deployment strategies

Maps to Task Statement 1.4 — Implement deployment strategies for instance, container, and serverless environments

Knowledge of:

  • Deployment methodologies for various platforms (for example, Amazon EC2, Amazon Elastic Container Service [Amazon ECS], Amazon Elastic Kubernetes Service [Amazon EKS], Lambda)
  • Application storage patterns (for example, Amazon Elastic File System [Amazon EFS], Amazon S3, Amazon Elastic Block Store [Amazon EBS])
  • Mutable deployment patterns in contrast to immutable deployment patterns
  • Tools and services available for distributing code (for example, CodeDeploy, EC2 Image Builder)

Skills in:

  • Configuring security permissions to allow access to artifact repositories (for example, AWS Identity and Access Management [IAM], CodeArtifact)
  • Configuring deployment agents (for example, CodeDeploy agent)
  • Troubleshooting deployment issues
  • Using different deployment methods (for example, blue/green, canary)

4.1 AWS CodeDeploy ★★★ Core

CodeDeploy is tested as heavily as CodePipeline. Know all three compute platforms (EC2/on-premises, Lambda, ECS), deployment configurations (AllAtOnce, HalfAtATime, OneAtATime, Canary10Percent5Minutes, Linear10PercentEvery1Minute and how to build custom ones), appspec.yml per platform, lifecycle hooks in order, automatic rollback on failure or CloudWatch alarm, and the CodeDeploy agent (required on EC2, log location for troubleshooting). In-place vs blue/green on EC2 is a classic question. Expect 4-6 questions.

Core docs

FAQ


4.2 Blue/green, canary, and rolling patterns ★★★ Core

The exam constantly asks you to pick the right deployment pattern for a constraint set: zero downtime, instant rollback, cost, DNS caching risk, database schema compatibility. Know the trade-offs: in-place/rolling (mutable, cheap, slow rollback), immutable/blue-green (new fleet, instant rollback by re-pointing, double cost during deploy), canary (small traffic slice first, needs alarms to be useful), and where the traffic shift happens (Route 53 weighted records, ALB listener/target groups, Lambda alias weights, ECS task sets). Expect 3-5 questions.

Core docs

Deeper reading


4.3 Lambda and serverless deployments ★★ Important

Serverless deployment questions center on Lambda versions and aliases: publish an immutable version, point an alias at it, and shift traffic gradually with alias weights. CodeDeploy drives canary/linear shifts with pre/post traffic hooks and alarm-based rollback; SAM wraps this with AutoPublishAlias and DeploymentPreference. Know API Gateway stage variables and canary settings for the API layer. Expect 2-3 questions.

Core docs

FAQ


4.4 ECS and EKS deployments ★★★ Core

Container deployment scenarios are frequent. For ECS know the three deployment types: rolling update (minimumHealthyPercent/maximumPercent), blue/green via CodeDeploy (two target groups, test listener, ValidateService hooks, alarm rollback), and external. For EKS know that CodeDeploy does not deploy to EKS — answers involve rolling updates via Kubernetes deployments, Helm, or a CodeBuild step running kubectl with an IAM-mapped role. Expect 3-4 questions.

Core docs

FAQ


4.5 AWS Elastic Beanstalk ★★ Important

Beanstalk still earns questions at the Professional level. Know the five deployment policies and their trade-offs (all at once, rolling, rolling with additional batch, immutable, traffic splitting), CNAME swap for blue/green, .ebextensions for configuration, and worker environments. The classic question: which policy gives zero downtime at least cost vs fastest rollback. Expect 2-3 questions.

Core docs

FAQ


Part II — Domain 2: Configuration Management and IaC (17%)

Infrastructure as code at organizational scale. CloudFormation is the center of gravity, with StackSets, multi-account governance, and Systems Manager automation orbiting it.

Chapter 5 — Infrastructure as code

Maps to Task Statement 2.1 — Define cloud infrastructure and reusable components to provision and manage systems throughout their lifecycle

Knowledge of:

  • Infrastructure as code (IaC) options and tools for AWS
  • Change management processes for IaC-based platforms
  • Configuration management services and strategies

Skills in:

  • Composing and deploying IaC templates (for example, AWS Serverless Application Model [AWS SAM], AWS CloudFormation, AWS Cloud Development Kit [AWS CDK])
  • Applying CloudFormation StackSets across multiple accounts and AWS Regions
  • Determining optimal configuration management services (for example, AWS OpsWorks, AWS Systems Manager, AWS Config, AWS AppConfig)
  • Implementing infrastructure patterns, governance controls, and security standards into reusable IaC templates (for example, AWS Service Catalog, CloudFormation modules, AWS CDK)

5.1 AWS CloudFormation ★★★ Core

CloudFormation is the most tested Domain 2 service. Know template anatomy, intrinsic functions, change sets (preview before update), stack policies and DeletionPolicy/UpdateReplacePolicy (protect stateful resources), drift detection, nested stacks vs cross-stack exports, cfn-init/cfn-signal with creation policies for EC2 bootstrapping, and rollback behavior including alarm-based rollback triggers. Failed-update troubleshooting (UPDATE_ROLLBACK_FAILED, what to do) is a recurring scenario. Expect 4-6 questions.

Core docs

FAQ


5.2 CloudFormation StackSets ★★★ Core

StackSets deploy one template to many accounts and regions. Know self-managed permissions (AWSCloudFormationStackSetAdministrationRole + ExecutionRole) vs service-managed permissions (Organizations integration, automatic deployment to new accounts in an OU), stack instances, operation preferences (region order, failure tolerance, max concurrent), and drift detection on stack sets. This is the default answer for "roll out X to every account". Expect 2-4 questions.

Core docs


5.3 Custom resources, macros, and hooks ★★ Important

When CloudFormation can't do something natively, a custom resource (Lambda-backed, responds to Create/Update/Delete with a signed URL callback) fills the gap. Macros transform templates at deploy time (SAM is a macro); modules package reusable resource collections; hooks proactively validate resources against policy before provisioning. Know which to pick for "extend CloudFormation" scenarios. Expect 1-2 questions.

Core docs


5.4 AWS CDK ★★ Important

The CDK defines infrastructure in real programming languages and synthesizes CloudFormation. Know constructs (L1/L2/L3), apps and stacks, cdk synth/diff/deploy, bootstrapping (the CDKToolkit stack per account/region), and CDK Pipelines for self-mutating CI/CD. On the exam CDK appears as the reusable-components answer (publish construct libraries) and inside pipeline scenarios. Expect 1-3 questions.

Core docs

FAQ


5.5 AWS SAM ★★ Important

SAM is CloudFormation shorthand for serverless (Transform: AWS::Serverless-2016-10-31). Know the resource types (Function, Api, Table), sam build/deploy/local, and above all the gradual deployment integration with CodeDeploy — AutoPublishAlias plus DeploymentPreference gives canary/linear Lambda releases with alarms and hooks. Expect 1-2 questions.

Core docs


5.6 AWS Service Catalog and Proton ★★ Important

Service Catalog packages approved CloudFormation templates as products in portfolios, with launch constraints so end users deploy with a role they don't otherwise have — the answer for "let developers self-serve approved infrastructure without broad IAM permissions". Proton does the same for containerized/serverless application templates with platform-team-managed environment and service templates. Expect 1-2 questions.

Core docs

FAQ


Chapter 6 — Multi-account environments

Maps to Task Statement 2.2 — Deploy automation to create, onboard, and secure AWS accounts in a multi-account or multi-Region environment

Knowledge of:

  • AWS account structures, best practices, and related AWS services

Skills in:

  • Standardizing and automating account provisioning and configuration
  • Creating, consolidating, and centrally managing accounts (for example, AWS Organizations, AWS Control Tower)
  • Applying IAM solutions for multi-account and complex organization structures (for example, SCPs, assuming roles)
  • Implementing and developing governance and security controls at scale (AWS Config, AWS Control Tower, AWS Security Hub, Amazon Detective, Amazon GuardDuty, AWS Service Catalog, SCPs)

6.1 AWS Organizations and SCPs ★★★ Core

Organizations is foundational to half the exam's governance scenarios. Know OUs and policy inheritance, service control policies (SCPs are guardrails — they never grant permissions, don't affect the management account, and deny wins), delegated administrator for services, trusted access, tag policies, and consolidated billing. The classic question shape: prevent all accounts in an OU from doing X, or allow only region Y. Expect 3-4 questions.

Core docs

FAQ

Deeper reading


6.2 AWS Control Tower ★★ Important

Control Tower is opinionated multi-account setup: a landing zone with log archive and audit accounts, Account Factory for standardized account vending (including Account Factory for Terraform), and controls (guardrails) that are preventive (SCPs), detective (Config rules), or proactive (CloudFormation hooks). It is the answer when a scenario wants automated, governed account provisioning without building it from raw Organizations + StackSets. Expect 2-3 questions.

Core docs

FAQ


6.3 IAM Identity Center and cross-account access ★★ Important

Know IAM Identity Center (successor to AWS SSO) for workforce access: permission sets provision roles into accounts, identity source can be the built-in store, Active Directory, or an external SAML IdP. For automation, know the cross-account role-assumption pattern (trust policy + sts:AssumeRole) that underpins multi-account pipelines. Expect 1-2 questions.

Core docs


Chapter 7 — Automation at scale

Maps to Task Statement 2.3 — Design and build automated solutions for complex tasks and large-scale environments

Knowledge of:

  • AWS services and solutions to automate tasks and processes
  • Methods and strategies to interact with the AWS software-defined infrastructure

Skills in:

  • Automating system inventory, configuration, and patch management (for example, Systems Manager, AWS Config)
  • Developing Lambda function automations for complex scenarios (for example, AWS SDKs, Lambda, AWS Step Functions)
  • Automating the configuration of software applications to the desired state (for example, OpsWorks, Systems Manager State Manager)
  • Maintaining software compliance (for example, Systems Manager)

7.1 AWS Systems Manager ★★★ Core

Systems Manager is the fleet-management answer across Domains 2, 4, and 5. Know the capabilities by name and use case: Run Command (ad hoc commands, no SSH), State Manager (desired-state associations), Patch Manager (patch baselines + maintenance windows), Automation (runbooks — the remediation building block), Session Manager (auditable shell, no bastions or open ports), Inventory + Compliance, Parameter Store, and the SSM Agent + instance role prerequisites. Hybrid activations manage on-premises servers. Expect 4-5 questions.

Core docs

FAQ


7.2 AWS Config ★★★ Core

Config records resource configuration history and evaluates it against rules. Know managed vs custom rules (Lambda or Guard), evaluation triggers (configuration change vs periodic), automatic remediation via SSM Automation runbooks, conformance packs (rule bundles, deployable org-wide), aggregators for multi-account/multi-region visibility, and the difference from CloudTrail (what changed vs who called what). Expect 3-4 questions.

Core docs

FAQ


7.3 Lambda and Step Functions for operations automation ★★ Important

Custom automation glue: EventBridge rule triggers a Lambda function or Step Functions state machine that calls AWS SDKs. Know when Step Functions beats a single Lambda (long-running, retries per step, human approval via task tokens, direct SDK integrations without code) and Lambda operational limits (15-minute timeout, concurrency). Expect 1-2 questions, usually inside a remediation scenario.

Core docs

FAQ


7.4 AWS AppConfig and OpsWorks ★ Light

AppConfig deploys application configuration and feature flags gradually with validators and automatic alarm-based rollback — the answer for "change config without redeploying code, safely". OpsWorks (Chef/Puppet) reached end of life in 2024 but still appears in the exam guide; treat it as a legacy distractor and know only that it was AWS-managed Chef/Puppet configuration management. Expect 1 question between them.

Core docs


Part III — Domain 3: Resilient Cloud Solutions (15%)

High availability, scalability, and disaster recovery. Professional-level resilience questions hinge on matching RTO/RPO numbers to the cheapest architecture that meets them.

Chapter 8 — High availability

Maps to Task Statement 3.1 — Implement highly available solutions to meet resilience and business requirements

Knowledge of:

  • Multi-AZ and multi-Region deployments (for example, compute layer, data layer)
  • SLAs
  • Replication and failover methods for stateful services
  • Techniques to achieve high availability (for example, Multi-AZ, multi-Region)

Skills in:

  • Translating business requirements into technical resiliency needs
  • Identifying and remediating single points of failure in existing workloads
  • Enabling cross-Region solutions where available (for example, Amazon DynamoDB, Amazon RDS, Amazon Route 53, Amazon S3, Amazon CloudFront)
  • Configuring load balancing to support cross-AZ services
  • Configuring applications and related services to support multiple Availability Zones and Regions while minimizing downtime

8.1 Route 53 for availability ★★ Important

Route 53 is the multi-region traffic layer. Know routing policies (failover, weighted, latency, geolocation), health checks (endpoint, calculated, CloudWatch-alarm-based) and how failover routing pairs with them, alias records, and evaluate-target-health. Application Recovery Controller readiness checks and routing controls show up for regional failover with strict control. Expect 2-3 questions.

Core docs

FAQ


8.2 Elastic Load Balancing ★★ Important

Know ALB vs NLB selection, cross-zone load balancing (default on for ALB, off for NLB), health checks and how they interact with Auto Scaling replacement, target group deregistration delay, and multi-AZ target distribution. Gateway Load Balancer is a distractor unless the scenario involves third-party appliances. Expect 1-2 questions.

Core docs

FAQ


8.3 Data layer resilience ★★★ Core

Match each data service to its HA and cross-region mechanism: RDS Multi-AZ (synchronous standby, failover not scaling) vs read replicas (async, cross-region capable, promotable); Aurora replicas and Global Database (sub-second cross-region replication, ~1 minute promotion); DynamoDB global tables (multi-active, last-writer-wins); S3 Cross-Region Replication (new objects only, versioning required, RTC for a 15-minute SLA); ElastiCache Redis Multi-AZ and Global Datastore. Expect 3-4 questions.

Core docs

FAQ


Chapter 9 — Scalability

Maps to Task Statement 3.2 — Implement solutions that are scalable to meet business requirements

Knowledge of:

  • Appropriate metrics for scaling services
  • Loosely coupled and distributed architectures
  • Serverless architectures
  • Container platforms

Skills in:

  • Identifying and remediating scaling issues
  • Identifying and implementing appropriate auto scaling, load balancing, and caching solutions
  • Deploying container-based applications (for example, Amazon ECS, Amazon EKS)
  • Deploying workloads in multiple Regions for global scalability
  • Configuring serverless applications (for example, Amazon API Gateway, Lambda, AWS Fargate)

9.1 Amazon EC2 Auto Scaling ★★★ Core

Auto Scaling groups appear across every domain. Know scaling policy types (target tracking first choice, step, simple, scheduled, predictive), lifecycle hooks (run actions during launch/terminate — pairs with CodeDeploy and log-draining scenarios), health check types (EC2 vs ELB grace period), instance refresh for rolling AMI updates, warm pools, termination policies, and cooldowns. Expect 3-5 questions.

Core docs

FAQ


9.2 Application Auto Scaling ★★ Important

Application Auto Scaling covers everything that is not an EC2 ASG: DynamoDB provisioned capacity, ECS service desired count, Aurora replicas, Lambda provisioned concurrency, and more. Know that the exam guide explicitly names DynamoDB auto scaling, RDS storage autoscaling, ECS capacity providers, and EKS autoscalers as scaling capabilities to distinguish. Expect 1-2 questions.

Core docs


9.3 Container scaling: ECS and EKS ★★ Important

Two scaling layers: tasks/pods and the compute under them. For ECS, service auto scaling handles tasks and capacity providers with managed scaling handle the ASG (or use Fargate and skip it). For EKS, know Cluster Autoscaler and Karpenter for nodes, Horizontal Pod Autoscaler for pods, and Fargate profiles. Expect 1-2 questions.

Core docs


9.4 Serverless and caching layers ★★ Important

Serverless scales by default but has knobs: Lambda reserved and provisioned concurrency, API Gateway throttling and caching, SQS as a buffer between tiers. CloudFront and ElastiCache are the caching answers for global scalability and database offload respectively. Expect 1-2 questions.

Core docs

FAQ


Chapter 10 — Disaster recovery

Maps to Task Statement 3.3 — Implement automated recovery processes to meet RTO and RPO requirements

Knowledge of:

  • Disaster recovery concepts (for example, RTO, RPO)
  • Backup and recovery strategies (for example, pilot light, warm standby)
  • Recovery procedures

Skills in:

  • Testing failover of Multi-AZ and multi-Region workloads (for example, Amazon RDS, Amazon Aurora, Route 53, CloudFront)
  • Identifying and implementing appropriate cross-Region backup and recovery strategies (for example, AWS Backup, Amazon S3, Systems Manager)
  • Configuring a load balancer to recover from backend failure

10.1 DR strategies: RTO and RPO ★★★ Core

Memorize the four strategies in order of cost and speed: backup and restore (hours RTO), pilot light (data live, compute off — tens of minutes), warm standby (scaled-down copy running — minutes), multi-site active/active (near zero). Every DR question is "cheapest architecture meeting RTO of X and RPO of Y" — anchor each strategy to its rough numbers and the services that implement it. Expect 2-3 questions.

Core docs


10.2 AWS Backup ★★ Important

AWS Backup centralizes backups across services (EBS, RDS, DynamoDB, EFS, S3, and more) with backup plans, vaults, cross-region and cross-account copies, and vault lock for immutability. Organizations integration gives org-wide backup policies. It is the answer when a scenario wants centralized, policy-driven, cross-region backup rather than per-service snapshot scripting. Expect 1-2 questions.

Core docs

FAQ


10.3 AWS Elastic Disaster Recovery ★ Light

DRS continuously replicates servers (on-premises or cloud) at the block level into a low-cost staging area, launching full recovery instances in minutes only when needed. It is the answer for lift-and-shift DR of servers with low RTO/RPO at minimal steady-state cost. Usually one question or a distractor against warm standby.

Core docs


Part IV — Domain 4: Monitoring and Logging (15%)

CloudWatch end to end: collecting logs and metrics, analyzing them, alarming on them, and wiring the results into automation. Almost every question in this domain touches CloudWatch or EventBridge.

Chapter 11 — Log and metric collection

Maps to Task Statement 4.1 — Configure the collection, aggregation, and storage of logs and metrics

Knowledge of:

  • How to monitor applications and infrastructure
  • Amazon CloudWatch metrics (for example, namespaces, metrics, dimensions, and resolution)
  • Real-time log ingestion
  • Encryption options for at-rest and in-transit logs and metrics (for example, client-side and server-side, AWS Key Management Service [AWS KMS])
  • Security configurations (for example, IAM roles and permissions to allow for log collection)

Skills in:

  • Securely storing and managing logs
  • Creating CloudWatch metrics from log events by using metric filters
  • Creating CloudWatch metric streams (for example, Amazon S3 or Amazon Kinesis Data Firehose options)
  • Collecting custom metrics (for example, using the CloudWatch agent)
  • Managing log storage lifecycles (for example, S3 lifecycles, CloudWatch log group retention)
  • Processing log data by using CloudWatch log subscriptions (for example, Kinesis, Lambda, Amazon OpenSearch Service)
  • Searching log data by using filter and pattern syntax or CloudWatch Logs Insights
  • Configuring encryption of log data (for example, AWS KMS)

11.1 CloudWatch metrics ★★★ Core

Know the metric model: namespaces, dimensions, standard (1-minute) vs high-resolution (1-second) metrics, standard vs detailed EC2 monitoring, custom metrics via PutMetricData or embedded metric format, and metric streams to Firehose/S3 for near-real-time export to third-party tools. Metric math and percentiles show up in alarm scenarios. Expect 2-3 questions.

Core docs

FAQ


11.2 CloudWatch Logs ★★★ Core

The log pipeline is heavily tested: log groups and retention settings, metric filters (turn log patterns into metrics you can alarm on — a classic exam pattern), subscription filters for real-time processing (Kinesis Data Streams, Firehose, Lambda, cross-account), export to S3 (batch, not real time — know the distinction), Logs Insights query syntax basics, and KMS encryption of log groups. Expect 3-4 questions.

Core docs


11.3 CloudWatch agent and collection security ★★ Important

The unified CloudWatch agent collects system-level metrics (memory, disk — not available natively) and logs from EC2 and on-premises servers. Know the prerequisites: agent config (commonly stored in SSM Parameter Store), an instance role with CloudWatchAgentServerPolicy, and installation at scale via SSM Run Command/State Manager. "Why are my memory metrics missing" and "agent installed but no logs" (role missing) are classic questions. Expect 1-2 questions.

Core docs


11.4 Streaming log pipelines: Kinesis ★★ Important

Know when each Kinesis service is the right sink: Data Streams for real-time custom processing (shards, consumers, replay within retention), Data Firehose for fully managed delivery to S3/OpenSearch/Redshift with buffering and Lambda transformation (near real time, no replay). CloudWatch Logs subscriptions plus Firehose to a central S3 bucket is the standard multi-account log aggregation pattern. Expect 1-2 questions.

Core docs

FAQ


Chapter 12 — Analysis and anomaly detection

Maps to Task Statement 4.2 — Audit, monitor, and analyze logs and metrics to detect issues

Knowledge of:

  • Anomaly detection alarms (for example, CloudWatch anomaly detection)
  • Common CloudWatch metrics and logs (for example, CPU utilization with Amazon EC2, queue length with Amazon RDS, 5xx errors with an Application Load Balancer [ALB])
  • Amazon Inspector and common assessment templates
  • AWS Config rules
  • AWS CloudTrail log events

Skills in:

  • Building CloudWatch dashboards and Amazon QuickSight visualizations
  • Associating CloudWatch alarms with CloudWatch metrics (standard and custom)
  • Configuring AWS X-Ray for different services (for example, containers, API Gateway, Lambda)
  • Analyzing real-time log streams (for example, using Kinesis Data Streams)
  • Analyzing logs with AWS services (for example, Amazon Athena, CloudWatch Logs Insights)

12.1 CloudWatch alarms and anomaly detection ★★★ Core

Alarms drive nearly all automation in this exam: states (OK, ALARM, INSUFFICIENT_DATA — know how missing data treatment changes behavior), actions (SNS, Auto Scaling, EC2 recover/stop/terminate, Systems Manager), composite alarms to reduce noise, and anomaly detection alarms (ML band instead of a static threshold — the answer for metrics with cyclical patterns). Alarms also gate deployments via CodeDeploy rollback and CloudFormation rollback monitoring. Expect 3-4 questions.

Core docs


12.2 Dashboards, Logs Insights, and Athena ★★ Important

Know the analysis tool for each shape of question: Logs Insights for interactive queries over CloudWatch log groups, Athena for SQL over logs archived in S3 (CloudTrail, ALB, VPC Flow Logs — partitioning reduces cost), CloudWatch dashboards for cross-region operational views, and QuickSight for business-style visualization of query results. Expect 1-2 questions.

Core docs


12.3 AWS X-Ray ★★ Important

X-Ray traces requests across distributed services. Know how to enable it per compute type: Lambda active tracing (checkbox + IAM), API Gateway stage setting, ECS/EKS via the X-Ray daemon as sidecar container, EC2 via daemon install. Understand segments/subsegments, annotations (indexed, filterable) vs metadata (not indexed), sampling rules, and the service map for finding the failing hop. Expect 2-3 questions.

Core docs

FAQ


12.4 Amazon Inspector ★★ Important

Inspector continuously scans EC2 instances (via SSM Agent), ECR container images, and Lambda functions for CVEs and network exposure. Findings flow to Security Hub and EventBridge for automated response. It appears in Domain 4 as an assessment tool and again in Domain 6 as a vulnerability scanner — know that it is agentless-by-SSM for EC2 and continuous rather than scheduled in v2. Expect 1-2 questions.

Core docs

FAQ


Chapter 13 — Automated monitoring and event management

Maps to Task Statement 4.3 — Automate monitoring and event management of complex environments

Knowledge of:

  • Event-driven, asynchronous design patterns (for example, S3 Event Notifications or Amazon EventBridge events to Amazon Simple Notification Service [Amazon SNS] or Lambda)
  • Capabilities of auto scaling for a variety of AWS services (for example, EC2 Auto Scaling groups, RDS storage auto scaling, DynamoDB, ECS capacity provider, EKS autoscalers)
  • Alert notification and action capabilities (for example, CloudWatch alarms to Amazon SNS, Lambda, EC2 automatic recovery)
  • Health check capabilities in AWS services (for example, ALB target groups, Route 53)

Skills in:

  • Configuring solutions for auto scaling (for example, DynamoDB, EC2 Auto Scaling groups, RDS storage auto scaling, ECS capacity provider)
  • Creating CloudWatch custom metrics and metric filters, alarms, and notifications (for example, Amazon SNS, Lambda)
  • Configuring S3 events to process log files (for example, by using Lambda) and deliver log files to another destination (for example, OpenSearch Service, CloudWatch Logs)
  • Configuring EventBridge to send notifications based on a particular event pattern
  • Installing and configuring agents on EC2 instances (for example, AWS Systems Manager Agent [SSM Agent], CloudWatch agent)
  • Configuring AWS Config rules to remediate issues
  • Configuring health checks (for example, Route 53, ALB)

13.1 Amazon EventBridge ★★★ Core

EventBridge is the connective tissue of the whole exam: nearly every "when X happens, do Y" answer routes through an EventBridge rule. Know event patterns (match on source/detail-type/detail fields), targets (Lambda, SNS, SQS, Step Functions, Run Command, CodePipeline, incident tooling), scheduled rules, cross-account event buses, input transformers, archive and replay, and dead-letter queues for failed target invocations. Expect 3-5 questions.

Core docs

FAQ


13.2 CloudWatch Synthetics, RUM, and specialized monitoring ★★ Important

Synthetics canaries run scripted probes (heartbeat, API, broken-link, UI flows) on a schedule and alarm when user journeys break — the answer for "detect the outage before customers do" and for post-deployment validation. Know also CloudWatch RUM (real user monitoring), Container Insights and Lambda Insights (per-platform performance metrics), and Managed Grafana/Managed Service for Prometheus for Kubernetes-native monitoring stacks. Expect 1-2 questions.

Core docs


13.3 Health checks and event-driven notification patterns ★★ Important

Tie the health-check layers together: ALB target group checks mark targets unhealthy (and Auto Scaling replaces them when using ELB health checks), Route 53 health checks fail DNS over, EC2 status-check alarms trigger automatic recovery. For notifications, know S3 Event Notifications (to Lambda/SQS/SNS, prefix and suffix filters) vs EventBridge for S3 (richer filtering, multiple targets), and SNS fan-out to SQS. Expect 2-3 questions.

Core docs

FAQ


Part V — Domain 5: Incident and Event Response (14%)

The smallest domain, but it reuses everything from Domains 4 and 2: events in, automated response out, and structured troubleshooting when things break.

Chapter 14 — Event sources and processing

Maps to Task Statement 5.1 — Manage event sources to process, notify, and take action in response to events

Knowledge of:

  • AWS services that generate, capture, and process events (for example, AWS Health, EventBridge, CloudTrail)
  • Event-driven architectures (for example, fan out, event streaming, queuing)

Skills in:

  • Integrating AWS event sources (for example, AWS Health, EventBridge, CloudTrail)
  • Building event processing workflows (for example, Amazon Simple Queue Service [Amazon SQS], Kinesis, Amazon SNS, Lambda, Step Functions)

14.1 AWS Health and service events ★★ Important

AWS Health surfaces service events and scheduled changes affecting your resources (for example, EC2 maintenance, certificate expiry). Know the EventBridge integration for automating responses to Health events (the classic scenario: instance scheduled for retirement — automate a restart or migration) and organizational view for org-wide visibility. Expect 1-2 questions.

Core docs


14.2 Event processing building blocks ★★ Important

Know the queue/stream/topic selection logic: SQS to buffer and decouple (visibility timeout, DLQs, FIFO for ordering), SNS for fan-out to many subscribers, Kinesis for ordered streaming with replay, Step Functions when the response is a multi-step workflow. DLQs on Lambda event sources and EventBridge targets are the reliability detail the exam checks. Expect 2-3 questions.

Core docs

FAQ


Chapter 15 — Automated remediation

Maps to Task Statement 5.2 — Implement configuration changes in response to events

Knowledge of:

  • Fleet management services (for example, Systems Manager, AWS Auto Scaling)
  • Configuration management services (for example, AWS Config)

Skills in:

  • Applying configuration changes to systems
  • Modifying infrastructure configurations in response to events
  • Remediating a non-desired system state

15.1 Config rules with auto-remediation ★★★ Core

The remediation loop is a signature DOP-C02 pattern: Config rule detects noncompliance, remediation action runs an SSM Automation runbook (directly or via EventBridge and Lambda), resource returns to desired state. Know how to scope rules, pass resource IDs as runbook parameters, set retry behavior, and when to choose an SCP (prevent) instead of remediation (detect and fix). Expect 2-3 questions.

Core docs


15.2 Fleet response with Systems Manager and Auto Scaling ★★ Important

Event-driven fleet changes: EventBridge triggers Run Command or Automation against tagged instances; State Manager reapplies drifting configuration on a schedule; Auto Scaling replaces unhealthy instances automatically (set the instance to unhealthy via the API for forced replacement). Patch Manager plus maintenance windows handles emergent CVE patching at scale. Expect 1-2 questions.

Core docs


15.3 OpsCenter and Incident Manager ★★ Important

OpsCenter aggregates operational issues as OpsItems (auto-created from EventBridge/CloudWatch alarms) with linked runbooks for investigation. Incident Manager adds paging: response plans, escalation channels, on-call schedules, and automatic incident creation from alarms. Pick OpsCenter for "central place to track and resolve operational issues", Incident Manager for "engage responders automatically". Expect 1-2 questions.

Core docs


Chapter 16 — Troubleshooting failures

Maps to Task Statement 5.3 — Troubleshoot system and application failures

Knowledge of:

  • AWS metrics and logging services (for example, CloudWatch, X-Ray)
  • AWS service health services (for example, AWS Health, CloudWatch, Systems Manager OpsCenter)
  • Root cause analysis

Skills in:

  • Analyzing failed deployments (for example, AWS CodePipeline, CodeBuild, CodeDeploy, CloudFormation, CloudWatch synthetic monitoring)
  • Analyzing incidents regarding failed processes (for example, auto scaling, Amazon ECS, Amazon EKS)

16.1 Analyzing failed deployments ★★★ Core

Know where each tool records failure: CodeBuild build logs in CloudWatch Logs (phase that failed, exit code), CodeDeploy agent logs on the instance and lifecycle event failure reasons in the console, CloudFormation stack events and rollback reasons (plus UPDATE_ROLLBACK_FAILED recovery via ContinueUpdateRollback), and pipeline action failure details. Synthetics canaries validate the deployment from the user's perspective. Expect 2-3 questions.

Core docs


16.2 Troubleshooting scaling and container failures ★★ Important

Know the standard diagnoses: Auto Scaling activity history explains why instances launched/terminated or failed to launch (quota, AZ capacity, launch template errors); ECS stopped tasks carry a stoppedReason (image pull failure, health check failure, OOM); EKS troubleshooting goes through pod events and Container Insights. CloudWatch metrics plus X-Ray narrow application-level root cause. Expect 1-2 questions.

Core docs


16.3 AWS Fault Injection Service ★ Light

FIS runs controlled chaos experiments (terminate instances, inject API errors, stress CPU) with stop conditions tied to CloudWatch alarms. It is the answer when a scenario wants to validate resilience or test failover before a real incident. Usually one question or a distractor.

Core docs


Part VI — Domain 6: Security and Compliance (17%)

Security automation at organizational scale: least-privilege IAM, layered controls, and continuous auditing. Weighted equally with Domain 2 and drawing on the same multi-account machinery.

Chapter 17 — Identity and access management at scale

Maps to Task Statement 6.1 — Implement techniques for identity and access management at scale

Knowledge of:

  • Appropriate usage of different IAM entities for human and machine access (for example, users, groups, roles, identity providers, identity-based policies, resource-based policies, session policies)
  • Identity federation techniques (for example, using IAM identity providers and AWS IAM Identity Center)
  • Permission management delegation by using IAM permissions boundaries
  • Organizational SCPs

Skills in:

  • Designing policies to enforce least privilege access
  • Implementing role-based and attribute-based access control patterns
  • Automating credential rotation for machine identities (for example, Secrets Manager)
  • Managing permissions to control access to human and machine identities (for example, enabling multi-factor authentication [MFA], AWS Security Token Service [AWS STS], IAM profiles)

17.1 IAM policies and evaluation ★★★ Core

Professional-level IAM: policy evaluation order (explicit deny always wins; permission must survive SCP, permissions boundary, session policy, and identity/resource policy), identity-based vs resource-based policies (resource policies enable cross-account without role switching), condition keys (aws:PrincipalOrgID for org-scoped access, aws:SourceIp, MFA conditions), and attribute-based access control with tags. Roles for machines, never long-lived keys. Expect 3-4 questions.

Core docs

FAQ


17.2 Federation and machine identity ★★ Important

Know the federation menu: IAM Identity Center for workforce SSO, SAML/OIDC IAM identity providers for direct federation, and OIDC federation for CI systems (GitHub Actions assuming a role without stored keys — a modern favorite). For machine credentials, instance profiles and ECS task roles beat access keys; Secrets Manager rotates what must remain a secret (database passwords) on a schedule with Lambda rotation functions. Expect 2-3 questions.

Core docs

FAQ


17.3 SCPs and permissions boundaries in practice ★★★ Core

The exam repeatedly tests the difference between the permission guardrails: SCPs cap what any principal in an account can do (org-level, affects roles and root of member accounts, grants nothing), permissions boundaries cap what a specific IAM entity can do (delegation tool — let teams create roles that can't exceed the boundary), and session policies scope a single STS session. Know which layer solves which scenario and that an action must be allowed at every layer. Expect 2-3 questions.

Core docs


Chapter 18 — Security automation and data protection

Maps to Task Statement 6.2 — Apply automation for security controls and data protection

Knowledge of:

  • Network security components (for example, security groups, network ACLs, routing, AWS Network Firewall, AWS WAF, AWS Shield)
  • Certificates and public key infrastructure (PKI)
  • Data management (for example, data classification, encryption, key management, access controls)

Skills in:

  • Automating the application of security controls in multi-account and multi-Region environments (for example, Security Hub, Organizations, AWS Control Tower, Systems Manager)
  • Combining security controls to apply defense in depth (for example, AWS Certificate Manager [ACM], AWS WAF, AWS Config, AWS Config rules, Security Hub, GuardDuty, security groups, network ACLs, Amazon Detective, Network Firewall)
  • Automating the discovery of sensitive data at scale (for example, Amazon Macie)
  • Encrypting data in transit and data at rest (for example, AWS KMS, AWS CloudHSM, ACM)

18.1 AWS Security Hub ★★★ Core

Security Hub is the aggregation point: it collects findings from GuardDuty, Inspector, Macie, Config, and partners in a normalized format (ASFF), runs security standards (AWS Foundational Security Best Practices, CIS), and supports org-wide enablement with a delegated administrator account. Automated response is the flagship pattern: findings go to EventBridge, which triggers remediation Lambda/SSM; custom actions let analysts trigger the same from the console. Expect 2-3 questions.

Core docs

FAQ


18.2 GuardDuty and Detective ★★★ Core

GuardDuty is managed threat detection over CloudTrail, VPC Flow Logs, and DNS logs (no agents, plus protection plans for S3, EKS, RDS, Lambda, and malware). Know org-wide enablement with a delegated administrator, suppression rules, and the EventBridge-driven response pattern (finding triggers isolation/notification). Detective is the follow-on investigation tool that builds a behavior graph for root-causing a finding. Expect 2-3 questions.

Core docs

FAQ


18.3 Encryption: KMS, CloudHSM, and ACM ★★ Important

Know AWS managed vs customer managed KMS keys, key policies and grants, cross-account key use (key policy + IAM on both sides), automatic rotation, and multi-Region keys. ACM issues and auto-renews public TLS certificates for ELB/CloudFront/API Gateway (renewal is the selling point); Private CA issues internal certs; CloudHSM is the answer only for single-tenant, FIPS 140-2 Level 3, customer-controlled HSM requirements. Expect 2-3 questions.

Core docs

FAQ


18.4 Network security controls ★★ Important

Layer the controls: security groups (stateful, instance-level, allow rules only), network ACLs (stateless, subnet-level, allow and deny), AWS Network Firewall (managed VPC-level inspection with stateful rule groups), WAF (Layer 7 rules on ALB/CloudFront/API Gateway, rate-based rules), and Shield Standard vs Advanced for DDoS. Firewall Manager pushes WAF/security group/Network Firewall policies org-wide — the automation angle the exam cares about. Expect 1-2 questions.

Core docs

FAQ


18.5 Amazon Macie ★ Light

Macie discovers sensitive data (PII, credentials, financial data) in S3 at scale using machine learning and managed data identifiers, and continuously evaluates bucket security posture (public access, encryption). It is the answer for "find PII across hundreds of buckets automatically". Findings flow to Security Hub and EventBridge. Usually one question.

Core docs


Chapter 19 — Security monitoring and auditing

Maps to Task Statement 6.3 — Implement security monitoring and auditing solutions

Knowledge of:

  • Security auditing services and features (for example, CloudTrail, AWS Config, VPC Flow Logs, CloudFormation drift detection)
  • AWS services for identifying security vulnerabilities and events (for example, GuardDuty, Amazon Inspector, IAM Access Analyzer, AWS Config)
  • Common cloud security threats (for example, insecure web traffic, exposed AWS access keys, S3 buckets with public access enabled or encryption disabled)

Skills in:

  • Implementing robust security auditing
  • Configuring alerting based on unexpected or anomalous security events
  • Configuring service and application logging (for example, CloudTrail, CloudWatch Logs)
  • Analyzing logs, metrics, and security findings

19.1 AWS CloudTrail ★★★ Core

CloudTrail answers "who did what, when, from where". Know organization trails (one trail, all accounts, delivered to a central bucket), management vs data events (S3 object-level and Lambda invoke logging cost extra and are off by default), log file integrity validation (digest files detect tampering), delivery to CloudWatch Logs for metric-filter alerting (the classic root-login or unauthorized-API alarm), and CloudTrail Lake for SQL over events. Expect 2-3 questions.

Core docs

FAQ


19.2 IAM Access Analyzer and credential hygiene ★★ Important

Access Analyzer finds resources shared outside your zone of trust (account or organization) — S3 buckets, KMS keys, roles, and more — and validates policies before deployment. Know also the credential hygiene toolkit: credential reports, access advisor (last-accessed data for right-sizing policies), and the standard response runbook for exposed access keys (deactivate, review CloudTrail, rotate). Expect 1-2 questions.

Core docs


19.3 VPC Flow Logs and network auditing ★ Light

Flow logs capture accepted/rejected IP traffic metadata at the VPC, subnet, or ENI level, delivered to CloudWatch Logs or S3 (analyze with Logs Insights or Athena). They are the answer for "why is this connection failing" (look for REJECT records) and for network forensic evidence. Remember they show metadata, not packet contents. Usually one question.

Core docs

FAQ


19.4 Trusted Advisor and drift auditing ★ Light

Trusted Advisor checks accounts against best practices in cost, performance, security, fault tolerance, and service quotas (full checks require Business/Enterprise support; results can feed EventBridge for automation). Pair it mentally with CloudFormation drift detection: Trusted Advisor audits posture, drift detection audits divergence from declared infrastructure. Usually one question between them.

Core docs


Final checklist

Before you book the exam, you should be able to answer these without hesitation:

  • Design a cross-account CodePipeline: where do the artifact bucket, KMS key, and IAM roles live, and who assumes what?
  • Pick the right CodeDeploy deployment configuration and rollback trigger for EC2, ECS, and Lambda scenarios.
  • Choose between Beanstalk's five deployment policies given downtime, cost, and rollback constraints.
  • Explain how a StackSet with service-managed permissions deploys a guardrail to every new account in an OU automatically.
  • Wire a Config rule to an SSM Automation remediation, and say when an SCP is the better answer.
  • Pick the DR strategy (backup/restore, pilot light, warm standby, active/active) that meets a given RTO/RPO at lowest cost.
  • Trace the log pipeline: agent to log group, metric filter to alarm, subscription filter to Kinesis, export to S3 — and which steps are real time.
  • Route any "when X happens, do Y" scenario through the right EventBridge rule, target, and failure handling.
  • Describe the org-wide security stack: organization trail, delegated-admin GuardDuty and Security Hub, aggregated Config — and how findings become automated remediations.

Good luck — read every question twice, eliminate the answers that violate a constraint, and trust the documentation patterns you've studied.