How Should EC2 Auto Scaling Maintain 50% CPU Headroom and Daily Peaks?

SOA-C03 By islever Editorial Last updated

Implement scalability and elasticity.

Short answer

B Use an EC2 Auto Scaling target tracking policy at 50% CPU plus scheduled scaling to add capacity at 09:00 and scale in at 17:00.

Question

A CloudOps engineer is setting up a fleet of Amazon EC2 instances in an Auto Scaling group for an application. The fleet should have 50% CPU available at all times to accommodate bursts of traffic. The load will increase significantly between the hours of 09:00 and 17:00, 7 days a week.
How should the CloudOps engineer configure the scaling of the EC2 instances to meet these requirements?
  1. Create a target tracking scaling policy that runs when the CPU utilization is higher than 90%.
  2. Create a target tracking scaling policy that runs when the CPU utilization is higher than 50%. Create a scheduled scaling policy that ensures that the fleet is available at 09:00. Create a second scheduled scaling policy that scales in the fleet at 17:00. Correct Answer
  3. Set the Auto Scaling group to start with 2 instances by setting the desired instances, maximum instances, and minimum instances to 2. Create a scheduled scaling policy that ensures that the fleet is available at 09:00.
  4. Create a scheduled scaling policy that ensures that the fleet is available at 09:00. Create a second scheduled scaling policy that scales in the fleet at 17:00.

Key Takeaways

The exam is testing whether you can separate predictable daily load patterns from unpredictable bursts, and the trap is choosing scheduled-only scaling or a 90% CPU threshold that leaves too little headroom.

This question tests how to combine EC2 Auto Scaling target tracking with scheduled scaling for a workload that needs 50% CPU headroom and predictable 09:00–17:00 peaks. The correct configuration uses a 50% CPU target tracking policy plus scheduled scale-out at 09:00 and scale-in at 17:00.

Common mistake: The most common wrong answer is D: scheduled scaling alone handles the known 09:00–17:00 pattern but cannot react to unexpected traffic bursts that would consume the required 50% CPU headroom.

Expert Analysis

Why the Answer Is Correct

Option B combines the two controls the scenario requires. A target tracking policy with a 50% CPU target keeps average utilization near 50%, preserving the requested headroom for bursts. Scheduled scaling at 09:00 pre-provisions capacity before the predictable daily increase, and the 17:00 scheduled action scales the fleet back in after the peak. Together, the dynamic policy handles unexpected load while the schedules handle the known 09:00–17:00 pattern.

Why the Other Options Are Wrong

Option A sets target tracking at 90% CPU, which leaves only about 10% headroom and risks saturation during bursts. Option C fixes the Auto Scaling group at two instances by setting minimum, maximum, and desired to 2, so it cannot scale out at all, and it only adds a 09:00 schedule without a scale-in action. Option D uses only scheduled scaling, so it cannot respond to traffic spikes inside or outside the scheduled window. Option B is the only choice that preserves 50% CPU headroom and covers both predictable and unpredictable demand.

Community Comment Notes

Bad_Mat's comment supports option B and describes the intended design clearly: a target tracking policy set to 50% CPU utilization, a scheduled policy at 09:00 to scale up before the predictable load increase, and a second scheduled policy at 17:00 to scale in after peak hours. That matches the requirement to keep 50% CPU available at all times while aligning capacity with the daily traffic pattern. No learner comments argue for a different configuration or identify a conflicting constraint.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When a scenario gives both a utilization headroom requirement and a predictable time window, look for an answer that combines target tracking with scheduled scaling. Eliminate options that set the target too close to saturation or rely only on schedules, because they fail the burst-handling requirement.

Frequently Asked Questions

Why is a scheduled-only scaling policy insufficient for this EC2 fleet?

Scheduled scaling handles the predictable 09:00–17:00 load pattern but cannot react to unexpected bursts, so the fleet could lose its required 50% CPU headroom.

Why not set target tracking at 90% CPU instead of 50%?

A 90% target leaves only about 10% CPU headroom, which violates the requirement to keep 50% CPU available for bursts.

More SOA-C03 FAQ →

Discussion 1 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 1

  1. Bad_Mat 👍 1 Answered B
    B: Create a target tracking scaling policy set to 50% CPU utilization, add a scheduled scaling policy for 09:00 to scale up before predictable load increases, and add a second scheduled scaling policy for 17:00 to scale in after peak hours.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Resolving Private IPv4 Exhaustion in AWS VPCs

S-grade

How Do You Ramp ALB Traffic Gradually During EC2 Cache Warm-Up?

S-grade

Avoiding Permanent Credentials with AWS STS

S-grade

Automate EC2 Reboot with Systems Manager Maintenance Windows

S-grade

Practice All SOA-C03 Questions

Access 100 questions with complete answers and detailed explanations.

View Full SOA-C03 Practice Test →

← Back to SOA-C03 Study Guide