AWS • DOP-C02

AWS Certified DevOps Engineer - Professional (DOP-C02) Practice Test

Validates technical expertise in provisioning, operating, and managing distributed systems and services on AWS, including CI/CD, security controls, monitoring, and highly available systems.

Exam Details

Questions

436

Duration

180 minutes

Passing Score

750/1000

Difficulty

Professional

Last Updated

Jan 2025

Topics Covered

SDLC AutomationConfiguration Management and IaCResilient Cloud SolutionsMonitoring and LoggingIncident and Event ResponseSecurity and Compliance

Exam Domain Breakdown

SDLC Automation22%

Configuration Management and Infrastructure as Code17%

Security and Compliance17%

Resilient Cloud Solutions15%

Monitoring and Logging15%

Incident and Event Response14%

Exam Overview

The AWS Certified DevOps Engineer – Professional (DOP-C02) is a professional-level credential that validates deep technical expertise in provisioning, operating, and managing distributed systems and services on AWS. It covers the full spectrum of DevOps practices on the AWS platform, including the design and implementation of continuous integration and continuous delivery (CI/CD) pipelines, infrastructure automation using tools like AWS CloudFormation and AWS CDK, and the enforcement of security controls and compliance frameworks across cloud environments. The exam also tests proficiency in building self-healing, highly available, and scalable architectures using AWS-native services such as Auto Scaling, Elastic Load Balancing, and AWS Fault Injection Simulator.

First launched as DOP-C01 and updated to DOP-C02, the current version reflects modern DevOps practices with increased emphasis on resilience engineering, observability, and automated security governance. Candidates must demonstrate competency across six weighted domains: SDLC Automation (22%), Configuration Management and IaC (17%), Security and Compliance (17%), Resilient Cloud Solutions (15%), Monitoring and Logging (15%), and Incident and Event Response (14%). This breadth makes it one of the most comprehensive AWS professional certifications available.

Official exam page

Who Should Take This Exam

This certification is designed for experienced cloud practitioners who actively perform DevOps engineering functions in AWS environments. Ideal candidates include DevOps engineers, cloud platform engineers, site reliability engineers (SREs), and cloud infrastructure architects with at least two years of hands-on experience provisioning, operating, and managing AWS-based systems. Professionals who work on CI/CD pipeline design, infrastructure-as-code authoring, monitoring strategy, and cloud security automation will find the exam objectives directly aligned with their daily responsibilities.

The exam is also well-suited for software developers transitioning into platform or operations roles who have substantial AWS experience and scripting or programming skills. Candidates pursuing senior or lead DevOps positions—particularly in organizations that require formal AWS credentials for cloud infrastructure roles—will find this certification significantly strengthens their professional profile.

Prerequisites

AWS does not enforce formal prerequisites, but strongly recommends that candidates have a minimum of two years of experience provisioning, operating, and managing AWS environments before attempting the exam. A working knowledge of software development lifecycle (SDLC) methodologies, modern development and operations practices, and at least one scripting or programming language (such as Python, Bash, or PowerShell) is expected. Familiarity with Linux/Unix and Windows system administration is also recommended.

While not required, holding an AWS Certified Developer – Associate or AWS Certified SysOps Administrator – Associate credential is a practical stepping stone, as those exams cover foundational AWS services that appear throughout the DOP-C02 domains. Candidates should have hands-on experience with AWS services including CodePipeline, CodeBuild, CodeDeploy, CloudFormation, Systems Manager, CloudWatch, AWS Config, and IAM before sitting for this exam.

Exam Format

The DOP-C02 exam consists of 75 total questions: 65 scored questions that affect the final result and 10 unscored pretest questions that AWS uses for future exam development and are not identified during the exam. Questions are presented in two formats—multiple choice (one correct answer from four options) and multiple response (two or more correct answers from five or more options). The exam is administered over 180 minutes.

