The answer is overly sensitive metrics causing auto scaling oscillation. This occurs when scaling policies react to metrics like CPU utilization or request count per target that fluctuate rapidly, triggering a cycle where a new instance launches, the metric drops below the scale-in threshold, an instance terminates, and the metric spikes again—creating the classic thrashing pattern between 2 and 3 instances. On the CompTIA Cloud+ CV0-004 exam, this tests your understanding of auto scaling fluctuation dynamics and the importance of choosing stable, smoothed metrics with appropriate cooldown periods. A common trap is confusing this with insufficient capacity or misconfigured load balancers, but the rapid, repeating cycle is the hallmark of overly sensitive thresholds. Remember the memory tip: “Oscillation equals overreaction—smooth your metrics to stop the seesaw.”
CV0-004 Operations and Support Practice Question
This CV0-004 practice question tests your understanding of operations and support. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
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?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue: "most likely"
Why it matters: Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
[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
A
The instances are taking too long to become healthy.
Why wrong: Slow instance health checks would cause missing scaling events but not oscillation.
B
The launch configuration has incorrect user data.
Why wrong: Incorrect user data would cause instances to fail but not cause the group to oscillate.
C
The load balancer is not properly distributing traffic.
Why wrong: Load balancer issues would cause traffic to back up, possibly triggering scaling, but not rapid oscillation typically.
D
The scaling policies are based on metrics that are too sensitive.
Oscillation occurs when metrics trigger both scale-out and scale-in frequently.
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.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
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 would cause missing scaling events but not oscillation.
✗
The launch configuration has incorrect user data.
Why it's wrong here
Incorrect user data would cause instances to fail but not cause the group to oscillate.
✗
The load balancer is not properly distributing traffic.
Why it's wrong here
Load balancer issues would cause traffic to back up, possibly triggering scaling, but not rapid oscillation typically.
✓
The scaling policies are based on metrics that are too sensitive.
Why this is correct
Oscillation occurs when metrics trigger both scale-out and scale-in frequently.
Clue confirmation
The clue word "most likely" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
Common exam traps
Common exam trap: answer the scenario, not the keyword
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.
Detailed technical explanation
How to think about this question
Under the hood, auto scaling groups use CloudWatch alarms with metrics like Average CPUUtilization or RequestCountPerTarget. If the scale-out threshold is set too close to the scale-in threshold (e.g., scale out at 60% and scale in at 50%), a small change in load can trigger both actions repeatedly. This is often exacerbated by the cooldown period (default 300 seconds) being too short or the metric having high variance, leading to a feedback loop where each new instance temporarily reduces the average metric, triggering scale-in, then removal increases it again, triggering scale-out.
KKey Concepts to Remember
Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A small business has 20 workstations on the 192.168.1.0/24 network and one public IP from its ISP. The router uses PAT (NAT overload) so all 20 devices share one public address using different source ports. NAT questions test whether you understand the four address terms and which direction each translation applies.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Operations and Support — This question tests Operations and Support — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: 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.
What should I do if I get this CV0-004 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Are there clue words in this question I should notice?
Yes — watch for: "most likely". Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.