DOP-C02 Target Tracking Scaling Policy Practice Question
A DevOps engineer is responsible for monitoring a production environment that uses Amazon EC2 Auto Scaling. The engineer notices that the Auto Scaling group has been launching and terminating instances frequently over the past hour. The group uses a dynamic scaling policy based on average CPU utilization. The CloudWatch alarm that triggers scaling is set to a threshold of 70% CPU for scale-out and 30% for scale-in. The engineer checks the CloudWatch metrics and sees that CPU utilization is oscillating between 40% and 60%, never reaching the thresholds. The engineer suspects that the scaling policy is not working correctly. The engineer is considering the following actions: A) Change the scaling policy to use a target tracking policy with a target value of 50% CPU utilization. B) Increase the cooldown period for the scaling policy to 300 seconds. C) Disable the scale-in policy to prevent frequent terminations. D) Use a simple scaling policy instead of a dynamic scaling policy. Which action should the engineer take?
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
✓
Change the scaling policy to use a target tracking policy with a target value of 50% CPU utilization.
A target tracking policy automatically adjusts the desired capacity to maintain a target utilization (e.g., 50%), which smooths out oscillations by continuously adapting to load rather than reacting to fixed thresholds. Option A is wrong because disabling scale-in could lead to over-provisioning and increased costs. Option C is wrong because simple scaling policies are more prone to causing oscillations due to step adjustments with cooldowns. Option D is wrong because increasing the cooldown period only delays scaling actions and does not address the root cause of oscillations; target tracking is more effective.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable the scale-in policy to prevent frequent terminations.
Why it's wrong here
Disabling the scale-in policy only stops the Auto Scaling group from terminating instances; it does nothing to correct the scale-out logic that is causing CPU utilization to spike and fall. Without the ability to reduce capacity, the group will tend to remain over-provisioned, driving up costs and potentially masking the oscillation because the metric stays low from excess capacity. The real issue is the lack of a coordinated scaling objective, which target tracking solves by using one policy that governs both scale-out and scale-in based on the same target.
- ✓
Change the scaling policy to use a target tracking policy with a target value of 50% CPU utilization.
Why this is correct
Target tracking is a dynamic scaling policy that uses a control loop to continuously compute the required capacity needed to keep the CloudWatch metric at the specified target value. Rather than reacting with binary on/off alarms, it applies proportional adjustments based on the current deviation from 50% CPU utilization, smoothing out capacity changes and preventing the overshoot/undershoot cycle that causes oscillation. This gives the Auto Scaling group a clear, single objective that balances responsiveness with stability.
- ✗
Use a simple scaling policy instead of a dynamic scaling policy.
Why it's wrong here
A simple scaling policy is inherently more likely to worsen oscillation because it relies on a single CloudWatch alarm breach to trigger a fixed step adjustment, followed by a cooldown. This coarse on/off behavior uses a predetermined step size without considering how far the metric is from the desired value, so it tends to over-react and then freeze, causing the metric to bounce between above- and below-threshold states. Target tracking, by contrast, continuously calculates the required capacity based on the current metric deviation and makes many small adjustments instead of one large step.
- ✗
Increase the cooldown period for the scaling policy to 300 seconds.
Why it's wrong here
Raising the cooldown period to 300 seconds only delays the next possible scaling action; it does not address why the CPU metric is oscillating in the first place. While a longer cooldown may temporarily suppress frequent alarm-driven actions, it also leaves the group blind to rapid changes in demand, increasing the risk of sustained under- or over-provisioning. The underlying problem is the threshold-based policy logic, which target tracking eliminates by continuously adjusting capacity in small, calculated increments rather than waiting out a timer.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.