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:
- Practicing Continuous Integration and Continuous Delivery on AWS — the single most exam-relevant whitepaper; covers pipeline stages, testing, and deployment methods.
- Introduction to DevOps on AWS — service-by-service overview of the DevOps toolchain.
- Blue/Green Deployments on AWS — every blue/green technique the exam draws from (Route 53, ELB, Auto Scaling, Beanstalk, ECS, Lambda).
- Disaster Recovery of Workloads on AWS — backup and restore, pilot light, warm standby, multi-site active/active. Domain 3 is written from this.
- Organizing Your AWS Environment Using Multiple Accounts — OU design and account strategy behind Domains 2 and 6.
- AWS Well-Architected Framework — foundational thinking for all AWS exams; the Reliability Pillar matters most here.
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
- What is AWS CodePipeline? — continuous delivery orchestration
- Pipeline structure reference — stages, actions, transitions, runOrder
- Action types — Source, Build, Test, Deploy, Approval, Invoke
- Input and output artifacts — S3-backed artifact store between stages
- Manual approval actions — human gate before production, SNS notification
- Cross-region actions — artifact stores in every region you deploy to
- Starting pipelines (triggers) — EventBridge rules vs webhooks vs schedule
- Invoke a Lambda function in a pipeline — custom actions, PutJobSuccessResult/PutJobFailureResult
- Monitoring pipelines with EventBridge — react to stage/action state changes
FAQ
Deeper reading
- Practicing CI/CD on AWS (whitepaper) — pipeline stage design, team maturity models
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
- What is AWS CodeBuild? — managed build service, pay per build minute
- Build specification reference — phases: install, pre_build, build, post_build; artifacts; reports
- Environment variables in build environments — plaintext, Parameter Store, Secrets Manager
- Build caching — S3 cache vs local (source, Docker layer, custom) cache
- Test reporting — report groups for unit test and coverage results
- Batch builds — build graph, build list, build matrix
- Docker sample (build and push to ECR) — privileged mode, ECR login
- CodeBuild in a VPC — reach private RDS/ElastiCache/internal services during builds
- Build environment compute types — sizes, ARM, GPU, Lambda compute
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
- What are connections? (CodeConnections) — OAuth-based links to GitHub, GitLab, Bitbucket
- AWS CodeCommit user guide — Git repositories on AWS; approval rule templates, triggers
- CodePipeline source actions — S3, ECR, CodeCommit, third-party via connections
- Git tags and branch triggers — filter pipeline starts by branch, tag, or file path
- GitHub webhook events with CodeBuild — run builds on pull requests and pushes
Deeper reading
- How to migrate from CodeCommit — context for why CodeCommit answers are fading from new question pools
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
- Test reporting in CodeBuild — JUnit/Cucumber/TestNG report groups, code coverage reports
- Buildspec syntax: reports and phases — on-failure behavior, finally blocks, exit codes
- CodePipeline test actions — CodeBuild and Device Farm as test providers
- Invoke Step Functions from a pipeline — orchestrate multi-step validation
- Using webhooks to test pull requests — PR-triggered builds gate merges
Deeper reading
- Practicing CI/CD on AWS: testing stages — the canonical mapping of test types to pipeline stages
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
- Amazon CodeGuru Reviewer — automated code reviews on repositories and PRs
- Amazon CodeGuru Profiler — always-on production profiling, flame graphs
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
- What is AWS CodeArtifact? — managed artifact repository
- CodeArtifact concepts — domains, repositories, packages, assets
- Upstream repositories — chain to npmjs, PyPI, Maven Central; pull-through caching
- Repository policies — cross-account access to packages
- Using CodeArtifact with CodeBuild — auth tokens in the buildspec
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
- What is Amazon ECR? — managed container registry
- Image scanning — basic vs enhanced (Amazon Inspector) scanning
- Lifecycle policies — expire images by age or count
- Private image replication — cross-region and cross-account
- Repository policies — cross-account image sharing
- Image tag mutability — immutable tags prevent overwrite
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
- What is EC2 Image Builder? — managed image pipelines for AMIs and containers
- Image pipelines — recipe, infrastructure config, distribution config, schedule
- Components — build and test steps in YAML documents
- Distribution settings — copy AMIs cross-region, share cross-account
- Integrations with other services — EventBridge, SNS notifications on image completion
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
- What is AWS CodeDeploy? — deployments to EC2/on-premises, Lambda, ECS
- Deployment configurations — built-in and custom minimum-healthy-hosts/canary/linear configs
- AppSpec file reference — structure differs by compute platform
- AppSpec hooks — lifecycle event order for EC2, ECS, Lambda
- Deployment groups — tag-based or Auto Scaling group targeting
- Redeployment and rollbacks — automatic rollback on failed deployment or alarm
- Working with the CodeDeploy agent — install via SSM, agent logs for troubleshooting
- CodeDeploy and Auto Scaling integration — lifecycle hook deploys to new instances; suspend during blue/green
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
- Blue/Green Deployments on AWS (whitepaper) — the canonical catalogue of techniques
- CodeDeploy blue/green on EC2 — in-place vs blue/green deployment types
- Route 53 weighted routing — DNS-level traffic shifting, beware client TTL caching
- Elastic Beanstalk blue/green (swap CNAMEs) — environment URL swap
- Elastic Beanstalk deployment policies — all at once, rolling, rolling with additional batch, immutable, traffic splitting
- API Gateway canary release deployments — stage-level canaries for APIs
Deeper reading
- Deployment strategies (Well-Architected Reliability Pillar) — change management best practices
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
- Lambda versions — immutable snapshots of code + config
- Lambda aliases — weighted traffic shifting between versions
- CodeDeploy deployments on Lambda — canary/linear/all-at-once alias shifting
- SAM gradual deployments — AutoPublishAlias, DeploymentPreference, hooks and alarms
- API Gateway canary release — test with a fraction of API traffic
- API Gateway stages — stage variables for environment-specific config
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
- ECS deployment types — rolling, blue/green (CodeDeploy), external
- ECS blue/green with CodeDeploy — task sets, target group switching, test traffic
- CodeDeploy deployments on ECS — appspec for ECS, lifecycle hooks
- ECS services — desired count, deployment circuit breaker
- ECS task definitions — revisions are the unit of deployment
- What is Amazon EKS? — managed Kubernetes control plane
- EKS managed node groups — rolling node updates
- IAM roles for service accounts (IRSA) — pod-level AWS permissions
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
- What is AWS Elastic Beanstalk? — PaaS on top of EC2/ELB/Auto Scaling
- Deployment policies and settings — the five policies compared, batch sizes
- Blue/green deployments (CNAME swap) — swap environment URLs
- Configuration files (.ebextensions) — customize resources and instance software
- Worker environments — SQS-driven background processing
- Managed platform updates — maintenance-window platform patching
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
- What is AWS CloudFormation? — declarative infrastructure as code
- Template anatomy — Parameters, Mappings, Conditions, Resources, Outputs
- Intrinsic function reference — Ref, GetAtt, Sub, ImportValue, ForEach
- Change sets — preview and approve updates
- DeletionPolicy attribute — Retain/Snapshot/Delete for stateful resources
- Stack policies — prevent unintentional updates to critical resources
- Drift detection — detect out-of-band changes
- Nested stacks — reusable template components
- Cross-stack references (Export/ImportValue) — share outputs between stacks
- CFN helper scripts (cfn-init, cfn-signal) — bootstrap EC2 and signal success
- CreationPolicy attribute — wait for cfn-signal before marking CREATE_COMPLETE
- Service role for CloudFormation — deploy with permissions the caller lacks
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
- Working with StackSets — multi-account, multi-region stack deployment
- StackSets concepts — stack sets, stack instances, operations
- Grant self-managed permissions — admin and execution roles
- Enable service-managed permissions (Organizations) — trusted access, automatic deployments to OUs
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
- Custom resources — Lambda-backed extension points
- Template macros — transform templates before deployment
- Modules — reusable, versioned resource packages in the registry
- CloudFormation Hooks — proactive compliance checks at provisioning time
- CloudFormation registry — public and private extensions
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
- What is the AWS CDK? — infrastructure in TypeScript, Python, Java, C#, Go
- CDK core concepts — apps, stacks, constructs
- Constructs — L1 (CFN), L2 (sane defaults), L3 (patterns)
- Bootstrapping — per-account/region toolkit resources
- CDK Pipelines — self-mutating pipelines that deploy CDK apps
- AWS CDK CLI — synth, diff, deploy, destroy
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
- What is AWS SAM? — serverless extension of CloudFormation
- SAM template anatomy — Transform, Globals, serverless resource types
- Gradual deployments — CodeDeploy-backed canary/linear traffic shifting
- sam build — compile and package
- sam deploy — deploy via CloudFormation
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
- What is AWS Service Catalog? — curated product portfolios
- Launch constraints — provision with a designated IAM role
- Sharing portfolios — cross-account and Organizations sharing
- TagOptions — enforce tagging on provisioned products
- What is AWS Proton? — platform templates for container/serverless services
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
- What is AWS Organizations? — central account management
- Service control policies (SCPs) — maximum-permission guardrails
- SCP evaluation — inheritance, FullAWSAccess, deny lists vs allow lists
- Managing OUs — organize accounts into a hierarchy
- Tag policies — standardize tags across accounts
- Trusted access with AWS services — enable org-wide service integration
- Delegated administrator — administer org services from a member account
FAQ
Deeper reading
- Organizing Your AWS Environment Using Multiple Accounts (whitepaper) — recommended OU structure
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
- What is AWS Control Tower? — managed landing zone
- How Control Tower works — shared accounts, landing zone structure
- About controls — preventive, detective, proactive guardrails
- Provision accounts with Account Factory — standardized account vending
- Customize with Account Factory Customization — attach custom blueprints at provisioning
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
- What is IAM Identity Center? — workforce SSO across accounts and apps
- Permission sets — templates for account-level roles
- Identity sources — Identity Center directory, AD, external IdP
- Cross-account access with IAM roles — the delegation tutorial
- AssumeRole — temporary credentials across accounts
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
- What is AWS Systems Manager? — operations hub for AWS and hybrid fleets
- Run Command — run commands at scale without SSH
- State Manager — associations enforce desired state on a schedule
- Patch Manager — patch baselines, patch groups, compliance reporting
- Maintenance Windows — schedule disruptive tasks
- Automation runbooks — multi-step operational workflows
- Session Manager — auditable access, session logs to S3/CloudWatch
- Inventory — collect software/config metadata fleet-wide
- Parameter Store — config and SecureString secrets
- SSM Agent — prerequisite on every managed node
- Hybrid and multicloud (activations) — manage on-premises servers
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
- What is AWS Config? — configuration recorder and compliance engine
- Managed rules — prebuilt checks (encrypted volumes, public buckets, tags)
- Custom rules — Lambda-backed and Guard-backed evaluations
- Remediating noncompliant resources — automatic remediation with SSM Automation
- Conformance packs — packaged rule sets, org deployment
- Multi-account multi-region aggregation — aggregators and authorizations
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
- What is AWS Step Functions? — workflow orchestration
- Standard vs Express workflows — durability vs throughput
- Error handling (Retry, Catch) — per-state retries with backoff
- Service integrations — call AWS APIs directly from states
- Lambda quotas — timeout, concurrency, payload limits
- Lambda concurrency — reserved vs provisioned
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
- What is AWS AppConfig? — safe configuration deployment
- AppConfig deployment strategies — gradual rollout, bake time, rollback on alarm
- Feature flags — toggle features at runtime
- AWS OpsWorks documentation — legacy managed Chef/Puppet (end of life 2024)
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
- Routing policies — simple, weighted, latency, failover, geolocation
- DNS failover — active-passive and active-active configurations
- Health checks — endpoint, calculated, alarm-based
- Alias records — free queries to AWS targets, evaluate target health
- Route 53 Application Recovery Controller — readiness checks and routing controls for failover
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
- What is Elastic Load Balancing? — traffic distribution across AZs
- Application Load Balancer — Layer 7 routing, listener rules
- Network Load Balancer — Layer 4, static IPs, extreme scale
- Target group health checks — thresholds, intervals, success codes
- Cross-zone load balancing — how ELB spreads traffic across AZs
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
- RDS Multi-AZ deployments — synchronous standby, automatic failover
- RDS read replicas — async replication, cross-region, promotion
- Aurora high availability — Aurora replicas, failover priorities
- Aurora Global Database — cross-region storage-level replication
- DynamoDB global tables — multi-region, multi-active replication
- S3 replication — CRR/SRR, Replication Time Control
- ElastiCache Global Datastore — cross-region Redis replication
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
- What is Amazon EC2 Auto Scaling? — fleets that scale and self-heal
- Dynamic scaling policies — target tracking, step, simple
- Target tracking scaling — keep a metric at a target value
- Predictive scaling — ML forecasting for cyclical load
- Lifecycle hooks — pause instances at launch/termination
- Health checks — EC2 status vs ELB health, grace period
- Instance refresh — rolling replacement after AMI/launch template change
- Warm pools — pre-initialized capacity for slow-boot apps
- Launch templates — versioned launch config, required for newer features
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
- What is Application Auto Scaling? — scaling for non-EC2 resources
- DynamoDB auto scaling — scale provisioned RCU/WCU
- RDS storage autoscaling — grow storage automatically
- ECS service auto scaling — target tracking on CPU/memory/ALB requests
- Aurora Serverless v2 — ACU-based capacity scaling
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
- ECS capacity providers — managed scaling of underlying capacity
- AWS Fargate on ECS — serverless containers, no cluster scaling
- EKS autoscaling — Cluster Autoscaler, Karpenter
- Fargate on EKS — Fargate profiles for pods
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
- Lambda concurrency — reserved vs provisioned, throttling behavior
- API Gateway throttling — account and stage limits, usage plans
- API Gateway caching — stage-level response cache
- Using Lambda with SQS — buffering, batch size, scaling behavior
- What is Amazon CloudFront? — global edge caching
- ElastiCache caching strategies — lazy loading vs write-through
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
- Disaster Recovery of Workloads on AWS (whitepaper) — the canonical DR reference
- DR options in the cloud — the four strategies compared
- Reliability Pillar — failure management and DR testing
- AWS Resilience Hub — assess apps against RTO/RPO policies
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
- What is AWS Backup? — centralized backup management
- Backup plans — schedules, lifecycle, copy actions
- Cross-account backup — copy to a central backup account
- Backup Vault Lock — WORM protection for recovery points
- DynamoDB point-in-time recovery — continuous backups, 35 days
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
- What is AWS Elastic Disaster Recovery? — block-level replication, on-demand recovery
- Failback and drills — recovery drills without disruption
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
- What is Amazon CloudWatch? — metrics, alarms, dashboards, logs
- CloudWatch concepts — namespaces, dimensions, resolution, statistics
- Publishing custom metrics — PutMetricData, high-resolution metrics
- Embedded metric format — metrics from structured log output
- Metric streams — continuous export via Firehose to S3/partners
- Using metric math — derived metrics for alarms and dashboards
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
- What is CloudWatch Logs? — log groups, streams, retention
- Metric filters — create metrics from log events
- Filter and pattern syntax — match terms, JSON fields, space-delimited logs
- Subscription filters — real-time delivery to Kinesis, Firehose, Lambda
- Cross-account log data sharing — centralize logs via Kinesis destinations
- Export log data to S3 — batch export, up to 12 hours to complete
- Encrypt log data with KMS — customer managed keys on log groups
- CloudWatch Logs Insights — query language for log analysis
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
- Collect metrics and logs with the CloudWatch agent — unified agent overview
- Create IAM roles for the agent — permissions for metric/log upload
- Install the agent using Run Command — fleet-wide installation
- Agent configuration file — metrics and logs sections, store in Parameter Store
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
- What is Amazon Kinesis Data Streams? — real-time streaming, shard capacity
- What is Amazon Data Firehose? — managed delivery to S3, OpenSearch, Redshift
- Firehose data transformation — Lambda transform before delivery
- Amazon OpenSearch Service — search and visualize aggregated logs
- S3 lifecycle management — transition and expire archived logs
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
- Using CloudWatch alarms — thresholds, evaluation periods, missing data
- CloudWatch anomaly detection — ML-based expected-value bands
- Combining alarms (composite alarms) — alarm on a rule expression across alarms
- Alarm actions for EC2 — recover, stop, terminate, reboot
- ALB CloudWatch metrics — 5xx counts, target response time, healthy host count
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
- CloudWatch Logs Insights — fields, filter, stats, parse
- CloudWatch dashboards — cross-region, cross-account views
- What is Amazon Athena? — serverless SQL over S3
- Querying CloudTrail logs with Athena — the standard audit-analysis pattern
- Querying ALB logs with Athena — access log analysis
- What is Amazon QuickSight? — BI dashboards over Athena/S3
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
- What is AWS X-Ray? — distributed tracing
- X-Ray concepts — segments, annotations vs metadata, sampling
- X-Ray with Lambda — active tracing configuration
- X-Ray with API Gateway — trace API requests
- Running the X-Ray daemon on Amazon ECS — sidecar pattern for containers
- Sampling rules — control trace volume
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
- What is Amazon Inspector? — continuous vulnerability scanning
- Scanning EC2 instances — SSM Agent based collection
- Scanning ECR container images — enhanced scanning integration
- Findings in Amazon Inspector — severity scoring, EventBridge integration
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
- What is Amazon EventBridge? — serverless event bus
- Event patterns — JSON matching on event fields
- Rules — route matched events to targets
- Targets — Lambda, SQS, SNS, Step Functions, SSM, and more
- Scheduled rules and EventBridge Scheduler — cron and rate schedules
- Cross-account event buses — centralize events from an organization
- Archive and replay — reprocess historical events
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
- CloudWatch Synthetics canaries — scheduled scripted monitoring
- CloudWatch RUM — real user performance telemetry
- Container Insights — ECS/EKS cluster and task metrics
- Lambda Insights — function-level performance metrics
- Amazon Managed Grafana — managed visualization
- Amazon Managed Service for Prometheus — Prometheus-compatible metrics at scale
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
- ALB target group health checks — thresholds and routing behavior
- Auto Scaling health checks — EC2 vs ELB health check types
- Route 53 health checks — DNS failover behavior
- EC2 automatic recovery — recover on system status check failure
- S3 Event Notifications — Lambda, SQS, SNS destinations
- Using EventBridge with S3 — all events, advanced filtering
- SNS fan-out to SQS — parallel processing pattern
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
- What is AWS Health? — personalized service health events
- Monitoring AWS Health events with EventBridge — automate responses to Health events
- Organizational view — aggregate Health events across an organization
- AWS Health Dashboard — account-specific vs public status
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
- What is Amazon SQS? — queues, visibility timeout, DLQs
- SQS dead-letter queues — isolate poison messages
- What is Amazon SNS? — pub/sub, message filtering
- Lambda event source mappings — batching, error handling, DLQs
- Lambda asynchronous invocation — retries, destinations, DLQs
- Step Functions callback patterns — wait for external completion with task tokens
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
- Remediating noncompliant resources with Config — automatic remediation with SSM documents
- SSM Automation runbooks — the remediation execution engine
- AWS-managed Automation runbooks — prebuilt runbooks (restart, resize, disable keys)
- Config rules with EventBridge — react to compliance change events
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
- Run Command — targeted commands by tag or resource group
- State Manager associations — continuous desired-state enforcement
- Patch Manager — emergency and scheduled patching
- Set instance health (Auto Scaling) — force replacement of a bad instance
- EventBridge targets: Systems Manager — Run Command as a rule target
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
- Systems Manager OpsCenter — OpsItems, operational issue tracking
- What is AWS Systems Manager Incident Manager? — response plans, escalations, chat channels
- Creating incidents from CloudWatch alarms — automatic incident creation
- Systems Manager Explorer — multi-account ops data rollup
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
- Troubleshooting CodeDeploy — deployment and agent failures
- View CodeDeploy agent logs — instance-side diagnostics
- Troubleshooting CloudFormation — stack failures, rollback-failed recovery
- Logging CodeBuild builds — build logs and phases
- Troubleshooting CodePipeline — common pipeline errors
- CloudWatch Synthetics canaries — post-deploy user-path validation
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
- Troubleshooting Amazon EC2 Auto Scaling — launch failures, health check loops
- Viewing ECS stopped task errors — stoppedReason diagnostics
- Amazon EKS troubleshooting — node and pod failures
- Container Insights — cluster performance metrics
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
- What is AWS Fault Injection Service? — managed chaos engineering
- FIS experiment templates — actions, targets, stop conditions
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
- Policies and permissions in IAM — policy types and structure
- Policy evaluation logic — how allow/deny is decided across policy types
- Identity-based vs resource-based policies — cross-account implications
- Permissions boundaries — delegate role creation safely
- IAM condition keys — org ID, source IP, MFA, tags
- Attribute-based access control (ABAC) — tag-driven permissions
- IAM roles — trust policies, temporary credentials
- Security best practices in IAM — least privilege, roles over users
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
- Identity providers and federation — SAML and OIDC IdPs
- OIDC identity providers — federate CI systems like GitHub Actions
- AWS STS temporary credentials — AssumeRole variants
- What is AWS Secrets Manager? — secret storage with rotation
- Rotate secrets — managed rotation for RDS, custom Lambda rotation
- IAM roles for EC2 (instance profiles) — credentials without keys
- ECS task IAM roles — per-task permissions
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
- Service control policies — organization-level guardrails
- Permissions boundaries — entity-level maximum permissions
- Session policies — scope down assumed-role sessions
- Policy evaluation for accounts in an organization — cross-account evaluation walkthrough
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
- What is AWS Security Hub? — findings aggregation and standards
- Security standards — FSBP, CIS, PCI DSS controls
- Automated response and remediation — EventBridge integration, custom actions
- Managing administrator and member accounts — org-wide enablement, delegated admin
- AWS Security Finding Format (ASFF) — normalized finding schema
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
- What is Amazon GuardDuty? — intelligent threat detection
- GuardDuty finding types — reconnaissance, credential compromise, crypto mining
- Managing GuardDuty accounts with Organizations — delegated admin, auto-enable
- Responding to findings with EventBridge — automated response pattern
- What is Amazon Detective? — behavior-graph investigation
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
- What is AWS KMS? — managed cryptographic keys
- Key policies — the primary access control for keys
- Rotating KMS keys — automatic annual rotation
- Multi-Region keys — replicate keys for cross-region decryption
- What is AWS Certificate Manager? — free public certs, managed renewal
- AWS Private Certificate Authority — internal PKI
- What is AWS CloudHSM? — dedicated single-tenant HSMs
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
- Security groups — stateful instance-level firewall
- Network ACLs — stateless subnet-level rules
- What is AWS WAF? — web ACLs, managed rules, rate limiting
- AWS Shield — Standard vs Advanced DDoS protection
- What is AWS Network Firewall? — managed network traffic inspection
- AWS Firewall Manager — org-wide security policy management
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
- What is Amazon Macie? — sensitive data discovery for S3
- Sensitive data discovery jobs — scheduled and one-time scans
- Monitoring S3 security posture — bucket-level security evaluation
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
- What is AWS CloudTrail? — API activity auditing
- Organization trails — org-wide logging to a central bucket
- Management and data events — control plane vs data plane logging
- Log file integrity validation — tamper detection with digests
- Sending events to CloudWatch Logs — metric filters and alarms on API activity
- CloudTrail Lake — SQL queries over event data
- CloudTrail Insights — anomalous API call volume detection
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
- What is IAM Access Analyzer? — external access findings, policy validation
- Access Analyzer findings — resources shared with external principals
- IAM credential reports — audit credential age and MFA
- Refining permissions using last accessed information — trim unused permissions
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
- VPC Flow Logs — traffic metadata capture
- Flow log records — fields, ACCEPT/REJECT
- Querying VPC Flow Logs with Athena — SQL analysis of network traffic
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
- AWS Trusted Advisor — best-practice checks
- CloudFormation drift detection — detect out-of-band changes to stacks
- AWS Compute Optimizer — right-sizing recommendations
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.