Scoring uses a compensatory model on a scale of 100–1,000, with a minimum passing score of 750. This means candidates do not need to achieve a passing threshold in each individual domain; overall performance determines the outcome. Unanswered questions are scored as incorrect, so guessing carries no additional penalty. The exam is delivered through Pearson VUE, either at an authorized testing center or via online proctoring, and is available in English, Japanese, Korean, and Simplified Chinese. The exam fee is $300 USD. AWS certifications remain valid for three years.

Skills Measured

1.Domain 1 – SDLC Automation (22%): Designing and implementing CI/CD pipelines using AWS CodePipeline, CodeBuild, CodeDeploy, and CodeCommit; automating software testing and release strategies including blue/green, canary, and rolling deployments; and integrating source control workflows with deployment automation.
2.Domain 2 – Configuration Management and Infrastructure as Code (17%): Authoring and managing AWS CloudFormation templates and stacks, using AWS CDK for infrastructure definition, applying AWS Systems Manager for fleet configuration and patch management, and implementing Elastic Beanstalk and OpsWorks for application environment management.
3.Domain 3 – Security and Compliance (17%): Implementing identity and access management policies, automating compliance validation using AWS Config rules and conformance packs, managing secrets with AWS Secrets Manager and Parameter Store, and enforcing governance controls using Service Control Policies (SCPs) and AWS Organizations.
4.Domain 4 – Resilient Cloud Solutions (15%): Designing fault-tolerant and highly available architectures using Auto Scaling, Elastic Load Balancing, and Route 53 failover routing; implementing disaster recovery strategies; and using AWS Fault Injection Simulator to validate system resilience.
5.Domain 5 – Monitoring and Logging (15%): Configuring Amazon CloudWatch metrics, alarms, dashboards, and Logs Insights; implementing AWS X-Ray for distributed tracing; centralizing log management with CloudWatch Logs and Amazon OpenSearch Service; and setting up alerting and automated remediation workflows.
6.Domain 6 – Incident and Event Response (14%): Building event-driven automation using Amazon EventBridge, AWS Lambda, and SNS; implementing runbook automation with Systems Manager Automation; designing processes for detecting, responding to, and recovering from operational incidents on AWS.

Study Tips

Start with the official AWS Exam Guide for DOP-C02 (available on the AWS Certification page) to map each domain's task statements to specific AWS services, then prioritize hands-on practice with services you have the least experience with.
Use AWS Skill Builder's official Exam Prep Standard or Enhanced course for DOP-C02, which includes practice question sets aligned to the actual exam domains and structured video content from AWS subject matter experts.
Build and tear down CI/CD pipelines from scratch using CodePipeline, CodeBuild, and CodeDeploy in a personal AWS account—understanding how these services integrate end-to-end is heavily tested and cannot be learned purely from reading.
Practice writing CloudFormation templates that include nested stacks, cross-stack references, and custom resources. The Configuration Management and IaC domain (17%) requires deep familiarity with CloudFormation behaviors including rollback triggers and stack policies.
Take the AWS Certification Official Practice Exam (available on AWS Skill Builder) after completing your study to simulate real exam conditions, identify weak domains, and calibrate your time management for 75 questions in 180 minutes.
Review AWS whitepapers on DevOps practices, specifically 'Practicing Continuous Integration and Continuous Delivery on AWS' and 'Running Containerized Microservices on AWS,' as exam scenarios frequently draw from these architectural patterns.
Focus on scenario-based elimination techniques: DOP-C02 questions often present plausible-sounding distractors that include services not suited for the described scale, compliance requirement, or operational constraint. Practice identifying the single best answer rather than a correct-but-suboptimal one.

Career Benefits

The AWS Certified DevOps Engineer – Professional ranks among the top 20 highest-paying IT certifications in North America according to Skillsoft's IT Skills and Salary Report, reflecting strong market demand for professionals who can automate, secure, and operate cloud infrastructure at scale. In the United States, AWS DevOps engineers earn average salaries of approximately $135,000–$145,000 annually, with experienced professionals at senior levels reporting compensation above $150,000. Many organizations in finance, healthcare, retail, and technology explicitly list this certification as a preferred or required qualification for senior DevOps, cloud platform, and SRE roles.

