mediumMultiple Choice
CV0-004 Practice Question: Refer to the exhibit
Exhibit
[admin@controller ~]$ cldctl log asg-web --type scaling 2025-01-20 14:20:00 INFO Scaling event: Desired capacity changed from 2 to 3 2025-01-20 14:25:00 INFO Scaling event: Desired capacity changed from 3 to 2 2025-01-20 14:40:00 INFO Scaling event: Desired capacity changed from 2 to 3 2025-01-20 14:45:00 INFO Scaling event: Desired capacity changed from 3 to 2
Refer to the exhibit. The auto scaling group is fluctuating between 2 and 3 instances every few minutes. What is the most likely cause?
⚠ Common exam trap
CompTIA often tests the concept of scaling thrashing, and the trap here is that candidates may incorrectly attribute the oscillation to load balancer misconfiguration or instance health delays, rather than recognizing it as a direct symptom of overly sensitive scaling policies with insufficient cooldown or threshold margins.
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
✓
The scaling policies are based on metrics that are too sensitive.
The auto scaling group fluctuating between 2 and 3 instances every few minutes indicates a scaling policy that is too sensitive, likely based on a metric such as CPU utilization or request count per target that oscillates rapidly. When the metric crosses the scale-out threshold, a new instance launches, causing the metric to drop below the scale-in threshold, which then terminates an instance, creating a cycle. This is a classic symptom of thrashing due to overly aggressive or poorly configured scaling policies.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The instances are taking too long to become healthy.
Why it's wrong here
Slow instance health checks can cause scaling churn, but the described 2-to-3 oscillation every few minutes points to a cooldown or health-check grace period mismatch rather than slow boot alone. This option is tempting because unhealthy instances do trigger replacement, which is the correct diagnosis when instances fail checks outright rather than oscillating.
- ✗
The launch configuration has incorrect user data.
Why it's wrong here
Incorrect user data causes instances to fail health checks and be replaced, producing repeated termination and launch rather than a stable two-to-three oscillation. It is tempting because user data errors do break instances, and would be correct if instances never reached a healthy state.
- ✗
The load balancer is not properly distributing traffic.
Why it's wrong here
A load balancer distributing traffic unevenly changes per-instance load, not group capacity; scaling decisions follow aggregate metrics. It is tempting because load balancers influence scaling, and would be correct if one instance were saturated while others sat idle.
- ✓
The scaling policies are based on metrics that are too sensitive.
Why this is correct
Scaling policies react to metric thresholds; if those metrics fluctuate naturally around the target, the group adds and removes instances repeatedly. Overly sensitive thresholds or short cooldowns cause this rapid oscillation between two and three instances, matching the exhibit.
About these practice questions
This CV0-004 question is part of Courseiva's 834-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 CV0-004 practice question is part of Courseiva's free CompTIA 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 CV0-004 exam.