DOP-C02 Incident and Event Response Practice Question
A DevOps team is configuring an Auto Scaling group for a web application behind an Application Load Balancer. The team wants to automatically replace instances that fail the health check. Which scaling policy should be used?
⚠ Common exam trap
The trap is confusing scaling policies (which adjust capacity based on load metrics) with the automatic health check replacement, which is a default feature of Auto Scaling groups. Scaling policies are not involved in replacing unhealthy instances.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Default health check replacement
The correct approach is not a scaling policy but the Auto Scaling group's built-in health check replacement functionality. When the Auto Scaling group is configured with ELB health checks, it automatically terminates and replaces instances that the Application Load Balancer marks unhealthy. No scaling policy is required for this behavior.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Target tracking scaling policy
Why it's wrong here
A target tracking scaling policy dynamically adjusts the group's desired capacity to keep a CloudWatch metric such as average CPU utilization near a specified target value. It does not evaluate the health checks of individual instances, so an instance failing its EC2 status or Elastic Load Balancing health check will not be terminated simply because this policy is attached. Unhealthy instance replacement requires the Auto Scaling group's health check configuration rather than a load-based scaling policy.
- ✓
Default health check replacement
Why this is correct
When the Auto Scaling group is configured with EC2 health checks or an attached Elastic Load Balancer's health checks, it automatically detects instances that become unhealthy. The default health check replacement behavior marks the failing instance as unhealthy, terminates it, and launches a replacement instance to restore desired capacity, all without manual intervention. This is the underlying mechanism that keeps the web tier healthy, making it the correct choice for replacing faulty instances.
- ✗
Step scaling policy
Why it's wrong here
A step scaling policy increases or decreases the group's desired capacity in defined increments based on CloudWatch alarm thresholds, such as adding two instances when CPU exceeds 80%. Although this policy reacts to load-related metrics, it has no awareness of an instance's health status, so a single failed instance may remain in service if aggregate metrics stay within bounds. Replacing unhealthy instances is governed by health check replacement, not step adjustments.
- ✗
Manual scaling
Why it's wrong here
Manual scaling means a DevOps engineer or operator must explicitly update the desired capacity value through the console, CLI, or API. This approach is reactive and requires a human to first notice that an instance is unhealthy and then decide to terminate and replace it, which introduces delay and does not provide automated health-based replacement. It is therefore not the correct mechanism for automatically maintaining a healthy fleet.
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,298-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.