Two Actions to Improve Auto Scaling Responsiveness
A company runs a web application on EC2 instances behind an Application Load Balancer (ALB). The application experiences periodic spikes in traffic. The operations team wants to ensure that the application can handle the spikes without manual intervention. What is the MOST cost-effective solution?
⚠ Common exam trap
SAP-C02 often tests the choice between target tracking and simple/scheduled scaling; candidates may pick CPU-based simple scaling out of habit, but the exam expects recognition that RequestCountPerTarget target tracking is more direct and cost-effective for ALB-fronted web apps.
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
✓
Create a target tracking scaling policy using the ALB RequestCountPerTarget metric.
A target tracking scaling policy using the ALB RequestCountPerTarget metric automatically adjusts the number of EC2 instances to maintain a target value for requests per target, which directly correlates with traffic spikes. This is the most cost-effective because it scales in and out dynamically based on actual load, avoiding over-provisioning. It requires no manual intervention and responds to traffic changes in near real-time.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a scheduled scaling policy to add instances during predicted peak hours.
Why it's wrong here
Scheduled scaling only adds capacity at preconfigured times, so unpredicted spikes still overwhelm the fleet. It is tempting because it is cost-effective for traffic with a known, repeating pattern, such as business-hours peaks, where the schedule reliably matches demand.
- ✓
Create a target tracking scaling policy using the ALB RequestCountPerTarget metric.
Why this is correct
Target tracking on the ALB RequestCountPerTarget metric scales EC2 capacity directly with incoming request load, satisfying the no-manual-intervention requirement during traffic spikes. Because it reacts to demand rather than a fixed schedule, instances are added only when needed and removed afterwards, delivering the most cost-effective elasticity for periodic, unpredictable spikes.
- ✗
Manually add instances when traffic spikes are expected.
Why it's wrong here
Manual intervention directly contradicts the requirement for automatic handling of spikes, and operators cannot react fast enough during sudden traffic surges. It is tempting as a zero-configuration approach for rare, predictable events, but it fails the no-manual-intervention criterion outright.
- ✗
Use a simple scaling policy based on CPU utilization.
Why it's wrong here
Simple scaling enforces a cooldown between scaling activities, so it reacts too slowly to sharp spikes and cannot scale in as smoothly as target tracking. It is tempting because CPU-based rules are easy to configure, but step or target tracking scaling responds faster to utilisation changes.
Go deeper
Related to this question
About these practice questions
One of 984 original SAP-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 →
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 Amazon Web Services exam blueprint
This SAP-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 SAP-C02 exam.