CV0-004 Operations and Support Practice Question
A cloud operations team runs a three-tier application on Amazon EC2 instances behind an Application Load Balancer. During a peak-traffic event, users report intermittent 503 errors, and the operations team wants to automatically add capacity when the average CPU utilization of the Auto Scaling group exceeds 70 percent for five consecutive minutes, then remove capacity when it drops below 30 percent. Which TWO configuration elements must the team define to accomplish this? (Choose two.)
⚠ Common exam trap
The trap here is assuming a single target tracking policy can enforce two different thresholds, when target tracking maintains one target value and cannot express separate scale-out and scale-in conditions.
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
✓
A second CloudWatch alarm that enters the ALARM state when CPU utilization is less than 30 percent for the same evaluation window.
Dynamic scaling in an Auto Scaling group is driven by CloudWatch alarms that translate metric thresholds into scaling actions. Because the scenario specifies different thresholds for scaling out and scaling in, two separate alarms are needed: one for CPU above 70 percent and one for CPU below 30 percent, each evaluated over the stated five-minute window. Target tracking and budget alarms cannot express this asymmetric 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.
- ✓
A second CloudWatch alarm that enters the ALARM state when CPU utilization is less than 30 percent for the same evaluation window.
Why this is correct
Scale-in requires its own trigger because the threshold differs from scale-out. A separate CloudWatch alarm with a less-than-30-percent condition, evaluated over the same period, provides the discrete signal the Auto Scaling group needs to remove capacity only after utilization genuinely drops, matching the scenario's stated scale-in condition.
- ✗
An AWS Budgets alarm set to notify when EC2 spending exceeds 70 percent of the monthly forecast.
Why it's wrong here
AWS Budgets tracks cost and usage against financial thresholds, not runtime performance metrics. A budget notification fires on spend forecasts and cannot add or remove EC2 capacity in response to CPU utilization. It addresses cost governance, which is unrelated to the performance-driven scaling requirement described in the scenario.
- ✓
A CloudWatch alarm that enters the ALARM state when CPU utilization is greater than 70 percent for five consecutive evaluation periods.
Why this is correct
CloudWatch alarms evaluate metrics against thresholds over a defined number of periods. Configuring the alarm to breach when average CPU exceeds 70 percent for five consecutive five-minute periods gives the precise scale-out trigger the scenario requires, and that alarm can then be referenced as the scaling policy trigger for the Auto Scaling group.
- ✗
An Application Load Balancer health check configured with a 70 percent healthy threshold.
Why it's wrong here
ALB health checks determine whether individual targets are healthy enough to receive traffic; they do not measure aggregate CPU utilization and cannot trigger capacity changes. A 70 percent healthy threshold is not a valid health-check parameter, and even a valid health check would not produce the CPU-based scale-out and scale-in behavior the scenario demands.
- ✗
A target tracking scaling policy attached to the Auto Scaling group with a target value of 70 percent.
Why it's wrong here
Target tracking maintains a metric at a target value, but it does not natively support the asymmetric thresholds of 70 percent for scale-out and 30 percent for scale-in described in the scenario. Using a single target value would cause the group to oscillate around 70 percent instead of scaling in only after utilization falls below 30 percent, so this does not satisfy the stated requirement.
Quick reference
Asymmetric Encryption Algorithm Comparison
| Algorithm | Key Exchange | Signatures | Equivalent Security Key | Notes |
|---|---|---|---|---|
| RSA-3072 | Yes | Yes | 128-bit | Widely deployed; slow for bulk data |
| ECDSA P-256 | No | Yes | 128-bit | Fast signatures; standard TLS certs |
| ECDH / ECDHE | Yes | No | 128-bit | Perfect forward secrecy in TLS 1.3 |
| DH / DHE | Yes | No | 128-bit (3072-bit key) | Replaced by ECDHE in modern TLS |
| Ed25519 | No | Yes | ~128-bit | SSH keys, modern PKI |
Go deeper
Related to this question
About these practice questions
Courseiva writes every CV0-004 question from scratch — 834 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
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.