DOP-C02 practice questions and answers
All 15 questions from Practice Test 2 for AWS Certified DevOps Engineer – Professional, with the correct answer and a full explanation for each — including why the other options are wrong. Free to read, no signup.
What this set covers
Questions are weighted to match the official DOP-C02 exam guide. The real exam is 75 (65 scored) questions in 180 minutes with a pass mark of 750 / 1000.
- SDLC Automation3 q · 22%
- Configuration Management and IaC2 q · 17%
- Resilient Cloud Solutions2 q · 15%
- Monitoring and Logging3 q · 15%
- Incident and Event Response2 q · 14%
- Security and Compliance3 q · 17%
A monolithic application runs on EC2 instances in an Auto Scaling group behind an Application Load Balancer. Releases currently use CodeDeploy in-place deployments and take 40 minutes, during which capacity is reduced and a bad release takes another 40 minutes to undo. The business wants full capacity during releases and a rollback measured in minutes. Doubling compute cost for the length of a deployment is acceptable. Which change should the DevOps engineer make?
- ASwitch the deployment group to CodeDeploy blue/green, provisioning a replacement Auto Scaling group and rerouting the load balancer once the new instances pass health checks.✓
- BKeep in-place deployments but change the deployment configuration to AllAtOnce to shorten the window.
- CIncrease the Auto Scaling group's desired capacity during deployments and keep the OneAtATime configuration.
- DBake a new AMI for each release and update the launch template, letting instance refresh replace instances gradually.
Correct answer: A — Switch the deployment group to CodeDeploy blue/green, provisioning a replacement Auto Scaling group and rerouting the load balancer once the new instances pass health checks.
Blue/green with CodeDeploy launches a parallel fleet, waits for health checks, then shifts the load balancer — capacity stays at 100% and rollback is a reroute back to the original instances, which takes minutes. AllAtOnce is faster but takes the whole fleet down at once and still needs a redeploy to undo. Adding capacity with OneAtATime keeps the same slow, in-place process. Instance refresh with a new AMI is a reasonable pattern but rolls forward gradually; undoing it means another full refresh.
CodeDeploy blue/green deploymentsA pipeline must start as soon as a new container image tagged `release` is pushed to an Amazon ECR repository. The current implementation has CodePipeline poll the source every minute, which adds delay and API calls. What is the recommended trigger?
- ACreate an Amazon EventBridge rule for the ECR Image Action Successful event, filtered on the repository and image tag, with the pipeline as the target.✓
- BReduce the CodePipeline polling interval to 10 seconds.
- CAdd an ECR lifecycle policy that starts the pipeline when a new image is added.
- DSchedule the pipeline to run every five minutes and exit early if the image digest has not changed.
Correct answer: A — Create an Amazon EventBridge rule for the ECR Image Action Successful event, filtered on the repository and image tag, with the pipeline as the target.
ECR emits image push events to EventBridge, and an event pattern can match the repository name and tag, starting the pipeline immediately. CodePipeline polling intervals are not user-tunable to seconds and polling is the pattern being replaced. Lifecycle policies expire old images; they do not invoke anything. A scheduled pipeline trades one form of polling for another.
Start a pipeline on an Amazon ECR source changeA regulated company requires that the exact artifact tested in staging is what reaches production, that a named release manager approves the production step, and that the approval is auditable. Which pipeline design satisfies this?
- AUse one pipeline where the build stage produces a versioned artifact, later stages consume that same input artifact, and a manual approval action with an SNS topic gates the production stage.✓
- BUse two pipelines, rebuilding the application from the same commit in the production pipeline after staging tests pass.
- CUse one pipeline that rebuilds the artifact at each stage with stage-specific build arguments.
- DUse a single deploy stage that pushes to staging and production in parallel, then run tests in both.
Correct answer: A — Use one pipeline where the build stage produces a versioned artifact, later stages consume that same input artifact, and a manual approval action with an SNS topic gates the production stage.
Building once and promoting the same artifact through stages is what guarantees production runs the tested bits, and a manual approval action records who approved it and when in the pipeline execution history. Rebuilding for production — in a second pipeline or per stage — can produce a different artifact from the same commit because dependencies and base images move. Deploying to both environments in parallel means production gets untested code.
Manual approval actions in CodePipelineA company must patch a mixed fleet of Windows and Linux EC2 instances on a schedule, with approval delays for new patches, an audit record of compliance, and the least possible custom tooling. Which two actions should the DevOps engineer take? (Select TWO.)
- AInstall and configure the SSM Agent on all instances, define patch baselines with auto-approval delays, and run patching as a Systems Manager maintenance window task.✓
- BUse the AWS-RunPatchBaseline SSM document, which supports both Windows and Linux instances.✓
- CUse the AWS-ApplyPatchBaseline SSM document so a single document covers Windows and Linux.
- DBuild a scheduled Lambda function that connects to each instance over SSH and WinRM to apply updates.
- EEnable CloudFormation automatic patching for the stacks that create the instances.
Correct answer: A, B — Install and configure the SSM Agent on all instances, define patch baselines with auto-approval delays, and run patching as a Systems Manager maintenance window task. · Use the AWS-RunPatchBaseline SSM document, which supports both Windows and Linux instances.
Patch Manager is the managed answer: the SSM Agent plus patch baselines with approval delays, executed on a maintenance window schedule, and compliance reported per instance. AWS-RunPatchBaseline is the current document and covers both operating systems, whereas AWS-ApplyPatchBaseline is the older Windows-only document. Driving SSH and WinRM from Lambda rebuilds the service badly, and CloudFormation has no patching feature — that option exists only as a distractor.
AWS Systems Manager Patch ManagerBackups are driven by a `BackupSchedule` tag on Amazon EBS volumes. An audit shows volumes created without the tag were never backed up. The company wants any untagged volume to receive a default tag automatically, both for existing volumes and for tags removed later. Which solution should be implemented?
- AEnable the AWS Config required-tags managed rule scoped to the AWS::EC2::Volume resource type, with a remediation action that runs an SSM Automation runbook to apply the default tag.✓
- BCreate an EventBridge rule on the CreateVolume CloudTrail event that runs an SSM Automation runbook to apply the tag.
- CEnable the AWS Config required-tags rule scoped to AWS::EC2::Instance and remediate the instance's attached volumes.
- DAdd a Trusted Advisor check for untagged volumes and email the owning team weekly.
Correct answer: A — Enable the AWS Config required-tags managed rule scoped to the AWS::EC2::Volume resource type, with a remediation action that runs an SSM Automation runbook to apply the default tag.
Config continuously evaluates the resource type you scope the rule to, so a volume that is created untagged — or has its tag removed months later — becomes non-compliant and the attached remediation puts the tag back. An EventBridge rule on CreateVolume only ever sees creation, so a tag deleted afterwards goes unnoticed. Scoping the rule to instances checks the wrong resource type and misses unattached volumes. Trusted Advisor reports; it does not remediate.
AWS Config required-tags ruleA global retailer runs an Aurora PostgreSQL cluster in eu-west-1. A regional outage must be survivable with an RPO of about one second and an RTO of a few minutes, and read traffic in ap-southeast-1 should be served locally with low latency. Which solution meets these requirements?
- ADeploy an Aurora global database with a secondary cluster in ap-southeast-1, serve local reads there, and promote the secondary during a regional failure.✓
- BEnable Multi-AZ for the cluster and take cross-Region automated snapshots every 15 minutes.
- CCreate an Aurora Replica in ap-southeast-1 inside the same cluster and use the reader endpoint.
- DUse AWS Database Migration Service with ongoing replication into an RDS PostgreSQL instance in ap-southeast-1.
Correct answer: A — Deploy an Aurora global database with a secondary cluster in ap-southeast-1, serve local reads there, and promote the secondary during a regional failure.
Aurora global database replicates with typical lag under a second using storage-level replication, serves low-latency reads from the secondary Region, and supports promotion of a secondary in minutes. Multi-AZ protects against an AZ failure, not a Region failure, and 15-minute snapshots blow the RPO. An Aurora cluster and its replicas live in one Region, so option C is not possible. DMS can replicate cross-Region but adds a pipeline to operate and does not give a managed one-step promotion.
Amazon Aurora global databasesA stateless batch service runs on Amazon ECS. The team wants to cut cost by running most tasks on Spot capacity while keeping a guaranteed baseline on On-Demand, and tasks must drain gracefully when Spot capacity is reclaimed. Which configuration meets this?
- AAttach both a FARGATE and a FARGATE_SPOT capacity provider to the cluster and set a capacity provider strategy with a base on FARGATE and the remaining weight on FARGATE_SPOT, and handle the SIGTERM stop timeout in the task.✓
- BRun the service on a single FARGATE_SPOT capacity provider and set the service's desired count higher to absorb interruptions.
- CUse an EC2 Auto Scaling group of Spot Instances with the ECS agent and no capacity provider, relying on the ASG to replace reclaimed instances.
- DUse AWS Batch with On-Demand compute and a scheduled scale-down outside business hours.
Correct answer: A — Attach both a FARGATE and a FARGATE_SPOT capacity provider to the cluster and set a capacity provider strategy with a base on FARGATE and the remaining weight on FARGATE_SPOT, and handle the SIGTERM stop timeout in the task.
A capacity provider strategy with `base` on the On-Demand provider guarantees the baseline, and weights send the rest to Spot. ECS sends SIGTERM and honours the stop timeout when Spot capacity is reclaimed, so a task that handles the signal drains cleanly. Spot only leaves no guaranteed baseline. A raw Spot ASG without capacity providers gives ECS no way to balance the two pools. AWS Batch on On-Demand simply gives up the savings.
Amazon ECS capacity providersAfter moving to microservices on Amazon ECS, a team cannot tell which service causes slow checkout requests. They need per-request latency broken down by service and downstream call, including calls to DynamoDB and an external payment API. What should the DevOps engineer implement?
- AInstrument the services with the AWS Distro for OpenTelemetry, run it as a sidecar, and send traces to AWS X-Ray to get a service map and segment timings.✓
- BEnable detailed CloudWatch metrics on the ECS services and alarm on average CPU.
- CTurn on Application Load Balancer access logs and analyse them with Amazon Athena.
- DEnable VPC Flow Logs on the service subnets and query them with CloudWatch Logs Insights.
Correct answer: A — Instrument the services with the AWS Distro for OpenTelemetry, run it as a sidecar, and send traces to AWS X-Ray to get a service map and segment timings.
Distributed tracing is what breaks a single request into segments per service and downstream call; ADOT collects the traces and X-Ray renders the service map with timings, including AWS SDK calls and external HTTP calls. CPU metrics say nothing about where a request spent its time. ALB logs cover the edge request only, not internal hops. Flow logs are network metadata with no request context.
AWS X-Ray with Amazon ECSAn on-call engineer needs alarms for memory usage and disk space on Amazon EC2 instances, but those metrics are missing from the EC2 namespace in CloudWatch. Why are they missing, and what is the fix?
- AMemory and disk are guest-level metrics that the hypervisor cannot see; install the CloudWatch agent to publish them as custom metrics and alarm on those.✓
- BDetailed monitoring is disabled; enable it to get one-minute memory and disk metrics.
- CThe metrics exist but only in the CWAgent namespace after enabling EC2 Instance Connect.
- DMemory and disk metrics require Amazon EC2 Auto Scaling group metrics collection to be enabled.
Correct answer: A — Memory and disk are guest-level metrics that the hypervisor cannot see; install the CloudWatch agent to publish them as custom metrics and alarm on those.
CloudWatch collects EC2 metrics from outside the instance, so it can see CPU, network and disk I/O at the device level but not what the operating system reports for memory or filesystem usage. The CloudWatch agent runs inside the instance and publishes those as custom metrics. Detailed monitoring only changes the resolution of existing metrics from five minutes to one. Instance Connect is an SSH access feature, and ASG group metrics describe the group, not the OS.
Collect metrics with the CloudWatch agentCloudWatch Logs costs have grown sharply. Investigation shows several log groups have no retention setting and hold three years of debug logs, and a compliance rule requires 12 months of one specific application log to remain queryable at low cost. Which combination of actions addresses both cost and compliance?
- ASet a retention policy on every log group, and for the compliance log group add a subscription filter or export to Amazon S3 with a lifecycle rule, querying it with Amazon Athena when needed.✓
- BDelete the old log streams manually each quarter and keep log groups set to Never expire.
- CReduce the log level in every application and leave retention unset.
- DMove all log groups to Amazon S3 by disabling CloudWatch Logs in the applications and writing files directly to a bucket.
Correct answer: A — Set a retention policy on every log group, and for the compliance log group add a subscription filter or export to Amazon S3 with a lifecycle rule, querying it with Amazon Athena when needed.
Log groups default to Never expire, so setting retention is the direct fix for the storage bill, and moving the compliance data to S3 keeps 12 months at object-storage prices while staying queryable through Athena. Manual quarterly deletion is toil that will be forgotten. Lowering log levels helps ingestion cost but leaves three years of stored data. Writing files straight to S3 from the applications throws away live tailing, metric filters and alarms.
Working with log groups and retentionAn ECS rolling deployment recently pushed a broken image; tasks crashed on startup and the service sat in a failed state until an engineer noticed and redeployed the previous task definition. Which built-in feature would have rolled the service back automatically?
- AEnable the ECS deployment circuit breaker with rollback on the service.✓
- BSet the service's minimum healthy percent to 0 so failed tasks are replaced faster.
- CAdd a CloudWatch alarm on task count and subscribe the on-call rota to an SNS topic.
- DIncrease the load balancer health check grace period for the service.
Correct answer: A — Enable the ECS deployment circuit breaker with rollback on the service.
The deployment circuit breaker watches how many tasks fail to reach a steady state during a rolling deployment, stops the deployment, and — when rollback is enabled — restores the last known good task definition without human involvement. A lower minimum healthy percent just replaces tasks faster with the same broken image. An alarm notifies but does not act. A longer grace period delays health checks, which would have made the outage last longer.
Amazon ECS deployment circuit breakerInstances in an Auto Scaling group behind an Application Load Balancer sometimes keep running while the application on them stops answering requests. The load balancer marks them unhealthy, but Auto Scaling leaves them in service. What should the DevOps engineer change?
- ASet the Auto Scaling group's health check type to ELB and set a health check grace period long enough for application start-up.✓
- BEnable EC2 instance status check alarms with an automatic reboot action.
- CEnable Auto Scaling group instance scale-in protection.
- DIncrease the ALB target group's healthy threshold count.
Correct answer: A — Set the Auto Scaling group's health check type to ELB and set a health check grace period long enough for application start-up.
By default an Auto Scaling group uses EC2 status checks, which pass while the operating system is fine and the application is dead. Switching the health check type to ELB makes the group act on the load balancer's view and replace the instance, with the grace period preventing new instances from being killed during start-up. Reboot actions on status check alarms address hardware and OS failures. Scale-in protection keeps bad instances alive. Raising the healthy threshold makes recovery slower, not faster.
Health checks for instances in an Auto Scaling groupA company with 120 accounts in AWS Organizations must guarantee that no account — including its administrators and the account root user — can stop CloudTrail logging or create resources outside two approved Regions. What should the DevOps engineer implement?
- AAttach a service control policy to the organizational units that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail and denies actions outside the approved Regions using the aws:RequestedRegion condition.✓
- BAttach an IAM policy with the same denies to every IAM role in every account.
- CCreate AWS Config rules that detect stopped trails and out-of-Region resources and notify the security team.
- DSet a permissions boundary on the administrator role in each account.
Correct answer: A — Attach a service control policy to the organizational units that denies cloudtrail:StopLogging and cloudtrail:DeleteTrail and denies actions outside the approved Regions using the aws:RequestedRegion condition.
SCPs set the maximum available permissions for member accounts, so an explicit deny applies even to account administrators and the root user — nothing inside the account can grant its way around it. IAM policies and permissions boundaries are managed within the account, so a local administrator can change them. Config rules detect after the fact and cannot prevent the action.
Service control policies (SCPs)A shared build account produces artifacts that deployment accounts must read from an S3 bucket. The artifacts are encrypted with a customer managed KMS key. Deployments fail with an AccessDenied error on decrypt, even though the bucket policy grants the deployment accounts s3:GetObject. What is missing?
- AThe KMS key policy must allow the deployment account principals to use the key (kms:Decrypt), and those principals need kms:Decrypt in their own IAM policies.✓
- BThe bucket must have Requester Pays enabled so the deployment accounts can decrypt objects.
- CThe artifacts must be copied to an unencrypted bucket before deployment.
- DThe deployment accounts must be added to the bucket ACL as authenticated users.
Correct answer: A — The KMS key policy must allow the deployment account principals to use the key (kms:Decrypt), and those principals need kms:Decrypt in their own IAM policies.
Reading an SSE-KMS object needs two grants: permission on the object from the bucket policy, and permission on the key. For cross-account use, both the key policy and the caller's IAM policy must allow kms:Decrypt — the key policy alone in one account is not enough. Requester Pays is about data transfer billing. Removing encryption defeats the control. Bucket ACLs are legacy and cannot grant KMS permissions.
Allowing users in other accounts to use a KMS keySecurity requires that container images with CRITICAL vulnerabilities never reach the production ECS cluster, and that the check happens automatically as part of the release process rather than as a periodic report. Which implementation meets the requirement?
- AEnable Amazon Inspector enhanced scanning on the ECR repository and add a pipeline stage that queries the scan findings for the pushed image digest and fails the build when a CRITICAL finding exists.✓
- BEnable ECR scan on push and review the findings in the console before approving the manual approval action.
- CRun Amazon Inspector on the production ECS tasks and raise a ticket when CRITICAL findings appear.
- DAdd an SCP that denies ecs:RunTask when the image contains vulnerabilities.
Correct answer: A — Enable Amazon Inspector enhanced scanning on the ECR repository and add a pipeline stage that queries the scan findings for the pushed image digest and fails the build when a CRITICAL finding exists.
Enhanced scanning continuously scans images pushed to ECR, and a pipeline stage that reads the findings for the exact image digest turns the scan into an enforced gate — the deployment simply does not happen. Human review before an approval action is a process control that gets rushed. Scanning running production tasks finds the problem after it shipped. SCPs evaluate IAM request context and cannot inspect image contents.
Enhanced scanning in Amazon ECRReady to try it under exam conditions?
Reading answers is not the same as recalling them with a clock running. Take the same 15 questions as a timed mock exam — 35 minutes, no feedback until you submit, then a score broken down by exam domain so you know what to study.
Start the timed DOP-C02 test →