How to Reduce Latency During Peak Traffic Without Overprovisioning Using Target Tracking Scaling
Exhibit
ALB and ASG snapshot (15-minute peak): - RequestCountPerTarget: 1,920 - TargetResponseTime p95: 2.9 seconds - HTTPCode_Target_5XX_Count: 0 EC2 application metrics from CloudWatch agent: - CPUUtilization: 33% - MemoryUtilization: 46% - NetworkIn/Out: steady Application logs: [WARN] worker queue depth reached 5,000 [INFO] rejecting requests after thread pool saturation Current Auto Scaling policy: - Target tracking on CPUUtilization = 55%
Based on the exhibit, which change best reduces latency during peak traffic without overprovisioning the fleet?
Quick Answer
The answer is to change the Auto Scaling policy to target tracking on ALB RequestCountPerTarget. This is correct because target tracking scaling dynamically adjusts the fleet size based on the actual number of requests each instance receives, directly addressing the need to reduce latency during peak traffic without overprovisioning. By maintaining a target metric per instance, the policy adds capacity only when demand spikes, distributing the load efficiently and preventing performance degradation. On the SAA-C03 exam, this scenario tests your understanding of how to balance cost and performance using advanced scaling policies, often appearing as a trap where simple step scaling or scheduled scaling leads to overprovisioning or lag. A common memory tip is to think of “per-target” as per-instance fairness—if you want to keep each instance’s request count steady, use target tracking on that metric. Remember: for latency under load, track per target, not just overall CPU.
⚠ Common exam trap
Many candidates confuse reducing latency with scaling the fleet, often choosing a load balancer change (Option D) or a static instance upgrade (Option A) instead of recognizing that dynamic scaling based on per-target request count is the correct method to handle peak traffic without overprovisioning.
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
✓
Change the Auto Scaling policy to target tracking on ALB RequestCountPerTarget.
Using a target tracking scaling policy on ALB RequestCountPerTarget dynamically adjusts the fleet size based on the actual number of requests each instance receives. This ensures that during peak traffic, additional instances are added only when needed, reducing latency by distributing the load without overprovisioning. It directly addresses the goal of minimizing latency during spikes while maintaining cost efficiency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Replace the instances with a larger instance family so each server has more headroom.
Why it's wrong here
Bigger instances can help only when compute saturation is the main bottleneck, but the exhibit points to queue buildup and request concurrency.
When this WOULD be correct
This would be correct if the question asked for a solution to improve performance for a consistently high-traffic application where the current instance type is underpowered, and cost is not a primary concern.
- ✓
Change the Auto Scaling policy to target tracking on ALB RequestCountPerTarget.
Why this is correct
RequestCountPerTarget matches the actual demand reaching each instance and scales capacity before the thread pool saturates. Because CPU is still low, CPU-based scaling would react too late or not at all. Target tracking on request count helps keep queue depth and latency down while avoiding unnecessary overprovisioning during quieter periods.
- ✗
Use scheduled scaling to add instances only during the business hours peak window.
Why it's wrong here
Scheduled scaling follows the clock, not live demand, so it cannot react well to sudden surges or shifting traffic patterns.
When this WOULD be correct
If the question states that traffic spikes are predictable and occur at the same time every day (e.g., a known business hours peak), and the goal is to ensure capacity is ready exactly when needed without relying on dynamic scaling metrics, then scheduled scaling would be the best choice.
- ✗
Replace the ALB with a Network Load Balancer to reduce request latency.
Why it's wrong here
A Network Load Balancer changes the front end, but the logs show application thread exhaustion rather than load balancer overhead.
When this WOULD be correct
In a scenario where the application is latency-sensitive at the transport layer (e.g., for UDP traffic or extreme low-latency requirements) and the ALB's processing overhead is the bottleneck, replacing it with an NLB would be correct. The question would specify that compute capacity is adequate and the latency issue stems from the load balancer itself.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Change the Auto Scaling policy to target tracking on ALB RequestCountPerTarget.Correct answer▾
Why this is correct
RequestCountPerTarget matches the actual demand reaching each instance and scales capacity before the thread pool saturates. Because CPU is still low, CPU-based scaling would react too late or not at all. Target tracking on request count helps keep queue depth and latency down while avoiding unnecessary overprovisioning during quieter periods.
✗Replace the instances with a larger instance family so each server has more headroom.Wrong answer — click to see why▾
Why this is wrong here
Replacing instances with a larger family increases headroom but does not dynamically adjust capacity based on actual traffic patterns, leading to overprovisioning during off-peak hours and not specifically addressing latency during peak traffic.
★ When this WOULD be the correct answer
This would be correct if the question asked for a solution to improve performance for a consistently high-traffic application where the current instance type is underpowered, and cost is not a primary concern.
Why candidates choose this
Candidates may think larger instances inherently reduce latency by providing more resources, overlooking that this approach wastes capacity during low traffic and doesn't adapt to variable demand.
✗Use scheduled scaling to add instances only during the business hours peak window.Wrong answer — click to see why▾
Why this is wrong here
Scheduled scaling adds instances only during a fixed time window, but peak traffic may vary day-to-day or occur outside business hours, leading to either underprovisioning or overprovisioning. It does not dynamically adapt to actual traffic patterns.
★ When this WOULD be the correct answer
If the question states that traffic spikes are predictable and occur at the same time every day (e.g., a known business hours peak), and the goal is to ensure capacity is ready exactly when needed without relying on dynamic scaling metrics, then scheduled scaling would be the best choice.
Why candidates choose this
Candidates may think scheduled scaling is a simple, cost-effective way to handle peak traffic, overlooking that it cannot adapt to variable or unexpected load, and that the question emphasizes 'without overprovisioning' which requires dynamic adjustment.
✗Replace the ALB with a Network Load Balancer to reduce request latency.Wrong answer — click to see why▾
Why this is wrong here
Replacing the ALB with a Network Load Balancer reduces latency at the network layer but does not address the root cause of latency during peak traffic, which is insufficient compute capacity. The question asks for a change to reduce latency without overprovisioning, and NLB does not affect the fleet's ability to handle request load.
★ When this WOULD be the correct answer
In a scenario where the application is latency-sensitive at the transport layer (e.g., for UDP traffic or extreme low-latency requirements) and the ALB's processing overhead is the bottleneck, replacing it with an NLB would be correct. The question would specify that compute capacity is adequate and the latency issue stems from the load balancer itself.
Why candidates choose this
Candidates may think that any latency reduction is beneficial and assume a faster load balancer directly solves peak traffic latency, overlooking that the real issue is insufficient instances to handle request volume.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 302-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 →
Same concept, more angles
1 more way this is tested on SAA-C03
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Based on the exhibit, which change best reduces latency during peak traffic without overprovisioning the fleet?
hard- A.Replace the instances with a larger instance family so each server has more headroom.
- ✓ B.Change the Auto Scaling policy to target tracking on ALB RequestCountPerTarget.
- C.Use scheduled scaling to add instances only during the business hours peak window.
- D.Replace the ALB with a Network Load Balancer to reduce request latency.
Why B: Using a target tracking scaling policy on ALB RequestCountPerTarget dynamically adjusts the fleet size based on the actual load per instance, ensuring that capacity scales with demand during peak traffic without manual intervention or overprovisioning. This approach directly addresses latency caused by high request rates per instance by maintaining a target request count, which reduces response time without adding unnecessary instances during off-peak periods.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 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 SAA-C03 exam.