Skip to main content

Practice exam · AWS

AWS Certified DevOps Engineer - Professional (DOP-C02) practice exam

50
questions
180
minutes
75%
to pass the practice exam
59
questions in the bank

Short answer

The AWS Certified DevOps Engineer - Professional (DOP-C02) practice exam has 50 questions in 180 minutes, with a 75% passing mark, as configured here. The fastest way to know whether you are ready is to sit a full exam on the clock and read your score by domain, not only the total.

Domains covered

  • Configuration Management and IaC
  • Incident and Event Response
  • Resilient Cloud Solutions
  • SDLC Automation
  • Security and Compliance
  • Monitoring and Logging

Sample questions, with explanations

Three questions from the bank, open to read.

Question 1 · Security and Compliance

A platform team must guarantee that every new S3 bucket created in any account of an AWS Organization is automatically remediated to disable public access within minutes of creation, without relying on developers to opt in. They have AWS Config, Security Hub, and Systems Manager enabled organization-wide. Which approach delivers automatic, continuous detection AND remediation with the least custom code?

  1. Enable Security Hub's AWS Foundational Security Best Practices standard and rely on its built-in automatic remediation to disable public access on any flagged S3 bucket.
  2. Create an EventBridge rule on CloudTrail CreateBucket events in each account that invokes a Lambda function to call PutPublicAccessBlock, deploying the rule and Lambda through StackSets.
  3. Configure S3 Block Public Access at the account level using a single PutPublicAccessBlock call in the management account, which propagates the setting to all member accounts automatically.
  4. Deploy an organization-managed AWS Config rule (s3-bucket-public-read-prohibited) via a conformance pack, attach an SSM Automation document as the Config remediation action, and set the remediation to automatic so non-compliant buckets are fixed without manual approval. ✓ (correct)
Why this is correct

The conformance-pack-plus-Config-remediation approach is correct: AWS Config rules can be deployed organization-wide via conformance packs, and Config natively supports attaching an SSM Automation document as a remediation action that runs automatically when a resource is non-compliant. This is the lowest-code path because the detection (managed rule) and the remediation (managed SSM document) are both AWS-provided. The EventBridge-CloudTrail-Lambda option works but is the higher-code answer the question explicitly steers away from ('least custom code') — you must write, deploy, and maintain a Lambda in every account plus StackSet plumbing, and it only catches the create event rather than providing continuous compliance evaluation. The Security Hub option is wrong because Security Hub itself does not perform automatic remediation; it aggregates findings and can trigger remediation only via EventBridge plus an external action (SSM/Lambda) — the 'built-in automatic remediation' described does not exist. The account-level Block Public Access option is wrong because PutPublicAccessBlock at the account level is per-account and does not 'propagate' from the management account to members; there is no inheritance of this setting across an Organization from a single call.

Question 2 · Incident and Event Response

An Auto Scaling group runs a stateful streaming-ingest fleet. On scale-in, instances must drain in-flight Kafka partitions and checkpoint offsets before termination, a process that takes up to 8 minutes. The team added an autoscaling lifecycle hook on `autoscaling:EC2_INSTANCE_TERMINATING` with `HeartbeatTimeout=300` and `DefaultResult=ABANDON`, and a Lambda subscribed via EventBridge that runs the drain script. During load tests, instances were terminated while still draining, losing data. Which combination correctly fixes the lifecycle hook so draining always completes?

  1. Keep HeartbeatTimeout=300 but change DefaultResult to CONTINUE so that if draining overruns, the instance proceeds to terminate gracefully instead of being abandoned.
  2. Set DefaultResult to ABANDON and rely on it: when the 300s timeout elapses mid-drain, ABANDON cancels the termination and returns the instance to InService so it can finish draining.
  3. Raise HeartbeatTimeout to cover the worst-case drain (e.g., 600s) AND have the drain Lambda call RecordLifecycleActionHeartbeat periodically, then CompleteLifecycleAction with CONTINUE on success; keep DefaultResult as ABANDON only as a safety net for stuck hooks. ✓ (correct)
  4. Replace the lifecycle hook with instance scale-in protection on every instance so the group can never terminate a draining instance automatically.
