SOA-C02 Scheduled scaling Practice Question

A company runs a web application on Amazon EC2 instances that are part of an Auto Scaling group. The application's traffic is predictable with regular peaks during business hours and low traffic at night. The SysOps administrator wants to optimize costs while ensuring that performance meets demand. The administrator also needs to minimize manual intervention. Which scaling policy should be used?

⚠ Common exam trap

Many exam-takers confuse target tracking scaling with scheduled scaling, assuming dynamic metric-based policies are always optimal, but for predictable patterns, scheduled scaling provides more precise cost control and avoids unnecessary scaling events.

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

✓

Scheduled scaling

Scheduled scaling is the correct choice because the traffic pattern is predictable with regular peaks during business hours and low traffic at night. This policy allows the administrator to define specific times to increase or decrease the desired capacity of the Auto Scaling group, matching capacity to demand without manual intervention and optimizing costs by reducing instances during off-peak hours.

Answer analysis

Option-by-option breakdown

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

✓
Scheduled scaling
Why this is correct
Scheduled scaling allows you to define a recurring or one-time schedule to adjust the desired capacity of an Auto Scaling group at a future time. Because the company's workload follows a predictable pattern (e.g., a morning peak), scheduled scaling can proactively add EC2 instances before the traffic arrives, eliminating the lag inherent in reactive methods. After the initial configuration, it runs automatically without manual intervention, making it the most efficient choice for a known, consistent demand curve.
✗
Target tracking scaling
Why it's wrong here
Target tracking scaling adjusts capacity based on a real-time metric such as CPU utilization or request count per instance, attempting to maintain the metric near a target value. However, it is inherently reactive—it only increases capacity after the observed load has already pushed the metric above the threshold. For a sharp morning peak, this means instances are launched only as traffic spikes, potentially causing latency for users during the delay, whereas scheduled scaling would have already prepared the fleet.
✗
Simple scaling
Why it's wrong here
Simple scaling relies on CloudWatch alarms that trigger when a metric breaches a threshold; however, it is asynchronous and includes mandatory cool-down periods during which no further scaling actions are executed. This makes it slow to respond to rapid changes, and it may repeatedly add or remove instances in steps, which is inefficient for a steep, predictable increase in traffic. Unlike scheduled scaling, simple scaling does not anticipate the morning peak, so it risks under-provisioning exactly when demand ramps up.
✗
Manual scaling
Why it's wrong here
Manual scaling requires an administrator to explicitly update the desired capacity of the Auto Scaling group through the console, CLI, or API every time the load pattern changes. This is not automated and is prone to human error; if an administrator forgets to scale up ahead of the morning peak, the web application will experience capacity shortages and degraded performance. Scheduled scaling, in contrast, eliminates the need for constant human oversight by predefining the scaling events, ensuring the application is always ready for the expected surge.

Go deeper

SOA-C02 Scheduled scaling Practice Question

Why each option matters

Option-by-option breakdown

Related to this question