DOP-C02 Incident and Event Response Practice Question
A company uses EC2 instances in an Auto Scaling group behind an ALB. The DevOps team receives alerts that the CPU utilization on the instances is consistently above 90% during peak hours. The Auto Scaling group is configured with a simple scaling policy that adds one instance when CPU exceeds 80% and removes one when below 30%. However, during sudden traffic spikes, the scaling policy reacts too slowly, causing performance degradation. The team wants to improve the scaling responsiveness without over-provisioning. What should the team do?
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
✓
Replace the simple scaling policy with a target tracking scaling policy based on average CPU utilization with a target value of 70%.
A target tracking scaling policy automatically adjusts the size of the Auto Scaling group to keep the average CPU utilization close to the target value (70%). This provides a proactive and responsive scaling mechanism for sudden traffic spikes without manual intervention. Option A is incorrect because increasing the cooldown period would delay scaling actions, worsening the response time. Option B is incorrect because although a step scaling policy can add multiple instances at once, it requires manual configuration of thresholds and step adjustments, and it may not adapt as smoothly to varying spikes as target tracking. Option C is incorrect because scheduled scaling only addresses predictable traffic patterns, not sudden, unpredictable spikes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the cooldown period for the simple scaling policy to allow more time for metrics to stabilize.
Why it's wrong here
Increasing the cooldown period for the simple scaling policy would actually worsen the problem: after a scale-out action, the cooldown prevents any further scaling actions for a longer duration, so if the CPU continues to spike or a second spike occurs, Amazon EC2 Auto Scaling cannot add more instances until the cooldown expires. This delays the very capacity that is needed to handle sudden traffic surges, making the response slower, not more stable. Cooldowns help avoid thrashing but at the cost of responsiveness, and they do nothing to address the root cause of the simple scaling policy's lag in reacting to sharp utilization changes.
- ✗
Replace the simple scaling policy with a step scaling policy that adds multiple instances when CPU exceeds 80%.
Why it's wrong here
While a step scaling policy can be more responsive than simple scaling by adding multiple instances at once, it requires manual configuration of thresholds and actions. Target tracking is more automated and efficient for maintaining a target metric.
- ✗
Create a scheduled scaling action to add instances before peak hours based on historical data.
Why it's wrong here
Scheduled scaling can only add capacity at predetermined times based on historical patterns, so it cannot react to sudden, unanticipated traffic spikes—the exact problem described in the scenario. While it might be useful for predictable peak-hours, it provides no benefit when a spike occurs at an unexpected time, and it could also over-provision during quiet periods, increasing cost. Without an event-driven mechanism that continuously monitors CPU utilization (like target tracking), scheduled actions simply cannot meet the requirement to scale dynamically in response to real-time load.
- ✓
Replace the simple scaling policy with a target tracking scaling policy based on average CPU utilization with a target value of 70%.
Why this is correct
A target tracking scaling policy with a target value of 70% average CPU utilization proactively adds instances before utilization reaches 80% and continuously adjusts to maintain the target, providing fast response to spikes without over-provisioning.
Go deeper
Related to this question
About these practice questions
One of 1,339 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company uses an Auto Scaling group with a dynamic scaling policy based on the average CPU utilization of the instances. During an incident, the DevOps team notices that the Auto Scaling group is not launching new instances quickly enough to handle a traffic spike. What is a possible cause for the slow scaling response?
medium- ✓ A.The cooldown period is set too high.
- B.The health check grace period is set too low.
- C.The minimum group size is set too low.
- D.The launch template has a long warm-up time.
Why A: The cooldown period prevents the Auto Scaling group from launching or terminating instances after a scaling activity. If the cooldown is too long, it delays subsequent scaling actions. Option B is wrong because the health check grace period is for instance health checks after launch, not scaling speed. Option C is wrong because the minimum group size is irrelevant to scaling speed. Option D is wrong because the warm-up time for the launch template is not a real parameter.
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.