How to pass AWS Certified DevOps Engineer - Professional (DOP-C02)
33 min read6 domains coveredFree practice, no sign-up
The AWS Certified DevOps Engineer - Professional (DOP-C02) tests one thing above feature recall: can you design and automate the delivery, operation and governance of a production AWS workload under pressure. Amazon hands you a scenario with a real constraint - a pipeline that must deploy across accounts, a release that cannot drop a single request, a recovery time and recovery point you have to meet, a guardrail an account administrator must not be able to remove, an incident that must remediate itself with no operator awake - and asks which AWS approach meets it. The hard part is rarely knowing what a service is. It is choosing the option that meets the stated requirement with the most automation, the smallest blast radius and the least operational overhead when three of the four answers look plausible.
It suits people who already build and run delivery pipelines on AWS: DevOps engineers, platform and SRE practitioners, and release and infrastructure engineers who automate CI/CD, write infrastructure as code, design for resilience, instrument observability and respond to incidents day to day. The exam draws across six weighted domains. SDLC Automation carries the most marks, followed closely by Configuration Management and Infrastructure as Code and by Security and Compliance, then Resilient Cloud Solutions and Monitoring and Logging, with Incident and Event Response close behind. As a professional exam the questions are longer, the scenarios layer several services, and the trade-offs are sharper than at associate level.
The exam rewards engineering decision rules, not memorised limits. Most questions are dense scenarios where two or three answers are technically capable and only one is the best fit once you weigh the constraint that was named: deploy with zero downtime, keep the change auditable, recover within a stated objective, enforce the rule preventively rather than detect it after the fact, or fix it with the least manual effort. Practising on scenario questions with a worked explanation, and a reason every wrong option is wrong, beats reading service overviews because the skill under test is choosing correctly under that pressure.
DOP-C02 is an automate-it-correctly professional exam: almost every question is a layered scenario with a delivery, resilience, observability, incident or governance constraint, and the right answer is the AWS-native approach that meets it with the most automation, the smallest blast radius and the least operational overhead.
Difficulty
Advanced
Best for
Working AWS delivery and platform engineers: DevOps, platform and SRE practitioners, release engineers and infrastructure engineers who build CI/CD pipelines, author infrastructure as code, design resilient multi-account systems, run observability and automate incident response on AWS and need to prove they can do it under professional-level trade-offs.
Prerequisites
None enforced, but DOP-C02 expects real AWS experience. AWS recommends roughly two or more years provisioning, operating and managing AWS environments, and fluency with at least one programming language for build and automation scripting. Hands-on time with CodePipeline, CodeBuild, CodeDeploy, CloudFormation or the CDK, CloudWatch, EventBridge, Systems Manager, IAM and AWS Organizations is what actually carries you through the scenarios.
75
Questions
180 min
Time allowed
750 / 1000
Pass mark
$300
Exam cost (USD)
288
Practice questions
How this exam thinks
One habit decides this exam: read the long scenario for its real constraint, then pick the AWS-native approach engineered to meet it. The answer is almost never the most powerful or the most hand-rolled option. It is the most automated, most resilient, lowest-operational-overhead option that fits the stated requirement, whether that requirement is zero downtime, a named recovery time and recovery point, a bounded blast radius, an auditable change, or a guardrail that holds even against an account administrator.
The default tie-breaker is the managed, automated, least-overhead AWS-native option. AWS builds the exam around its own preference for managed automation, so when two answers both work, the one with less to build and operate usually wins: a failing CodeBuild action that natively halts the pipeline over a custom Lambda that calls StopPipelineExecution, ACM managed renewal over a scheduled reissue function, an EventBridge event pattern over a polling job, AWS Chatbot over a self-hosted Slack formatter, an Organizations service control policy over an IAM deny policy attached in every account. Reach for the manual, heavier, or more privileged option only when the scenario names a reason. That reason is the signal that the obvious automated answer is the trap.
The rest is a handful of professional discriminations the exam leans on. For delivery, a failed action halts a CodePipeline stage on its own, BeforeAllowTraffic gates a CodeDeploy revision before the load balancer sees it, and canary configurations hold one slice then shift the rest while linear configurations ramp in equal timed increments. For infrastructure as code, a stack policy protects a single resource from updates while the rest of the stack stays updatable, a change set previews replacements before they happen, StackSets and organisation conformance packs roll a baseline across accounts and auto-onboard new ones, and drift detection only reports out-of-band changes. For resilience, the disaster-recovery tier is chosen by the named RTO and RPO, and a cross-account backup copy puts recovery points outside the production blast radius. For incidents, an EventBridge rule or a CloudWatch Logs subscription filter drives serverless remediation with no human and no server, and CloudTrail attributes a past change to a principal, time and source IP. For governance, a service control policy sets a preventive ceiling that local IAM cannot override, and OIDC role assumption removes stored keys. Name the constraint, then choose the service built for it.
What each domain tests and how to study it
The DOP-C02 blueprint is split across 6 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.
What you must be able to do. Given a delivery scenario, choose the CodePipeline, CodeBuild, CodeDeploy or serverless deployment design that ships the change repeatably, gates it automatically, and meets the stated downtime, rollback and cross-account requirement with the least custom orchestration.
In one sentenceThe largest domain: orchestrate multi-stage, cross-account CI/CD, let test exit codes gate the pipeline natively, and pick the right deployment strategy - in-place, blue/green, canary or linear - for the stated downtime and rollback need.
Recall check: answer these from memory first
An integration-test stage must stop the pipeline and block promotion to production with no human watching and the least custom logic. What gates it, and why is a manual approval or a StopPipelineExecution Lambda unnecessary?
In which CodeDeploy AppSpec lifecycle hook does a smoke test gate a new EC2 revision before the load balancer routes production traffic to it, and which hooks run before and after it?
A cross-account CodePipeline deploy fails with access denied even though the production-account role exists and the artifact store uses a customer managed KMS key. What three grants must the target role hold together?
What it tests. Building and operating the delivery pipeline. Orchestrating multi-stage AWS CodePipeline pipelines with source, build, test, manual approval and deploy stages and cross-account and cross-Region actions; configuring managed builds with AWS CodeBuild, buildspec files, build caching and AWS CodeConnections to external Git repositories; wiring automated unit, integration and security tests with CodeBuild test reports as native pipeline quality gates; versioning and sharing artifacts with AWS CodeArtifact, Amazon ECR and Amazon S3 artifact stores including image signing; implementing in-place and blue/green deployments for Amazon EC2 and on-premises with AWS CodeDeploy, deployment groups and Auto Scaling groups; deploying containers on Amazon ECS and Amazon EKS with blue/green and rolling updates; and implementing canary and linear deployments for AWS Lambda and serverless with AWS CodeDeploy, the AWS Serverless Application Model and Amazon API Gateway stages.
How to study it. Make the pipeline-gating reflex automatic: a CodeBuild action that exits non-zero fails its CodePipeline stage and blocks promotion on its own, so a test command is itself the quality gate with no custom orchestration. Learn the CodeDeploy AppSpec lifecycle order cold and where each hook gates traffic: ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, then BeforeAllowTraffic (validate the new revision before the load balancer routes to it), then AllowTraffic, then AfterAllowTraffic. Fix the deployment-strategy split until the named requirement decides it: in-place reuses instances and risks downtime, blue/green stands up a parallel fleet for instant cutover and fast rollback, canary holds one fixed slice then shifts the remainder in one step, and linear ramps equal increments on a fixed timer. For cross-account deploys, remember the target role needs three things together - assume-role trust, S3 read on the artifact bucket, and key-usage rights on the customer managed AWS KMS key - or the deploy fails with access denied even when the role exists.
Easy to confuse
CodeDeploy blue/green versus in-place deployment. Blue/green provisions a parallel replacement fleet and cuts traffic over once it is healthy, so rollback is an instant traffic switch back with no downtime; an in-place deployment updates the existing instances in batches, so a bad revision touches live capacity and rollback means redeploying the previous version. Choose blue/green when the requirement is zero downtime or fast rollback.
Canary versus linear CodeDeploy configuration. A canary configuration such as Canary10Percent10Minutes routes one fixed slice, holds for the named interval while alarms are watched, then shifts the entire remainder in a single step; a linear configuration such as Linear10PercentEvery10Minutes adds equal increments on a fixed timer until complete. Match the wording: one hold-then-jump is canary, repeated equal steps is linear.
Failing CodeBuild action versus a StopPipelineExecution Lambda. A CodePipeline action that returns failure halts its stage and blocks promotion to the next stage natively, so a test that exits non-zero is the quality gate with zero extra wiring; an EventBridge rule invoking a Lambda that calls StopPipelineExecution rebuilds behaviour the pipeline already has. Let the action fail rather than orchestrate the halt yourself.
Worked example from the DOP-C02 bank
lock_openFree sampleSDLC Automationhard
A platform team uses AWS CodeDeploy to release to an Amazon EC2 fleet and wants every new revision to run an automated smoke test against the freshly installed application before the instance is allowed to receive production traffic from the load balancer. If the smoke test fails, the deployment should stop and not route traffic to that revision. In which AppSpec lifecycle event hook should the team place this smoke test so it gates traffic correctly?
APlace the smoke test in the AfterAllowTraffic hook, which runs once CodeDeploy has registered the instance behind the load balancer so the test exercises the genuinely live production endpoint.
BPlace the smoke test in the ApplicationStop hook, which runs at the start of the deployment so the test confirms the application is healthy before the new revision is installed over it.
CPlace the smoke test in the BeforeAllowTraffic hook, which runs after the application is installed and started but before CodeDeploy registers the instance to receive load balancer traffic.check_circle Correct
DPlace the smoke test in the BeforeInstall hook, which runs before files are copied so the test can verify the build is sound before CodeDeploy commits to deploying it on the host.
Use the CodeDeploy BeforeAllowTraffic lifecycle hook to validate a new revision before the load balancer routes production traffic to it. CodeDeploy runs lifecycle hooks in a defined order; BeforeAllowTraffic fires after Install and ApplicationStart but before the instance is re-registered with the load balancer, so a failing hook halts the deployment before any production traffic reaches the new revision.
Why A is wrong: AfterAllowTraffic runs only after traffic is already flowing, so a failure there means production users have already hit the bad revision; it cannot gate traffic before exposure.
Why B is wrong: ApplicationStop runs against the old revision before the new files are even copied, so it cannot validate the new build at all and is irrelevant to gating traffic for the release.
Why C is correct: BeforeAllowTraffic runs after install and start yet before the instance is re-registered to the load balancer, so a failing test stops the deployment and prevents production traffic reaching the new revision.
Why D is wrong: BeforeInstall runs before the new revision is on the instance, so there is nothing deployed to smoke test; it is used for pre-install setup, not for validating the running application.
What you must be able to do. Given a provisioning or governance-of-infrastructure scenario, choose the CloudFormation, CDK, StackSets, Service Catalog or Systems Manager approach that provisions repeatably, previews risky changes, protects critical resources, and rolls a baseline across accounts with the least ongoing effort.
In one sentenceThe infrastructure-as-code domain: model resources as code with CloudFormation and the CDK, preview replacements with change sets, protect single resources with stack policies, roll baselines across accounts with StackSets and conformance packs, and manage fleets with Systems Manager.
Recall check: answer these from memory first
One hand-tuned security group inside a production stack must never be modified or deleted by a routine template update while the rest of the stack stays updatable. Which in-stack guardrail does this, and why not a DeletionPolicy or stack termination protection?
Before updating a production stack you must reveal exactly which resources an update would replace by recreating them. Which mechanism surfaces this, and why does drift detection not answer it?
The same AWS Config rules and remediation must deploy into every account in an organisational unit and any account that joins later must inherit them automatically, as one versioned package. What achieves this with the lowest ongoing effort?
What it tests. Provisioning and governing infrastructure as code. Defining infrastructure with AWS CloudFormation templates, nested stacks, change sets and stack policies; building reusable components with the AWS Cloud Development Kit, CloudFormation modules and the AWS Serverless Application Model; provisioning and governing across accounts and Regions with AWS CloudFormation StackSets, AWS Service Catalog and AWS Resource Access Manager; detecting and remediating drift and managing resource lifecycle with CloudFormation drift detection, DeletionPolicy and UpdateReplacePolicy and AWS Config; configuring instances at scale with AWS Systems Manager State Manager, Run Command, Patch Manager and Parameter Store; and deploying automated configuration and remediation with AWS Config rules, AWS Systems Manager Automation runbooks and Amazon EC2 Image Builder for golden images.
How to study it. Learn the CloudFormation feature split cold, because the exam leans on it hard. A stack policy is an in-stack guardrail that denies Update:Modify or Update:Delete on one logical ID while the rest of the stack stays updatable, which is different from a DeletionPolicy (controls what happens to a resource on stack delete) and from termination protection (blocks deleting the whole stack). A change set previews a planned update and sets a Replacement indicator on each resource that would be recreated, so reviewers catch a disruptive recreate before it runs - drift detection cannot do this because it only reports changes already made outside CloudFormation. For multi-account rollout, distinguish StackSets (one template to many accounts and Regions from a management or delegated admin account) from an AWS Config organisation conformance pack (a packaged set of Config rules and remediation that auto-onboards any account joining the target organisational unit). For reusable CDK constructs, the answer is a versioned package on a private registry, not git submodules or a public Construct Hub. Map the Systems Manager toolset: State Manager enforces a desired state on a schedule, Run Command runs a one-off command, Patch Manager patches at scale, Parameter Store holds configuration, and Automation runbooks orchestrate multi-step fixes.
Easy to confuse
Stack policy versus DeletionPolicy. A stack policy is evaluated on every stack update and can deny Update:Modify or Update:Delete on a specific logical resource while allowing the rest, protecting it during routine updates; a DeletionPolicy or UpdateReplacePolicy only controls what happens to a resource when the stack itself is deleted or the resource is replaced. Use a stack policy to stop in-place modification, not a DeletionPolicy.
Change set versus drift detection. A change set previews how a newly submitted template would alter the stack and flags each resource a Replacement would recreate before anything is applied; drift detection compares live resources against the deployed template and reports changes already made outside CloudFormation after the fact. Change set for a planned update, drift detection for out-of-band edits.
CloudFormation StackSets versus organisation conformance pack. StackSets deploy one CloudFormation template to many target accounts and Regions and can auto-deploy to new accounts in an organisational unit; an AWS Config organisation conformance pack is the purpose-built way to roll a versioned set of Config rules and their remediation across an organisational unit and auto-onboard joiners. For a Config-rule baseline specifically, reach for the conformance pack.
CDK construct on a private registry versus a git submodule. Publishing reusable CDK constructs as a versioned language package to a private package registry lets teams pin a version and pull updates through their normal package manager; a git submodule forces every team to build from source and offers no clean version pinning. The package on the private registry is the supported distribution model.
Worked example from the DOP-C02 bank
lock_openFree sampleConfiguration Management and Infrastructure as Codemedium
An engineer is about to change the name property of a resource in an "AWS CloudFormation" stack and knows from experience that some property changes force CloudFormation to replace the resource by creating a new one and deleting the old. Before running the update on a production stack, the engineer wants the pipeline to reveal exactly which resources would be replaced so a risky change can be caught in review. Which mechanism MOST directly surfaces the replacement impact ahead of time?
ARun drift detection on the stack first so the report identifies which resources the pending update is going to replace once it runs.
BCreate a change set for the proposed update and inspect its "Replacement" field, which marks each resource that the update would replace before any change is applied.check_circle Correct
CAdd an "UpdateReplacePolicy" of "Retain" to the resource so that the pipeline lists every resource that would be replaced when the update runs.
DValidate the template with the validate-template operation so the pipeline returns the list of resources that the update would need to replace.
Use a CloudFormation change set and its Replacement field to preview which resources an update would recreate before applying it. Some property updates cannot be applied in place, so CloudFormation replaces the resource by provisioning a new one and removing the old; a change set describes the planned actions and sets a Replacement indicator for each affected resource, letting reviewers detect a disruptive recreate during approval rather than discovering it mid-deployment.
Why A is wrong: Drift detection compares live resources to the currently deployed template, not to a proposed new template, so it reveals existing drift rather than the replacements a future update would cause.
Why B is correct: A change set computes the resource-level diff against the live stack, including a Replacement value of True for resources that an update would recreate, so reviewers see the exact replacement impact before execution.
Why C is wrong: UpdateReplacePolicy only decides whether the old resource is kept or deleted when a replacement happens; it changes the outcome of replacement but does not preview which resources will be replaced.
Why D is wrong: Template validation only checks structural correctness and parameter declarations; it has no view of the deployed stack, so it cannot determine which resources an update would replace.
What you must be able to do. Given availability and recovery requirements with a stated RTO and RPO, choose the Multi-AZ, scaling, caching, throttling, disaster-recovery and backup design that meets the target with the least operational overhead and keeps recovery points outside the production blast radius.
In one sentenceThe resilience domain: spread across Availability Zones, scale and decouple to absorb demand, protect fragile backends with throttling and caching, and match the disaster-recovery tier and cross-account backup design to the named RTO and RPO.
Recall check: answer these from memory first
A single-AZ Amazon RDS payments database must survive an Availability Zone failure with automatic failover and no application code change, at the lowest operational overhead. What design meets this, and why not a cross-Region read replica?
Backups must be isolated so that a full compromise of the production account cannot reach or delete them, while the existing AWS Backup plans keep running. What is the most appropriate isolation, and why is Vault Lock or an IAM permission boundary insufficient?
A latency-sensitive Lambda function behind API Gateway suffers cold starts at the start of each business day. What keeps a predictable number of environments warm before the surge, and why is reserved concurrency the wrong lever?
What it tests. Designing for availability and recovery. Building highly available architectures with Multi-AZ deployments, Elastic Load Balancing, Amazon Route 53 and loosely coupled designs; scaling with EC2 Auto Scaling, serverless compute, Amazon DynamoDB and decoupling with Amazon SQS and Amazon SNS; accelerating and protecting workloads with Amazon CloudFront, Amazon ElastiCache and Amazon API Gateway caching and request throttling; selecting and automating disaster-recovery strategies (backup and restore, pilot light, warm standby, multi-site active/active) to meet recovery time and recovery point objectives across Regions; and automating backup and recovery with AWS Backup, AWS Elastic Disaster Recovery, snapshots and cross-Region and cross-account replication.
How to study it. Anchor on matching the design to the named RTO and RPO and the named failure scope. Convert a single-AZ database that must survive a zonal fault with automatic failover and no code change to RDS Multi-AZ (synchronous standby, endpoint fails over automatically) rather than a cross-Region replica or a snapshot runbook. Learn the disaster-recovery ladder by cost and recovery time: backup and restore is cheapest and slowest, pilot light keeps only the data layer running, warm standby runs a scaled-down live full stack, and multi-site is active-active and fastest. For Lambda cold starts before a known morning surge, choose scheduled provisioned concurrency, not reserved concurrency (which only caps and reserves account concurrency) or warming pings. For a fragile backend behind API Gateway, a per-method throttle override sheds excess load on one method with native throttling responses, separate from account-level limits or a WAF rate rule. Above all, learn that a cross-account AWS Backup copy action puts recovery points in a separately governed account so a production compromise cannot delete them, which Vault Lock or IAM controls inside the production account alone cannot guarantee.
Easy to confuse
Warm standby versus pilot light. Warm standby runs a scaled-down but fully functional copy of the whole stack in the recovery Region that only needs scaling up, giving a low RTO at higher steady cost; pilot light keeps only the core data layer replicated and running while the application tier stays switched off until failover, which is cheaper but slower to recover. Choose by the named RTO against the cost the scenario tolerates.
Cross-account backup copy versus Vault Lock in compliance mode. A cross-account AWS Backup copy action stores recovery points in a separately governed account so a compromise confined to production cannot reach or delete them; Vault Lock in compliance mode stops deletion before retention expires but the recovery points still live inside the production account and share its blast radius. For isolation from a production compromise, copy to a separate account.
Provisioned concurrency versus reserved concurrency. Provisioned concurrency initialises and holds a set number of Lambda execution environments so the first requests skip the cold-start init phase, and it can be scheduled to ramp before a known surge; reserved concurrency only sets aside and caps a share of account concurrency for the function and does nothing to pre-warm environments. For cold starts, provisioned concurrency is the lever.
API Gateway per-method throttle versus account-level throttle. A per-method throttle override caps one specific high-volume method with its own rate and burst and returns throttling responses on just that method; the account-level throttle caps every API in the Region and a WAF rate rule blocks per source address rather than capping a method. To protect one fragile backend method, override that method's throttle.
A security team is concerned that if an attacker compromises the production account, they could delete both the live data and the AWS Backup recovery points stored alongside it. The team wants backups isolated in a separate account so that a compromise of production cannot reach or delete them, while keeping the existing AWS Backup plans running in production. What is the MOST appropriate way to achieve this isolation?
AAdd a copy action to each backup plan rule that copies recovery points to a backup vault in a dedicated, separately governed backup account, so the protected copies reside outside the production account entirely.check_circle Correct
BKeep the recovery points in the production backup vault but apply an IAM permission boundary to every production role so that no production principal is allowed to call the delete recovery point action.
CEnable AWS Backup Vault Lock in compliance mode on the production backup vault so that recovery points cannot be deleted before their retention expires, even by an administrator.
DMove the production backup vault encryption to a customer managed AWS KMS key and remove production roles from the key policy so they can no longer decrypt the stored recovery points.
Use a cross-account AWS Backup copy to a vault in a separate backup account to keep recovery points outside the production blast radius. AWS Backup copy actions can target a backup vault in another account that the organisation governs separately; because the protected copies then live outside the production account, a compromise confined to production cannot delete them, which IAM controls or in-account locks alone cannot guarantee.
Why A is correct: Copying recovery points to a vault in a separate backup account places the protected copies under different governance and outside the production blast radius, so a compromise of production cannot reach or delete the cross-account copies.
Why B is wrong: A permission boundary narrows what production roles can do, but the recovery points still live in the production account, so an attacker with sufficient access or a new role could still reach them, failing the isolation goal.
Why C is wrong: Vault Lock prevents early deletion of recovery points, but the vault is still in the production account, so this addresses tampering rather than the account-level isolation the requirement asks for.
Why D is wrong: Restricting the KMS key controls who can decrypt restores, but the recovery point objects remain in the production account and can still be deleted, so confidentiality is improved while deletion isolation is not.
What you must be able to do. Given an observability requirement, choose the CloudWatch, CloudTrail, X-Ray, Container Insights or cross-account approach that collects the right signal, traces and audits requests, and proves integrity with the least bespoke tooling.
In one sentenceThe observability domain: collect in-guest signals with the CloudWatch agent, trace and sample with X-Ray, prove log integrity with CloudTrail, and get per-task and per-service container metrics from Container Insights without a self-managed collector.
Recall check: answer these from memory first
An EC2 Auto Scaling fleet must alarm on in-guest memory and root-disk usage with the least ongoing maintenance. What collects those signals and where is its config placed, and why does detailed monitoring not help?
A high-traffic API on X-Ray must cap trace volume yet always capture every server-error trace, and tune the rate without redeploying services. What achieves this, and why is an SDK-hardcoded percentage wrong?
An auditor needs cryptographic proof that delivered CloudTrail log files are unaltered and none are missing, without custom hashing. Which CloudTrail feature provides it, and why is bucket encryption insufficient?
What it tests. Instrumenting the workload and proving what happened. Collecting, aggregating and storing logs and metrics with Amazon CloudWatch, the CloudWatch agent, Amazon CloudWatch Logs and metric filters; aggregating telemetry across accounts and tracing requests with CloudWatch cross-account observability, AWS X-Ray, Amazon Data Firehose and log subscription filters; auditing and analysing with Amazon CloudWatch Logs Insights, AWS CloudTrail, Amazon Athena and CloudWatch anomaly detection; automating monitoring and event management with Amazon CloudWatch alarms, composite alarms, Amazon EventBridge and Amazon SNS; and monitoring application and endpoint health with Amazon CloudWatch Synthetics, CloudWatch RUM, Container Insights and Lambda Insights.
How to study it. Make "what signal, what proof" your reflex. Learn that default Amazon CloudWatch EC2 metrics come from the hypervisor and never expose in-guest memory or root-disk usage, so collecting those requires the CloudWatch agent with its configuration baked into the launch template, never detailed monitoring (which only raises frequency) and never Compute Optimizer. For tracing, X-Ray sampling rules with a reservoir plus a fixed rate, and a condition that always samples server-error responses, bound trace volume while never missing errors, and because the rules live in X-Ray they are tuned centrally with no redeploy - unlike an SDK-hardcoded percentage. For audit integrity, CloudTrail log file integrity validation writes signed hourly digest files so the AWS CLI can prove each delivered log file is unchanged and none are missing, which encryption or a bucket DeleteObject deny cannot prove. For containers, enable CloudWatch Container Insights to get rolled-up per-task, per-service and per-cluster CPU, memory and network metrics on ECS with built-in dashboards and no self-managed Prometheus or sidecar to maintain.
Easy to confuse
CloudWatch agent versus detailed monitoring. The CloudWatch agent runs inside the guest and publishes memory, disk and custom metrics the hypervisor cannot see; detailed monitoring only raises the publish frequency of existing hypervisor metrics to one minute and never adds memory or disk. When the scenario needs in-guest signals, the agent is the only answer.
X-Ray sampling rule versus an SDK-hardcoded sampling percentage. A centrally managed X-Ray sampling rule sets a reservoir plus a fixed rate and can match on attributes such as HTTP status to always record errors, and it changes without redeploying instrumented services; a percentage hardcoded in each service's SDK samples errors at the same flat rate and forces a redeploy to retune. Use a sampling rule for central control and guaranteed error capture.
CloudTrail log file integrity validation versus S3 encryption. CloudTrail log file integrity validation writes signed digest files so you can cryptographically verify each delivered log file is unchanged and none are missing; S3 server-side encryption protects confidentiality at rest and proves nothing about tampering, and a DeleteObject deny is an access control, not an integrity proof. For tamper-evidence, enable integrity validation.
Container Insights versus a self-managed Prometheus sidecar. CloudWatch Container Insights automatically rolls up per-container, per-task, per-service and per-cluster CPU, memory and network metrics on ECS with managed dashboards; a Prometheus node-exporter sidecar scraped by a self-run server delivers similar data but adds agents and a server to operate. To attribute resource pressure to a workload with no self-managed collector, enable Container Insights.
Worked example from the DOP-C02 bank
lock_openFree sampleMonitoring and Loggingmedium
An auditor requires assurance that the AWS CloudTrail log files delivered to a central Amazon S3 bucket have not been altered or deleted since CloudTrail wrote them. The team wants a way to prove the integrity of each delivered log file that does not depend on writing custom hashing code or trusting only S3 access controls. Which CloudTrail feature satisfies this integrity requirement?
AEnable Amazon S3 server-side encryption with an AWS KMS key on the bucket so that the encryption proves the CloudTrail log files were not modified after they were delivered to the bucket.
BTurn on CloudTrail log file integrity validation, which writes signed digest files so the team can verify with the AWS CLI that each delivered log file is unchanged and none are missing.check_circle Correct
CApply an Amazon S3 bucket policy that denies the DeleteObject action to all principals, relying on the policy alone to guarantee the integrity of every CloudTrail log file in the bucket.
DSchedule an AWS Lambda function to compute and store an MD5 hash of each new CloudTrail object, then compare the stored hashes during an audit to detect any tampering with the log files.
Enable CloudTrail log file integrity validation to cryptographically prove delivered log files are unaltered and none are missing. CloudTrail log file integrity validation creates a signed digest file each hour that references the log files delivered in that period along with their hashes; the AWS CLI validate-logs command uses the public key to confirm every log file is unchanged and that no expected file is missing, giving cryptographic, native integrity assurance.
Why A is wrong: Server-side encryption protects confidentiality of objects at rest but does not detect or prevent modification or deletion, so it cannot serve as proof that the delivered log files remain unaltered.
Why B is correct: CloudTrail log file integrity validation produces hourly digest files signed with a private key, and the validate-logs command checks the hashes, proving each delivered log file is unmodified and detecting any deletion without custom hashing code.
Why C is wrong: A deny-delete bucket policy is an access control that can be changed by a privileged principal and proves nothing about whether file contents were altered, so it does not provide verifiable integrity assurance.
Why D is wrong: A custom hashing Lambda is exactly the bespoke code the team wants to avoid and uses a weak hash with self-managed storage, whereas CloudTrail already provides a signed, native integrity-validation mechanism.
What you must be able to do. Given an event or failure scenario, choose the EventBridge, CloudWatch Logs subscription, Systems Manager Automation, rollback or CloudTrail approach that responds, remediates or attributes the cause automatically with no operator in the loop and no server to manage.
In one sentenceThe incident-automation domain: match events precisely with EventBridge patterns, drive serverless remediation from a log subscription filter, post to chat with AWS Chatbot, roll back failed deployments natively, and attribute past changes with CloudTrail.
Recall check: answer these from memory first
Every PutBucketPolicy call must trigger a Lambda that evaluates the new policy, with the least custom code and no polling. How is the rule built, and why is a five-minute scheduled scan or an S3 object-created notification wrong?
A specific throttling log pattern must trigger a short, serverless remediation on each occurrence with no fixed-schedule polling and no instance. What design fits, and why is a State Manager association on a timer the wrong choice?
After an S3 bucket was briefly public, you must determine who changed it, when and from which source IP, with a multi-Region CloudTrail trail already running. Which source answers this, and why not VPC Flow Logs?
What it tests. Responding to events and finding causes without a human in the loop. Building event-driven response with Amazon EventBridge rules and event buses, AWS Lambda targets and Amazon SNS and Amazon SQS destinations; processing events and notifying responders with Amazon EventBridge Pipes, Amazon SNS, AWS Chatbot and chat-based operations; implementing automated configuration changes with AWS Systems Manager Automation, AWS Config remediation and AWS Lambda; troubleshooting deployment and pipeline failures with AWS CloudFormation stack rollback, AWS CodeDeploy automatic rollback, deployment alarms and pipeline failure states; and performing root-cause analysis with Amazon CloudWatch, AWS X-Ray, AWS CloudTrail and VPC Flow Logs.
How to study it. Make event-driven and serverless the default for response. To act on one specific API call, an EventBridge rule with an event pattern on the source and eventName fires only for that call and passes the matched CloudTrail event straight to a Lambda target, with no schedule, no scanning and no in-function filtering. To remediate on a matching log line, a CloudWatch Logs subscription filter on the pattern invokes a least-privilege Lambda the moment the line appears, beating a scheduled State Manager association, a poll, or an EC2 tailer. To post CloudWatch alarms to Slack with the least overhead, subscribe AWS Chatbot to the existing SNS topic; it natively formats alarm notifications, so there is no Lambda formatter, raw-JSON webhook or email-to-channel hack to build. For root-cause work, learn the source-of-truth split: CloudTrail attributes who changed a configuration, when and from which source IP via userIdentity, eventTime and sourceIPAddress; VPC Flow Logs only show network connections and never name the principal; S3 access logging is for object access, not configuration changes.
Easy to confuse
EventBridge event pattern versus a scheduled scan. An EventBridge rule with an event pattern matching the source and eventName fires the instant the matching API call is recorded and passes the event straight to the target, with no polling; a scheduled rule that scans CloudTrail every few minutes adds latency, cost and custom scan logic for behaviour the pattern already gives. For a specific API call, match it with a pattern.
CloudWatch Logs subscription filter versus State Manager association. A CloudWatch Logs subscription filter evaluates each log event against a pattern and streams only matches to a Lambda target in real time, so remediation fires the moment the pattern appears; a Systems Manager State Manager association runs on a schedule and would only catch the pattern on its next poll. For log-driven, event-time remediation, use the subscription filter.
AWS Chatbot versus a custom Slack-formatter Lambda. AWS Chatbot subscribes to an existing SNS topic and natively renders CloudWatch alarm notifications as readable Slack messages with nothing to host; a Lambda that transforms each notification into Slack blocks and posts to a webhook is a formatter you must deploy and maintain in every account. Reuse the SNS wiring and point Chatbot at it.
CloudTrail versus VPC Flow Logs for root cause. CloudTrail records management API calls with userIdentity, eventTime and sourceIPAddress, so it attributes a configuration change to a principal, time and origin; VPC Flow Logs record only network traffic at the IP and port level and never name the principal or the API call. To answer who changed a setting, query CloudTrail, not flow logs.
Worked example from the DOP-C02 bank
lock_openFree sampleIncident and Event Responsehard
An Amazon S3 bucket holding production data was made publicly readable for roughly twenty minutes before an engineer reverted it. The security team must determine, after the fact, exactly who or what changed the bucket configuration, when the change was made, and from which source IP address, so they can complete a root-cause report. The account has AWS CloudTrail enabled with a multi-Region trail delivering management events to an S3 bucket, and they have not yet enabled any other diagnostic service. Which approach MOST directly answers who made the change?
AEnable Amazon S3 server access logging on the bucket now and review the delivered access log records to find the principal and source address that altered the bucket configuration during the exposure window.
BRun a CloudWatch Logs Insights query over the application log group for the time window to find the entry that recorded the bucket being made public, then read the user field from that log line.
CQuery the AWS CloudTrail event history or the delivered trail logs for the PutBucketAcl and PutBucketPolicy events on that bucket, reading the userIdentity, eventTime and sourceIPAddress fields to attribute the change.check_circle Correct
DAnalyse VPC Flow Logs for the period to find the source IP that connected to the S3 endpoint, then map that address back to the engineer or service that reconfigured the bucket during the exposure.
Use AWS CloudTrail management events to attribute a configuration change to a principal, time and source IP after the fact. AWS CloudTrail logs management API calls including S3 bucket configuration changes, recording userIdentity, eventTime and sourceIPAddress for each event. Because the trail was already capturing these events, querying CloudTrail is the direct way to attribute a past change to a specific principal, time and origin for a root-cause report.
Why A is wrong: S3 server access logs capture object-level request activity going forward and would not be populated for a change that already happened, nor do they record bucket-configuration API calls with caller identity.
Why B is wrong: Application logs only contain what the application chose to write and would not capture an out-of-band configuration change made through the console or API, so the responsible principal is not recorded there.
Why C is correct: CloudTrail records management API calls such as PutBucketAcl with the userIdentity, eventTime and sourceIPAddress, so querying those events for the bucket attributes the change to a principal, time and origin exactly as required.
Why D is wrong: VPC Flow Logs show network connections by IP but carry no caller identity or API action, so they cannot reveal who altered the bucket policy, only that some traffic to an endpoint occurred.
What you must be able to do. Given an access, secret-management, guardrail, data-protection or compliance-evidence requirement, choose the IAM, Organizations, Secrets Manager, ACM, detection or Audit Manager approach that enforces the control preventively at scale and collects evidence continuously.
In one sentenceThe security-and-compliance domain: enforce preventive guardrails with service control policies, hand out short-lived credentials with OIDC and STS, automate secret and certificate lifecycle, detect threats, and collect control-mapped evidence continuously with Audit Manager.
Recall check: answer these from memory first
Across 300 accounts, no principal in any production account, including an account administrator, may disable or delete CloudTrail, and a per-account IAM deny was bypassed by detaching it. What enforces this durably, and why can an IAM policy or permission boundary not?
A GitHub Actions workflow must deploy to AWS with no stored access keys and only short-lived, scoped credentials. What authenticates it, and why is a stored IAM user key, even rotated, wrong?
An auditor needs SOC 2 evidence mapped to specific controls, collected continuously from AWS services rather than gathered manually at audit time. Which managed service does this, and why not a Config conformance pack alone?
What it tests. Securing and proving the platform at scale. Implementing identity and access at scale with IAM roles, AWS Organizations, service control policies and AWS IAM Identity Center; automating secret and credential management with AWS Secrets Manager rotation, AWS Systems Manager Parameter Store and short-lived role credentials; applying automated guardrails with AWS Config, AWS Control Tower, service control policies, CloudFormation hooks and AWS CloudFormation Guard; automating data protection with AWS Key Management Service, encryption enforcement, Amazon S3 access controls and AWS Certificate Manager; implementing security monitoring and threat detection with Amazon GuardDuty, AWS Security Hub, Amazon Inspector and Amazon Detective; and automating compliance auditing and evidence collection with AWS CloudTrail, AWS Config conformance packs and AWS Audit Manager.
How to study it. Fix the preventive-versus-detective and preventive-versus-cap distinctions, because the hardest security questions turn on them. To guarantee no principal in any account, including an account administrator, can perform an action, the answer is a service control policy on the organisational unit (a preventive ceiling administered only from the management account), not an IAM deny policy that a local team can detach, not a permission boundary on each role, and not a detective Config rule that only repairs after the fact. For pipeline credentials, the supported pattern is an IAM OIDC identity provider with STS role assumption so the workflow gets short-lived, scoped credentials per run and stores no long-lived access keys anywhere. For TLS, ACM managed renewal renews a DNS-validated certificate automatically as long as the validation CNAME stays in the hosted zone, so no scheduled reissue Lambda is needed. Map each detection service to its threat: GuardDuty for behavioural threat detection from account and network logs, Inspector for software vulnerabilities and CVEs, Security Hub for aggregating findings, Detective for investigation. For audit, AWS Audit Manager maps prebuilt framework controls to evidence sources and continuously collects from Config, CloudTrail and others, which a Config conformance pack or Security Hub scores alone do not assemble into a control-mapped report.
Easy to confuse
Service control policy versus IAM permission boundary. A service control policy is set in the AWS Organizations management account and caps the maximum permissions for every principal in the targeted accounts, so even an account administrator cannot exceed or remove it; a permission boundary is attached per IAM principal inside the account and a local administrator can change the principals or boundaries. For a guarantee that survives account-level administrators, use an SCP.
OIDC role assumption versus stored IAM user access keys. An IAM OIDC identity provider lets a pipeline present its signed token to STS and receive short-lived, scoped credentials per run with nothing stored; storing an IAM user's access keys, even encrypted and rotated, keeps long-lived static credentials that can leak. When the requirement bans stored keys and demands short-lived scoped credentials, choose OIDC with STS.
ACM managed renewal versus a scheduled reissue Lambda. ACM managed renewal renews a DNS-validated public certificate and pushes it to integrated services such as an Application Load Balancer automatically, as long as the validation CNAME stays in the hosted zone, with no listener change; an EventBridge-scheduled Lambda that reissues and re-attaches a certificate is custom toil that ACM already performs. Keep the CNAME and let ACM renew.
AWS Audit Manager versus an AWS Config conformance pack. AWS Audit Manager maps prebuilt or custom framework controls to evidence sources and continuously assembles supporting data from Config, CloudTrail, Security Hub and resource APIs into a control-mapped assessment report; a Config conformance pack only evaluates resource configuration against rules and produces compliance status, not a standard-aligned evidence report. For control-mapped audit evidence, use Audit Manager.
Worked example from the DOP-C02 bank
lock_openFree sampleSecurity and Compliancehard
A company manages around 300 accounts in AWS Organizations grouped into organisational units by environment. Security needs a hard guarantee that no principal in any production account, including account administrators with broad IAM policies, can disable AWS CloudTrail or delete its trails. A previous attempt that relied on attaching an IAM deny policy in each account was bypassed when a team detached the policy. The team wants the most durable control that cannot be removed by account-level administrators. Which approach should they implement?
AAttach a permission boundary to every IAM role in the production accounts that omits the CloudTrail stop and delete actions, so the boundary caps what those roles can do regardless of their attached policies.
BDistribute an AWS Config rule to the production accounts that detects when a trail is stopped or deleted and triggers a remediation that recreates it, treating detection and repair as the enforcement mechanism for the requirement.
CMove all production accounts under a dedicated organisational unit and apply an IAM identity-based deny policy through AWS IAM Identity Center permission sets so every assigned user inherits the CloudTrail restriction centrally.
DAttach a service control policy to the production organisational unit that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail, so the guardrail applies to every principal in those accounts and cannot be overridden locally.check_circle Correct
Use a service control policy on an organisational unit to set a preventive permission ceiling that even account administrators cannot override. Service control policies define the maximum permissions available to principals in the member accounts they target and are administered only from the AWS Organizations management account; denying cloudtrail:StopLogging and cloudtrail:DeleteTrail at the organisational unit means no principal in those accounts, including an account administrator, can perform those actions, which is a preventive guarantee that local IAM policies, permission boundaries, or detective controls cannot match.
Why A is wrong: A permission boundary caps a principal's effective permissions, but it is set within the account and an account administrator can change or remove it, so it does not survive a local admin acting against the control the way an organisation guardrail does.
Why B is wrong: Config with remediation detects and repairs after the fact rather than preventing the action, so there is a window where logging is off, and an account admin can disable the rule, which falls short of a hard preventive guarantee.
Why C is wrong: Identity Center permission sets only constrain principals that sign in through Identity Center, so roles, account root, and locally created users are unaffected, which leaves the very administrators the requirement targets able to stop or delete the trails.
Why D is correct: A service control policy sets the maximum available permissions for every principal in the targeted accounts including account administrators, and it is managed only from the organisation management account, so denying the CloudTrail stop and delete actions there is a preventive guardrail that local admins cannot remove.
A study plan that works
Map the blueprint and book a date
Day 1
Read the official AWS exam guide and the six domains with their weights, and be honest about your AWS experience against the recommended two-plus years. Book a provisional date now: a fixed date turns open-ended study into a plan and is the strongest predictor of actually sitting. Note that SDLC Automation is the single largest domain and that Configuration Management and Infrastructure as Code and Security and Compliance are the next heaviest, so plan the deepest study where the marks are.
Build the delivery and IaC decision maps
Week 1
Before drilling any domain, build the decision trees the whole exam rests on: the CodePipeline native-gating rule and the CodeDeploy lifecycle-hook order, the canary-versus-linear and blue/green-versus-in-place splits, and the CloudFormation feature split (stack policy, change set, StackSets, conformance pack, drift detection). Use the recall prompts in this guide: cover the answer, choose the approach from the constraint, then reveal. If you cannot pick from the requirement alone, you do not own it yet.
Go deep on SDLC Automation and IaC (Domains 1 and 2)
Weeks 1 to 3
These two carry the most marks, so they get the most time. Drill cross-account pipelines and the three grants a target role needs with a customer managed KMS key, the deployment strategies matched to a stated downtime and rollback need, and the in-stack guardrails and change-set previews that keep infrastructure changes safe and auditable. Practise on scenario questions and read the worked explanation on every one, including the ones you got right, watching for the named constraint that picks the answer.
Lock resilience and observability (Domains 3 and 4)
Weeks 3 to 4
Drill the disaster-recovery ladder against a named RTO and RPO, RDS Multi-AZ for zonal failover, scheduled provisioned concurrency, per-method throttling, and the cross-account backup copy that escapes the production blast radius. For observability, fix the CloudWatch agent for in-guest signals, X-Ray sampling rules with a reservoir and error condition, CloudTrail log file integrity validation, and Container Insights. Do each easy-to-confuse pair by hand until the constraint alone decides it.
Cover incident response and security (Domains 5 and 6)
Week 4
Drill event-driven and serverless remediation: EventBridge patterns for a specific API call, CloudWatch Logs subscription filters for log-driven fixes, AWS Chatbot over SNS, and CloudTrail versus VPC Flow Logs for root cause. On security, lock the SCP preventive ceiling, OIDC with STS for keyless pipelines, ACM managed renewal, the detection-service map, and AWS Audit Manager for continuous control-mapped evidence. Tie every choice back to the constraint named.
Drill weak domains, then space the review
Week 5
Use your per-domain accuracy to attack the two domains dragging you down, not to re-read what you already know. Then space it: revisit each domain's recall prompts after a few days and again a week later. Spacing roughly doubles what sticks compared with cramming, and it is the cheapest gain available before a professional-level exam where the scenarios are long and the trade-offs are sharp.
Sit a timed mock and calibrate
Weeks 5 to 6
Take at least one full timed mock under exam conditions to rehearse pacing across the long professional scenarios and the flag-and-return habit in the time allowed. Treat the score as a per-domain readiness signal, not a single number, and review every missed question, naming the constraint you misread, before you book or sit.
Know when you're ready
Readiness for the AWS Certified DevOps Engineer - Professional is a score on layered scenario questions you have not seen before, not a feeling that the services are familiar. Those are different things, and the gap between them is where people fail at professional level, where the scenarios are long and several services are in play at once. Re-reading the docs builds fluency, and fluency feels like knowledge, so confidence rises while real recall does not. The fix is to test yourself: if you can read a fresh scenario, name the delivery, resilience, observability, incident or governance constraint, and pick the AWS-native approach while explaining why each other option is wrong, you know it; if you can only nod along to an explanation, you do not yet.
Be especially wary of early confidence on the service map. Knowing what CodePipeline, CloudFormation, CloudWatch, EventBridge and Organizations each do is the easy half; choosing between them under a zero-downtime, recovery-objective, blast-radius or preventive-guardrail constraint, when two of them would work, is the half the exam actually tests. Trust your measured per-domain accuracy over your gut, and set the bar at clearing every domain comfortably on unseen questions across more than one session, not scraping a single pass on the marked pass score.
This guide gives you the map. The practice bank is where you find out whether you can navigate it, with a worked explanation and a reason every distractor is wrong on every question. Readiness scoring tells you when you are there. Not before.
Ready to put this into practice?
Free DOP-C02 questions with worked explanations. No sign-up.
Read the long scenario for its real constraint first. The zero-downtime, recovery-objective, blast-radius, auditability or automation limit named in the question is what picks the answer, so find it before you judge the options.
When two services both work, default to the managed, automated, AWS-native, least-overhead one. Reach for a custom Lambda, a polling job or a self-hosted component only when the scenario names a reason the managed path cannot meet.
For remediation or response that needs no human, choose the event-driven serverless chain. An EventBridge rule, a CloudWatch Logs subscription filter or an alarm invoking a Systems Manager runbook or Lambda beats an SNS email or a scheduled scan whenever the requirement is to act automatically.
Match the deployment strategy to the stated downtime and rollback need. Blue/green for zero downtime and instant rollback, canary for a held slice then a single shift, linear for equal timed increments, and let a failing build action gate the pipeline natively.
Treat broad permissions and stored long-lived keys as wrong answers. A wildcard policy, a public bucket, or an embedded access key is the trap; a scoped IAM role, OIDC with STS, and an SCP preventive ceiling almost always win the security questions.
Match the disaster-recovery tier and backup design to the named RTO, RPO and threat. A low RTO points to warm standby or multi-site, a few-minute RPO needs continuous or point-in-time recovery, and isolation from a production compromise needs a cross-account backup copy.
Flag and move on. Cover every long question once before you sink time into a hard one; collecting the clear marks first protects the ones you actually know within the 180 minutes.
Frequently asked questions
How is the DOP-C02 different from an associate-level AWS exam?
It is a professional exam, so the scenarios are longer, layer several services together, and the trade-offs are sharper. Where an associate question asks which service does a job, a professional question gives you a delivery, resilience, observability, incident or governance situation with a named constraint and asks for the best of several workable options. The skill under test is engineering judgement under that constraint, not service recall.
Do I need to take the associate exams first?
No, there is no prerequisite certification. In practice the candidates who pass have real AWS delivery experience, roughly two or more years provisioning and operating environments, and are comfortable scripting build and automation logic in at least one language. The exam assumes you have built pipelines and infrastructure as code, not just read about them.
Which domains carry the most marks?
SDLC Automation is the single largest domain, with Configuration Management and Infrastructure as Code and Security and Compliance the next heaviest, then Resilient Cloud Solutions and Monitoring and Logging, and Incident and Event Response close behind. Plan the deepest study on delivery pipelines, infrastructure as code and security, but every domain is dependable marks if you drill it as decision trees.
How should I think about automated remediation and response questions?
When a scenario says a problem must be handled with no operator awake, the answer is an event-driven serverless chain: an EventBridge rule matching a specific event, a CloudWatch Logs subscription filter on a pattern, or a CloudWatch alarm, invoking a Systems Manager Automation runbook or an AWS Lambda function. An option that only sends an SNS notification, polls on a schedule, or runs an EC2 tailer is the trap when the requirement is automatic action with no server to manage.
What is the difference between canary and linear deployments in CodeDeploy?
A canary configuration routes one fixed slice of traffic to the new version, holds there for a named interval while alarms are watched, then shifts the entire remainder in a single step. A linear configuration adds equal increments of traffic on a fixed timer until the shift completes. Read the wording: one hold-then-jump is canary, repeated equal steps is linear.
How do I tell when to use a service control policy versus an IAM policy?
A service control policy is set in the AWS Organizations management account and caps the maximum permissions for every principal in the targeted accounts, so even an account administrator cannot exceed it or remove it locally. An IAM policy grants permissions to a principal within those limits and a local team can change or detach it. When the requirement is a guarantee that holds against account administrators, an SCP on the organisational unit is the preventive control, not an IAM deny.
How many practice questions should I do before booking?
Enough that every domain clears comfortably on questions you have not seen, and a full timed mock feels comfortable on pacing across the long professional scenarios. Quality of review beats raw volume: on every question, read the worked explanation and name the constraint that picked the answer, including on the ones you got right, so you are practising the judgement the exam tests rather than memorising answers.
Is the AWS DevOps Engineer Professional worth it?
It is the natural capstone for engineers who already build and operate delivery pipelines on AWS and want a credential that distinguishes them from associate-level practitioners. The preparation itself is valuable because it forces you to reason precisely about automation, resilience, and governance trade-offs rather than just knowing which services exist. A common next step for those who want to broaden is the AWS Solutions Architect Professional, or deepening into specific areas such as the AWS Security Specialty.
Examworthy is not affiliated with or endorsed by Amazon Web Services. This guide is original study material based on the public exam blueprint. We never reproduce live exam items. DOP-C02 and related marks belong to their respective owners.
