SAA-C03 Design High-Performing Architectures Practice Question

A web API runs on an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). During traffic spikes, users experience request timeouts even though CPU stays below 40%. After investigation, you find the ASG often has too few healthy targets to handle the current request rate. Which change will best improve responsiveness during spikes?

⚠ Common exam trap

Many exam-takers assume CPU utilization is always the best scaling metric, but AWS explicitly tests that ALB-level metrics (RequestCountPerTarget, TargetResponseTime) are more appropriate when the bottleneck is request throughput rather than compute load.

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 an ALB metric such as RequestCountPerTarget or TargetResponseTime.

The issue is that the ASG has too few healthy targets to handle the request rate, even though CPU is low. A target tracking scaling policy based on RequestCountPerTarget or TargetResponseTime directly aligns scaling with the ALB's view of demand, ensuring the ASG adds instances when request rates spike, regardless of CPU utilization. This addresses the root cause—insufficient capacity to serve incoming requests—rather than relying on a metric (CPU) that does not reflect the bottleneck.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Keep the ASG scaling policy based on CPU utilization, but increase the ASG min capacity by 50%.
Why it's wrong here
Raising the minimum capacity can reduce the odds of running out of healthy targets, but the scaling decision is still driven by CPU. In this scenario, CPU is explicitly <40% during the timeouts, so CPU-based scaling may not trigger additional capacity early enough for the request-rate increase. This also permanently increases baseline cost even when traffic is low.
✓
Create a target tracking scaling policy using an ALB metric such as RequestCountPerTarget or TargetResponseTime.
Why this is correct
Target tracking with an ALB performance metric scales based on the same layer where the problem is observed (requests/latency through the ALB). As traffic spikes, RequestCountPerTarget and/or TargetResponseTime increase; the scaling policy then increases the ASG desired capacity so the ALB has more healthy targets to distribute requests to. That reduces queuing/latency and helps prevent timeouts without waiting for CPU to rise.
✗
Enable EC2 detailed monitoring for one-minute granularity and keep CPU scaling.
Why it's wrong here
More frequent CPU measurements may make scaling react slightly faster, but it does not change the underlying signal. Since CPU remains below 40% during timeouts, the CPU metric still won’t reflect the bottleneck (insufficient healthy targets for the request rate), so scaling may not increase capacity when needed.
✗
Switch to scaling based on the ASG network out bytes metric only, ignoring ALB response metrics.
Why it's wrong here
Network out bytes can correlate with traffic, but it is not a direct measure of user-perceived performance. It can be noisy (for example, from background data transfer) and it may not capture saturation effects that show up as rising ALB latency or request queuing. ALB request/latency metrics provide a closer feedback loop to timeouts.

Go deeper

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question