Why this is correct

The correct fix combines a timeout sized to worst-case drain with active heartbeats: RecordLifecycleActionHeartbeat resets the timer so a long-but-healthy drain isn't cut off, and CompleteLifecycleAction with CONTINUE releases the instance to terminate the instant the drain finishes — no waiting for the full timeout. The 8-minute drain exceeded the 300s timeout, which is exactly why instances were killed mid-drain. Changing DefaultResult to CONTINUE is wrong: CONTINUE on timeout means the instance proceeds to TERMINATE when the timer expires — so an overrunning drain still gets terminated, just 'gracefully' according to the hook, which does NOT prevent data loss. Scale-in protection is wrong as a remediation: protected instances are excluded from scale-in entirely, so the group can never scale in that fleet — it breaks autoscaling rather than enabling safe draining. The claim that ABANDON returns the instance to InService is a misconception: ABANDON abandons the lifecycle action and the instance proceeds to terminate immediately (skipping remaining hooks); it does NOT return the instance to service or pause termination.

Question 3 · Resilient Cloud Solutions

An Auto Scaling group of EC2 instances spans three Availability Zones behind an Application Load Balancer. Each instance mounts an Amazon EFS file system for shared session state. During a single-AZ impairment, the team observes that although the ASG launches replacement instances in the healthy AZs, a subset of new instances in one healthy AZ intermittently fail to start the application because they cannot reach the file system. The team wants to maximize fault tolerance against a full AZ loss. Which configuration is MOST likely the root cause and correct fix?

  1. The ALB lacks cross-zone load balancing; enable cross-zone load balancing so requests are evenly distributed across instances in all AZs.
  2. The EFS file system has mount targets in only two of the three AZs; create a mount target in every AZ where instances run so each instance accesses EFS through a local-AZ mount target. ✓ (correct)
  3. The EFS file system uses One Zone storage; migrate to EFS Standard so data is stored across multiple AZs for higher durability.
  4. The Auto Scaling group uses a single-AZ subnet; expand the ASG to subnets in all three AZs so replacement instances launch in healthy zones.
Why this is correct

Missing mount targets is the correct root cause: EFS is accessed via per-AZ mount targets, and an instance in an AZ without a mount target cannot mount the file system (or must cross AZs unreliably), which matches the symptom that only instances in one specific healthy AZ fail. Creating a mount target in every AZ where instances run fixes it. Cross-zone load balancing affects how the ALB distributes inbound requests across registered targets; it has nothing to do with an instance's ability to mount EFS at boot, so it would not cause or fix this. A single-AZ ASG subnet contradicts the scenario, which states the ASG already spans three AZs and successfully launches replacements in healthy AZs, so the subnet configuration is not the issue. Migrating from EFS One Zone to Standard would improve durability/availability of the data itself, but it does not address the connectivity symptom; even with Standard storage, instances in an AZ lacking a mount target still cannot mount, so it does not fix the described failure.

Take the full practice exam

  • 50 questions drawn from the bank, with a 180-minute timer
  • Score by domain and a review of every question
  • An AI tutor to talk through each question you miss
  • What you miss feeds your study plan
Start the practice examStudy the path first

Independent, unofficial practice exam. AWS and the exam name are trademarks of their owners; UpSkillScore is not affiliated with them. Format and passing mark are the exam's configuration in UpSkillScore, not an official statement.

Frequently asked questions

How many questions does the AWS Certified DevOps Engineer - Professional (DOP-C02) practice exam have?

It has 50 questions and a 180-minute limit. The passing mark of the practice exam is 75%.

Is this the official AWS Certified DevOps Engineer - Professional (DOP-C02) exam?

No. It is an independent practice exam built to match the structure of the real one. It does not replace the official exam.

Do I need an account to take it?

You can read the structure and sample questions without an account. Taking the full timed exam, scoring by domain and the AI tutor need one.