Holding the DOP-C02 credential positions professionals for roles including Senior DevOps Engineer, Cloud Platform Engineer, Site Reliability Engineer, Release Engineering Lead, and Cloud Infrastructure Architect. Compared to associate-level AWS certifications, the professional designation signals the ability to architect complete DevOps systems—not just operate within them—which meaningfully expands role eligibility and negotiating leverage. Demand for certified DevOps engineers on AWS is projected to grow substantially as organizations accelerate cloud adoption and prioritize automated governance and security practices.

Sample Questions

Preview — answers shown

5 sample questions with correct answers and explanations. Start a practice session to test yourself across all 436 questions.

1. A logistics company runs a custom Web Application Firewall (WAF) on a fleet of EC2 instances. The WAF generates detailed logs and sends them to an Amazon CloudWatch Logs group. Each log event contains a severity field, such as SEVERITY=LOW, SEVERITY=MEDIUM, or SEVERITY=CRITICAL. The security operations team requires an immediate email notification the moment any log event containing 'SEVERITY=CRITICAL' is ingested. What is the most direct and cost-effective way to implement this alerting mechanism?

ASet up a CloudWatch Logs subscription filter to stream all logs to Amazon Kinesis Data Firehose, which then stores them in an S3 bucket. An S3 event notification then triggers a Lambda function to scan the log file for critical events and send an email.

BEnable Amazon GuardDuty to analyze the CloudWatch Logs and use its findings to trigger an Amazon EventBridge rule for critical events.

CCreate a CloudWatch Logs metric filter that specifically counts the occurrences of the text 'SEVERITY=CRITICAL'. Create a CloudWatch alarm that monitors this new custom metric and triggers a notification to an Amazon SNS topic when the count is greater than zero. Subscribe the security team's email to the SNS topic.

DCreate a Lambda function that is triggered on a schedule by Amazon EventBridge every one minute. The function will query the CloudWatch Logs group for recent critical events and send an email if any are found.

Explanation

This scenario calls for a real-time, pattern-based alerting system directly from log data, which is a primary use case for CloudWatch features. Why the CloudWatch Logs metric filter approach is correct: This is the most efficient and native AWS solution. A CloudWatch Logs metric filter is designed to scan incoming log data for specific patterns (like the string 'SEVERITY=CRITICAL') and convert matches into a numeric CloudWatch metric. You can then create a CloudWatch alarm based on this metric. By setting the alarm threshold to be greater than or equal to 1, the alarm will trigger the instant the first critical event is detected. The alarm's action can be to publish a message to an SNS topic, which then emails the subscribed security team. This entire process is serverless, real-time, and highly cost-effective. Why other approaches are incorrect: The Kinesis Data Firehose solution is overly complex and expensive. It introduces multiple services (Kinesis, S3, Lambda) and data transfer steps, adding latency and cost where a simpler solution exists. The Amazon GuardDuty approach is incorrect because GuardDuty is a threat detection service that analyzes specific AWS data sources like VPC Flow Logs, DNS logs, and CloudTrail events. It does not analyze custom application logs for arbitrary text patterns. The scheduled Lambda function approach is not real-time. A Lambda function triggered every minute by EventBridge introduces a delay of up to one minute between the event occurring and the alert being sent. The metric filter approach is immediate.

2. A financial services firm, SecureFunds, uses a standard buildspec.yml file in its AWS CodeBuild projects. A recent security review highlighted several issues with the current configuration. The buildspec file hardcodes AWS access keys and a database password as environment variables. It also uses raw ssh and scp commands to transfer build artifacts. A DevOps engineer must redesign this process to align with AWS security best practices. What changes should the engineer recommend? (Select TWO.)

Multiple correct answers

