SAP-C02 Design for New Solutions Practice Question

A company runs a stateless web tier on Amazon EC2 instances behind an Application Load Balancer. Traffic is highly variable, with sharp spikes during flash sales. The company wants the web tier to scale out quickly during spikes and scale in when demand drops, while keeping costs low. Which configuration should a solutions architect recommend?

⚠ Common exam trap

The trap here is choosing scheduled or fixed-capacity scaling, which cannot respond to the unpredictable timing of flash-sale spikes.

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

✓

Use an Auto Scaling group with a target tracking scaling policy based on average CPU utilization, and enable the Application Load Balancer health checks.

Variable demand with sharp spikes and a desire for low cost calls for dynamic scaling that follows actual load. Target tracking on average CPU utilization adjusts capacity automatically as utilization moves, adding instances during flash sales and removing them afterward, while ALB health checks keep traffic on healthy targets.

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 an Auto Scaling group with a target tracking scaling policy based on average CPU utilization, and enable the Application Load Balancer health checks.
Why this is correct
Target tracking scales the fleet automatically to hold average CPU utilization near a target value, adding instances quickly during flash sales and removing them as demand falls. ALB health checks ensure traffic only reaches healthy instances, so the design responds to variable load while controlling cost, which matches the stated requirements.
✗
Use an Auto Scaling group with a simple scaling policy and a cooldown period of 600 seconds.
Why it's wrong here
Simple scaling with a long cooldown blocks further scaling actions until the cooldown expires, so the fleet cannot add capacity quickly during a sharp spike. The 600-second cooldown delays subsequent adjustments and can leave the application under-provisioned during rapid traffic growth, defeating the goal of fast scale-out.
✗
Use a larger fixed fleet of EC2 instances sized to handle peak flash-sale traffic at all times, behind the Application Load Balancer.
Why it's wrong here
A fixed fleet sized for peak demand runs at that cost continuously, even when traffic is low, which contradicts the requirement to keep costs low. It also cannot adapt if peak demand grows beyond the provisioned size, and it wastes capacity during the long periods between flash sales.
✗
Use an Auto Scaling group with a scheduled scaling policy that adds instances every day at a fixed hour.
Why it's wrong here
Scheduled scaling changes capacity at predetermined times, so it cannot react to unpredictable flash-sale spikes that occur outside the schedule. During an unexpected surge the fleet would be under-provisioned, and during quiet periods the schedule may keep excess instances running, raising cost without matching demand.

Go deeper

SAP-C02 Design for New Solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question