SOA-C02 Cost and Performance Optimization Practice Question

An EC2 Auto Scaling group runs a stateless web application with predictable daily peaks. Which two actions can reduce cost while preserving capacity during peak periods? (Choose 2.)

⚠ Common exam trap

Candidates often think disabling health checks saves money by avoiding instance replacements, but this actually risks application availability and can increase costs due to undetected failures, while the real cost-saving mechanisms are proactive scaling and using cheaper instance types like Spot.

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

✓

Configure scheduled scaling actions for the known peak window.

Scheduled scaling allows you to proactively increase capacity before the predictable daily peak and reduce it afterward, ensuring you only pay for the resources needed during the peak window. This avoids over-provisioning for the entire day, directly reducing costs while maintaining performance during high-demand periods.

Answer analysis

Option-by-option breakdown

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

✓
Configure scheduled scaling actions for the known peak window.
Why this is correct
Scheduled scaling actions are the correct approach for a workload with a known, predictable peak window because they proactively adjust the Auto Scaling group's desired capacity at the specified times, launching instances before traffic increases. This eliminates the delay that dynamic scaling can incur while waiting for metrics like CPU utilization to cross thresholds, ensuring capacity is available exactly when the peak begins. It also lets you scale back down after the window to avoid paying for idle resources.
✓
Use a mixed instances policy with some Spot capacity where interruption is acceptable.
Why this is correct
A mixed instances policy can reduce cost for a stateless, fault-tolerant web application by including Spot Instances, which are significantly cheaper than On-Demand and can be interrupted with a two-minute notice. Because the app is stateless and can tolerate individual instance replacement, the risk of Spot interruption is manageable, and the Auto Scaling group can maintain overall capacity by balancing On-Demand and Spot across instance types. This complements scheduled scaling by addressing cost efficiency around the peak, not the timing of the peak.
✗
Run all instances as On-Demand at maximum peak size all day.
Why it's wrong here
Running all instances as On-Demand at maximum peak size all day means the Auto Scaling group never scales down, so you pay for peak capacity even during low-traffic periods. While this guarantees that there is always enough capacity to handle the peak, it directly contradicts the cost-optimization goal of Auto Scaling, which is to match capacity to actual demand. The resulting waste can be substantial if the peak window is only a few hours, making this approach financially inefficient.
✗
Disable health checks to avoid instance replacement.
Why it's wrong here
Disabling health checks prevents the Auto Scaling group from detecting and replacing unhealthy instances, which would leave failed instances serving traffic and degrade application availability. Health checks are fundamental to Auto Scaling's self-healing behavior; without them, the group cannot respond to instance failures or ELB unhealthy status, and this is especially risky for a web application where high availability is expected. Even if the goal is to reduce replacements during a peak, this approach sacrifices reliability without solving the cost or capacity planning problem.

Go deeper

SOA-C02 Cost and Performance Optimization Practice Question

Why each option matters

Option-by-option breakdown

Related to this question