AWS Certified DevOps Engineer – Professional (DOP-C02): Practical Exam Guide
The AWS Certified DevOps Engineer – Professional exam validates technical expertise in provisioning, operating, and managing distributed systems and services on AWS, with emphasis on continuous delivery, automation, resilience, monitoring, incident response, and security. It is intended for people performing a DevOps engineer role, especially candidates with substantial AWS operating experience. This guide helps you decide whether your current work matches the exam, which domains need deliberate practice, how to sequence study, and whether you are ready to schedule DOP-C02.
What DOP-C02 validates
DOP-C02 tests whether you can design, automate, operate, and troubleshoot AWS environments rather than merely recall isolated service definitions. The official scope connects delivery pipelines with infrastructure as code, resilient operations, observability, incident handling, and security or compliance automation.
AWS describes the exam as validating technical expertise in provisioning, operating, and managing distributed systems and services on AWS. It also covers implementing and managing continuous-delivery systems and methodologies, automating security controls and governance processes, defining monitoring, metrics, and logging systems, implementing highly available and self-healing systems, and designing tools that automate operational processes.
That combination changes how you should study. A candidate who knows the console screens for a service but cannot explain how it behaves inside a deployment, recovery, or governance workflow is not covering the exam’s practical intent. Study each service in the context of a system: what triggers it, which identity accesses it, what state it changes, how failure is detected, and how an operator verifies the result.
Who should consider this exam
This certification is a better fit for an experienced AWS operator who owns delivery and operational outcomes than for someone who has only completed introductory cloud exercises. AWS identifies a target candidate with 2 or more years of experience provisioning, operating, and managing AWS environments, plus software-development-lifecycle and programming or scripting experience.
The recommended background includes highly automated infrastructure, operating-system administration, and modern development and operations processes. AWS also recommends experience securing AWS infrastructure. These are recommendations, not a statement that every candidate must document a particular job title or prerequisite before scheduling.
Use the background description as a readiness test. Can you follow a failed release from source through build, artifact storage, deployment, health checks, and rollback? Can you change infrastructure safely across accounts or Regions? Can you investigate logs and metrics, identify an operational signal, and automate a response? If several answers are no, build hands-on capability before treating practice-question performance as evidence of readiness.
The official scope also names some work as out of scope for the target candidate. It does not expect advanced networking knowledge such as advanced routing algorithms or failover techniques, deep-level security recommendations to developers, database design and performance optimization, or full-stack application development. This does not eliminate networking, security, databases, or application behavior from scenarios; it helps you avoid turning the preparation plan into a specialist certification in one adjacent subject.
Exam format and scheduling facts
The exam is 180 minutes long and contains 75 multiple-choice or multiple-response questions. AWS states that 65 questions affect your score and that 10 questions are unscored; the unscored questions are not identified. The practical scheduling decision is therefore to confirm the current official appointment details before paying, then prepare to reason through the complete question set.
The official exam name is AWS Certified DevOps Engineer – Professional, and the exam code is DOP-C02. AWS lists English, Japanese, Korean, and Simplified Chinese as exam languages. The listed exam price is 300 USD, subject to AWS’s additional pricing information and foreign-exchange terms, so verify the amount and applicable policy at checkout rather than relying on an old study page.
AWS offers the exam at Pearson VUE testing centers or through online proctoring. Choose the delivery route you can support reliably. For online proctoring, review the current provider requirements and appointment rules in advance. For a testing center, check location availability and arrival requirements before selecting a date. Those logistical checks are official-process decisions; choosing a quiet study block, testing your equipment early, and reserving buffer time are practical recommendations.
AWS reports results as a scaled score of 100–1,000, and the minimum passing score is 750. Do not interpret that as a simple percentage of correct answers. AWS also cautions candidates when interpreting section-level feedback, so use domain feedback to select remedial study rather than treating it as a precise measure of competence in every service.
How the exam content is organized
DOP-C02 is organized into six content domains: SDLC Automation; Configuration Management and Infrastructure as Code; Resilient Cloud Solutions; Monitoring and Logging; Incident and Event Response; and Security and Compliance. The supplied official research does not provide domain percentages, so this guide does not assign weights or compare unlabeled percentages.
The absence of a percentage in the supplied evidence is itself a useful planning constraint. Do not assume that the services you use most at work represent the whole exam. Start with the official task statements, map each one to your experience, and give extra study time to tasks where you cannot explain both the design choice and the operational failure mode.
The domains overlap deliberately. A secure artifact repository belongs to delivery, but its permissions and encryption affect security. A CloudWatch alarm may reveal a resilient-system failure, trigger an incident workflow, or initiate automated remediation. Build cross-domain study cases instead of six isolated vocabulary lists.
Domain 1: SDLC Automation
SDLC Automation covers implementing CI/CD pipelines, integrating automated testing, building and managing artifacts, and implementing deployment strategies for instance, container, and serverless environments. The official task statements make the domain broader than pipeline creation: they include repositories, secrets, testing stages, artifact lifecycle, permissions, deployment agents, troubleshooting, and deployment methods.
Study a complete promotion path. Trace source control into a build, test execution, artifact repository, approval or policy gate, and deployment target. Then vary the target between Amazon EC2, containers, and Lambda. Compare mutable and immutable deployment patterns, and explain when blue/green or canary deployment changes risk, traffic handling, rollback, and observability.
Practice diagnosing an unsuccessful release by asking focused questions: Did the build produce the expected artifact? Can the deployment role read it? Is the agent or target environment configured? Did the application health check fail after traffic moved? Is the rollback path valid? This sequence is more useful than memorizing a service-to-service diagram.
Domain 2: Configuration Management and IaC
Configuration Management and Infrastructure as Code covers reusable infrastructure components, automated account onboarding and security in multi-account or multi-Region environments, and automated solutions for complex tasks and large-scale environments. The official tasks include CloudFormation, AWS SAM, AWS CDK, StackSets, Organizations, Control Tower, IAM, Config, Systems Manager, Lambda, and Step Functions as examples of relevant capabilities.
Study infrastructure as a lifecycle. Know how a reusable template or construct expresses desired state, how change is reviewed and deployed, how configuration is applied after provisioning, and how drift, noncompliance, or failed updates are detected. Compare the responsibilities of CloudFormation, configuration-management services, and operational automation rather than treating them as interchangeable.
Then model an organization with multiple accounts or Regions. Decide where account creation, baseline controls, delegated administration, role assumption, service control policies, configuration rules, and security findings belong. The objective is not to memorize one landing-zone design; it is to justify a repeatable, secure, and maintainable automation pattern at scale.
Domain 3: Resilient Cloud Solutions
Resilient Cloud Solutions requires you to think about availability, scalability, recovery, and self-healing as properties of an operating system rather than as isolated infrastructure features. AWS states that the exam covers implementing systems that are highly available, scalable, and self-healing on AWS.
For this domain, study failure paths. Identify what happens when an instance, target, deployment, dependency, or Region becomes unhealthy; which signal detects the problem; what automation responds; and how the service returns to a safe state. Include capacity changes and recovery validation in your notes, not just initial architecture.
A useful exercise is to compare two designs with the same application but different health checks, scaling signals, deployment methods, and rollback behavior. Explain the trade-off between rapid recovery and false positives, and distinguish an architecture that survives a failure from one that only sends an alert about it.
Domain 4: Monitoring and Logging
Monitoring and Logging covers collecting, aggregating, and storing logs and metrics; auditing and analyzing them to detect issues; and automating monitoring and event management in complex environments. The official task statements specifically include CloudWatch metrics and logs, metric filters, metric streams, retention, Logs Insights, X-Ray, EventBridge, autoscaling, health checks, Config remediation, and agents.
Build an observability flow from producer to decision. Decide where application and infrastructure data is collected, how it is encrypted and retained, how logs are searched or transformed, which metric or pattern becomes an alarm, and what notification or automated action follows. Include IAM permissions for collection and access, because an otherwise correct design can fail when an agent or service cannot write or read its telemetry.
Practice selecting signals rather than listing them. For example, distinguish a metric that indicates resource pressure from one that indicates user-visible failure. Use the official examples as study prompts: EC2 CPU utilization, queue length, ALB 5xx errors, CloudWatch anomaly detection, CloudTrail events, and AWS Config rules. Then connect the signal to a dashboard, alarm, event pattern, notification, or remediation action.
Also learn the boundaries between tools. CloudWatch Logs Insights supports log analysis; Amazon Athena can analyze data stored for that purpose; X-Ray helps trace supported distributed requests; EventBridge routes matching events; and Systems Manager or Lambda can participate in remediation. The exam may ask for the best end-to-end arrangement, not the definition of one product.
Domain 5: Incident and Event Response
Incident and Event Response is the operational decision layer: detect an event, determine its impact, contain or recover safely, and use automation where a repeatable response is appropriate. The six-domain structure confirms this area is separate from monitoring, so preparing only dashboards and alarms leaves a gap.
Create incident runbooks from observable symptoms. For each scenario, record the first signal, the evidence to collect, the permissions required, the safest containment step, the rollback or recovery action, and the validation condition. Include deployment failures, configuration drift, unhealthy targets, capacity problems, and security-related events without assuming that every alert should trigger an immediate destructive action.
When reviewing a proposed response, ask whether it is idempotent, auditable, reversible, and scoped to the affected resources. Event-driven automation can reduce response time, but an overly broad rule or role can multiply damage. Your study answer should account for event matching, least-privilege access, failure handling, and how an operator confirms that the response worked.
Domain 6: Security and Compliance
Security and Compliance focuses on automating security controls, governance processes, and compliance validation. Treat it as an engineering concern woven through delivery and operations: identities, secrets, encryption, account controls, policy enforcement, evidence, and remediation should be designed into the workflow rather than added after deployment.
Review the security decisions in every lab. Identify the principal making each API call, the resource policy or role it needs, where secrets are stored, how artifacts and telemetry are protected, and how a control is verified. In multi-account exercises, include organization-level guardrails, role assumption, configuration evaluation, findings, and remediation boundaries.
Do not turn this domain into a collection of security-service names. Practice choosing between preventive and detective controls, central and workload-level controls, and automatic remediation versus human review. A strong answer explains how the control is deployed consistently, how exceptions are handled, and what evidence demonstrates compliance.
A preparation method that matches the exam
Use a build-and-investigate cycle: read the task statement, implement a small workflow, break one part of it, observe the evidence, repair it, and document the design decision. This method develops the applied judgment the domains require and exposes permission, state, rollback, and observability gaps that passive reading often hides.
Begin with the official exam guide and the domain task pages. Convert each task statement into a checklist with three columns: “can explain,” “can implement,” and “can troubleshoot.” Mark a task as ready only when you can do more than define its services. The official pages provide additional context for task statements, so use that context to refine the checklist rather than inventing a narrower syllabus.
Use a single evolving reference architecture for study. It can contain a source repository, CI/CD pipeline, test stages, artifact storage, infrastructure templates, several deployment targets, centralized logs and metrics, alarms, event routing, account boundaries, and compliance controls. Each week, change one design constraint: multiple accounts, multiple Regions, a failed deployment, a noisy alarm, a compromised credential, or a capacity spike.
Keep an error log. For each missed practice item, record the requirement, the option you selected, the reason it was attractive, the decisive clue, and the AWS mechanism that resolves the problem. Revisit patterns in your errors: confusing collection with analysis, choosing an application fix for an IAM problem, ignoring rollback, or selecting a manual step when the scenario asks for automation.
A practical study roadmap
A staged roadmap is more effective than moving randomly through service documentation. Establish the baseline first, build integrated workflows next, then spend the final stage on diagnosis and decision speed. Adjust the length of each stage to your existing experience; the sequence is a recommendation, not an AWS requirement.
Stage one is scope mapping. Read the official overview and all six domain names, then examine the supplied task pages for SDLC Automation, Configuration Management and IaC, and Monitoring and Logging. Inventory your experience with pipelines, testing, artifacts, deployment targets, templates, account automation, logs, metrics, events, incident response, and security controls. Schedule nothing until the gaps are visible.
Stage two is delivery and infrastructure. Build a pipeline that produces a controlled artifact, runs more than one kind of automated test, and deploys to an AWS target. Recreate the infrastructure with reusable templates or constructs. Add a secret-management decision, a least-privilege deployment role, and a rollback or replacement path. Troubleshoot deliberately by changing permissions, configuration, or health conditions one at a time.
Stage three is scale and operations. Extend the design across accounts or Regions conceptually or in a safe laboratory environment. Add centralized telemetry, retention, encryption, dashboards, alarms, event routing, health checks, and a remediation action. Test what happens when a deployment fails, a target becomes unhealthy, telemetry is missing, or an automated action lacks permission.
Stage four is scenario rehearsal. Work through mixed cases without looking up the answer immediately. For each case, identify the requirement, constraints, current failure signal, desired operational outcome, and least-complex AWS pattern that meets them. Explain why the alternatives fail. This is where you learn to separate a technically possible choice from the best choice for the stated conditions.
Stage five is readiness review. Recheck every task statement, repeat the labs that exposed weak reasoning, and use timed practice only after you understand the underlying services. Review unanswered items as well as wrong items: AWS states that unanswered questions are scored as incorrect and that there is no penalty for guessing. Develop a controlled process for marking, returning to, and completing difficult items.
How to reason through multiple-choice questions
Start with the requested outcome and constraints, not the service names in the options. Identify whether the question is asking for prevention, deployment, detection, diagnosis, recovery, governance, or evidence. Then eliminate choices that require an unsupported manual step, violate least privilege, ignore scale, or solve a different layer of the problem.
For a pipeline question, trace source, build, test, artifact, approval, deployment, health validation, and rollback. For an infrastructure question, trace desired state, account or Region scope, change management, drift, and remediation. For an observability question, trace collection, storage, analysis, alarm, event, and action. For an incident question, trace detection, containment, recovery, and verification.
Multiple-choice questions have one correct response and three incorrect responses. Multiple-response questions have two or more correct responses out of five or more options, and AWS instructs candidates to select one or more responses that best complete the statement or answer the question. Read every option carefully; an option can contain a familiar service while still failing the scenario’s security, scale, or operational requirement.
Do not infer correctness from a single keyword. “Automated” does not automatically mean Lambda, “centralized” does not automatically mean one account, and “highly available” does not automatically mean adding replicas. Match the mechanism to the trigger, scope, state, permissions, and success condition described in the question.
Hands-on exercises worth prioritizing
Prioritize exercises that force several domains to interact. The strongest lab is not the largest architecture; it is a small system in which you can observe a change, explain the control path, induce a failure, and restore service without guessing.
For delivery, create a pipeline with source integration, a build, automated unit or integration testing, an artifact repository, and a deployment to an instance, container, or serverless target. Record how secrets are supplied, how the deployment identity accesses artifacts, how health is measured, and how a failed release is stopped or reversed.
For infrastructure automation, express a baseline with reusable infrastructure code and apply it to more than one environment. Add account or Region considerations, configuration validation, patch or inventory automation, and a controlled change process. Inspect what happens when a template update fails or the deployed state differs from the declared state.
For observability, send logs and custom or service metrics to the appropriate destinations, create a metric filter or alarm, search the data, and route an event to a notification or controlled remediation. Test missing permissions and delayed telemetry. The point is to understand the complete signal path, including encryption, retention, and access.
For resilience and incident response, remove a target or make a dependency unhealthy in a non-production environment. Observe the health check, alarm, scaling or recovery action, and operator evidence. Write down what would distinguish a successful automated recovery from a loop that repeatedly masks the underlying fault.
For security and compliance, apply a baseline policy, evaluate it, generate a finding, and document a remediation path. Review every role and resource policy used by the exercise. If the lab is too expensive or risky to run, diagram the workflow and validate each service interaction against official documentation rather than improvising a claim about behavior.
Common preparation mistakes
The most damaging mistake is studying service names without studying operational sequences. DOP-C02 spans delivery, infrastructure, resilience, monitoring, incidents, and security, so isolated flashcards can leave you unable to choose between plausible architectures.
Avoid relying on memorized answer keys, leaked material, or exam dumps. They cannot establish that you can build or troubleshoot the systems in the blueprint, and memorization does not guarantee a passing result. Use legitimate practice to expose reasoning gaps, then verify the underlying behavior in official AWS documentation or a controlled lab.
Do not allocate study time solely by personal familiarity. A pipeline engineer may underprepare incident response and compliance; an operations engineer may know monitoring but lack artifact or deployment-depth practice. Use task statements and your error log to balance the plan.
Do not ignore permissions and lifecycle details. Many scenarios turn on who can assume a role, read an artifact, publish logs, invoke an automation, or remediate a finding. Storage retention, encryption, deployment health, rollback, and drift also determine whether a design is operationally complete.
Do not over-study out-of-scope specialties at the expense of the tested role. You need enough surrounding knowledge to evaluate DevOps designs, but the official target description does not require advanced routing algorithms, database performance optimization, or full-stack application development.
Finally, do not treat a strong score on one practice set as a scheduling decision by itself. Recheck all task statements, explain missed answers without notes, and complete at least one mixed review under the available exam time. Readiness is stronger when it is repeatable across unfamiliar scenarios.
When to schedule and what to verify
Schedule when you can explain and troubleshoot the major task statements, not simply when you have finished a video course. Before booking, confirm the current exam page for price, languages, delivery choices, appointment availability, and any provider requirements; these details can change independently of your study notes.
Use the official guide as the authority for scope and the AWS certification page as the authority for current booking information. Confirm that the appointment identifies DOP-C02, the AWS Certified DevOps Engineer – Professional exam. Select Pearson VUE testing-center delivery or online proctoring based on your practical setup, then complete the provider’s current checks before the appointment.
Plan the final review around decisions you repeatedly miss. Revisit pipeline testing and artifact permissions, IaC lifecycle and multi-account controls, health and recovery behavior, telemetry paths, incident automation, and compliance evidence. Avoid starting a broad new service catalogue immediately before the exam; consolidate the relationships you can already apply.
On the exam, unanswered questions are scored as incorrect and AWS states there is no penalty for guessing. A practical approach is to eliminate clearly unsuitable options, select the best supported response, and return only when doing so is likely to improve the decision. Keep enough time to complete every item and review flagged multiple-response questions.
What happens after certification
AWS certifications are valid for three years from the date earned, after which the credential must be recertified to remain current and active. Treat recertification as a future maintenance decision and check the current AWS recertification policy for the available path and conditions rather than assuming the process remains unchanged.
Keep the study artifacts that have continuing operational value: deployment diagrams, runbooks, IAM decision records, observability maps, failure tests, and IaC review checklists. They turn exam preparation into a reusable engineering reference and make it easier to identify which skills need refreshing later.
After the exam, use the result carefully. AWS cautions candidates when interpreting section-level feedback. Treat weaker areas as prompts for targeted practice, not as a precise inventory of everything you do or do not know. Continue validating changes against current AWS documentation because service behavior and recommended patterns can evolve.
A final readiness checklist
You are closer to a sensible scheduling decision when you can connect the requested business or operational outcome to an AWS design, identify the control points, and explain how the system proves success. Use the checklist below as a final gap review rather than a substitute for the official exam guide.
Confirm that you can explain and troubleshoot CI/CD pipelines, automated testing, artifact creation and protection, and deployment strategies for EC2, containers, and serverless environments. Confirm that you can reason about mutable versus immutable delivery, blue/green or canary methods, health checks, and rollback.
Confirm that you can define reusable IaC, manage lifecycle changes, apply controls across accounts or Regions, automate account onboarding, use IAM organization patterns, and automate inventory, patching, configuration, or compliance tasks. Be able to distinguish provisioning from configuration management and event-driven operational automation.
Confirm that you can design log and metric collection, aggregation, storage, encryption, retention, analysis, dashboards, alarms, tracing, event patterns, autoscaling, health checks, and remediation. Then connect those capabilities to incident response: detection, evidence, containment, recovery, validation, and auditability.
Confirm that security and compliance decisions appear in your delivery and operations designs. You should be able to identify identities, permissions, secrets, encryption, governance controls, findings, exceptions, and remediation. Finally, complete mixed practice without leaving questions unanswered and verify all current scheduling details through the official AWS pages.
Conclusion
DOP-C02 is best approached as an applied operations exam. Build a small but integrated AWS delivery system, express its infrastructure as code, instrument it, secure it, break it safely, and document how automation restores or contains the problem. Map that work to all six official domains, use task statements to expose gaps, and verify current booking information before scheduling. That preparation gives you a more reliable basis for the decision than memorizing isolated service facts or relying on unauthorized question material.