AStore the database password as a SecureString parameter in AWS Systems Manager Parameter Store. Reference this parameter in the CodeBuild project settings instead of defining it as a plain-text environment variable in the buildspec.yml file.

BEncode the credentials using Base64 and keep them as environment variables to obscure them from plain-text view.

CIn the post-build phase, add commands to securely delete (rm -rf) all files and logs that might contain the credentials from the build container.

DInstead of hardcoding AWS access keys, remove them and assign an IAM role with the necessary permissions to the CodeBuild project's service role. Replace the ssh and scp commands with AWS Systems Manager Run Command to securely interact with target instances.

EMove the credentials to a private S3 bucket with server-side encryption and have the buildspec.yml file download them during the pre-build phase.

Explanation

This scenario requires correcting several common security anti-patterns in a CI/CD process. The goal is to remove all long-term, static credentials from the configuration files. The first critical change is to eliminate the hardcoded AWS access keys. The correct and secure way for an AWS service like CodeBuild to interact with other AWS services is by using an IAM role. You should configure the CodeBuild project to use a service role that has been granted the specific permissions it needs. This provides temporary, automatically-rotated credentials. Additionally, using raw ssh and scp requires managing SSH keys and opening network ports. A more secure and manageable approach is to use AWS Systems Manager Run Command, which allows you to execute commands on instances securely through the SSM agent without needing direct network access like SSH. The second critical change is to secure the database password. Storing it as a plain-text environment variable is highly insecure. The best practice is to store it as a SecureString parameter in AWS Systems Manager Parameter Store. This encrypts the secret at rest. The CodeBuild project can then securely retrieve it at runtime by referencing the parameter, with access controlled by its IAM role. Encoding with Base64 provides no real security as it's easily reversible. Deleting files at the end of the build doesn't fix the root problem of exposing credentials in the first place. Storing secrets in S3 is not the recommended practice compared to dedicated services like Parameter Store or Secrets Manager.

3. An online forum application, ForumSphere, uses a DynamoDB table with a partition key of ForumName and a sort key of Subject. A new reporting feature requires finding all threads posted within a specific ForumName during the last 90 days, sorted by the LastPostDateTime. How should this query be implemented efficiently?

ADirectly query the base table using ForumName and LastPostDateTime as key conditions.

BCreate a new DynamoDB table with a Local Secondary Index (LSI) on the LastPostDateTime attribute. Migrate all data to this new table and use a Query operation on the LSI.

CAdd a Global Secondary Index (GSI) to the existing table with ForumName as the partition key and LastPostDateTime as the sort key. Use a Query operation on the GSI.

DPerform a Scan operation on the entire table and use a filter expression to find posts within the last 90 days.

Explanation

This question tests your understanding of DynamoDB's query capabilities and the rules for creating secondary indexes. The existing table's primary key (ForumName, Subject) does not support efficient queries sorted by date. To support this new query pattern, an index is required. A Local Secondary Index (LSI) is ideal because the query is still scoped to the same partition key (ForumName) but needs a different sort key (LastPostDateTime). However, a critical rule for DynamoDB is that you cannot add an LSI to a table after it has been created. Therefore, the only way to implement this is to create a new table with the desired schema, including the LSI on LastPostDateTime, and then perform a one-time data migration from the old table to the new one. The application can then perform an efficient Query operation against the new table's LSI. A Scan operation is highly inefficient and should always be avoided for frequent access patterns. A GSI would also work for the query, but creating a new table with an LSI is often preferred when strong read consistency on the index is a potential future requirement. You cannot directly query on LastPostDateTime as it's not part of the base table's key.

4. A tech team is migrating their Kubernetes workload from EC2 to Amazon EKS for better scalability. They need email notifications for specific EKS component log events, planning to use SNS for notifications and Lambda for log evaluation. What's the best approach?

ASend EKS logs to S3 bucket and enable PUT object notifications to trigger Lambda

