SAA-C03 Design High-Performing Architectures Practice Question

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 fixed size Auto Scaling group at maximum capacity.

  Why it's wrong here

  Maintaining a fixed size at maximum capacity ensures performance but is highly cost-inefficient. It wastes resources during off-peak hours and does not scale dynamically to meet unexpected traffic surges. This approach ignores the cost-saving benefits of cloud elasticity and is generally not recommended for variable production workloads.

• ✓

  Implement Auto Scaling with target tracking policies.

  Why this is correct

  Target tracking scaling policies allow the architecture to maintain a specific metric, such as average CPU utilization, across a fleet. This ensures that the application always has enough compute power to handle load spikes while reducing the instance count when demand drops, achieving both performance and cost-efficiency.

• ✗

  Configure the ALB to handle all scaling automatically.

  Why it's wrong here

  An Application Load Balancer manages the distribution of traffic among instances, but it does not control the scaling of the instances themselves. While the ALB itself is highly scalable, the underlying EC2 instances require an Auto Scaling group to handle changes in compute capacity based on demand.

• ✗

  Use reserved instances to handle all peak traffic.

  Why it's wrong here

  Reserved Instances offer significant cost savings, but they commit you to a specific instance count. If you reserve capacity for peak traffic, you pay for unused resources during low-traffic periods. Auto Scaling is required to adjust the actual fleet size in response to real-time traffic fluctuations.