BSend EKS logs to CloudWatch Logs, write Logs Insights queries per component, associate results with EventBridge to trigger Lambda

CPublish EKS logs to S3 with server access logging, configure subscription filters with Lambda as destination

DPublish EKS logs to CloudWatch Logs, configure subscription filters per component with Lambda as destination

Explanation

CloudWatch Logs with subscription filters provides the optimal solution for real-time log processing and notifications. Here's the complete workflow: EKS components generate logs that are published to CloudWatch Logs, where each component typically has its own log group. Subscription filters act as real-time log processors that can filter specific patterns and forward matching events to destinations like Lambda, Kinesis, or Firehose. For this scenario, you create subscription filters with filter patterns that match the specific events requiring notifications. These filters forward matching log entries to Lambda functions in real-time. The Lambda function receives the filtered logs, evaluates them further if needed, and triggers SNS notifications. The key advantage is that subscription filters support pattern matching, so Lambda is only invoked for relevant events, not every log entry. This makes the solution cost-effective and performant. The logs are also Base64 encoded and gzip compressed when sent to Lambda, optimizing data transfer. The S3 approach would require Lambda invocation for every log file upload, regardless of content, making it inefficient and costly. CloudWatch Logs Insights is for ad-hoc querying, not real-time event processing, and has no EventBridge integration. S3 server access logging only tracks S3 bucket access, not EKS component logs. This architecture provides real-time, filtered log processing with minimal latency and cost.

5. The central IT team at a large research university is concerned about cost overruns from idle resources left running in student and faculty AWS accounts. They have identified that AWS Trusted Advisor provides an 'Idle Load Balancers' check. They need an automated way to get a daily notification summarizing the findings of this check. Which three of the following methods could be used to build this notification system?

Multiple correct answers

AConfigure an Amazon EventBridge rule that listens for the 'Trusted Advisor Check Item Refresh' event for the specific idle load balancer check. Set the rule's target to an SNS topic to send a notification.

BUse AWS Config to create a custom rule that detects idle load balancers based on traffic metrics.

CCreate a CloudWatch alarm based on the specific Trusted Advisor metric for the number of idle load balancers. Configure the alarm to send a notification to an SNS topic if the number is greater than zero.

DWrite an AWS Lambda function, triggered daily by an EventBridge schedule, that calls the Trusted Advisor API to get the check results, formats a report, and sends it to an SNS topic.

ELaunch a t3.micro EC2 instance to run a cron job that calls the AWS CLI to check for idle load balancers and sends an email via Amazon SES.

FManually log in to the AWS console each day to check the Trusted Advisor dashboard.

Explanation

Automating notifications from AWS Trusted Advisor can be achieved through its integration with other AWS services like EventBridge and CloudWatch. Why these approaches are correct: The EventBridge event-driven approach is the most direct method. Trusted Advisor emits an event to EventBridge whenever a check's status is refreshed. You can create a rule to capture this specific event and immediately trigger a notification to an SNS topic. The CloudWatch alarm approach leverages another native integration. Trusted Advisor exposes its check results as CloudWatch metrics. You can create an alarm on the metric that counts the number of idle load balancers, and this alarm can trigger an SNS notification. The scheduled Lambda function approach provides the most flexibility for custom reporting. A Lambda function can programmatically call the Trusted Advisor API, retrieve the detailed results of the check, format them into a human-readable report, and then publish that report to an SNS topic on a daily schedule via EventBridge. Why other approaches are incorrect: Using AWS Config is incorrect because Config is designed for checking resource configuration compliance, not for analyzing utilization metrics like idleness. Running a cron job on an EC2 instance is not a serverless or low-overhead solution; it requires managing an EC2 instance and a custom script, adding unnecessary operational overhead. Manually checking the Trusted Advisor dashboard is a manual process and does not meet the automation requirement for daily notifications.

One-time access to this exam

Full access to all 436 questions

Or $15/mo for all 201 exams

Detailed explanations

Free preview stays available