A company has a production application that runs on large compute optimized Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are in an Amazon EC2 Auto Scaling group. The…

Question

Options

• ADeploy additional instances outside the Auto Scaling group. Create a new target group that
• BIncrease the maximum capacity of the Auto Scaling group. Change the instances to a burstable
• CIncrease the maximum capacity of the Auto Scaling group. Configure a scaling policy to add
• DIncrease the desired capacity of the Auto Scaling group. Configure a scaling policy to add

• A
  4% (1)
• B
  8% (2)
• C
  77% (20)
• D
  12% (3)

Explanation

Option C is correct because the Auto Scaling group's maximum capacity of 2 acts as a hard ceiling - even with a scaling policy, no new instances can launch until you raise that ceiling. Raising the maximum capacity and attaching a CPU-based scaling policy (e.g., target tracking at 60–70% CPU) gives the group both the permission and the trigger to scale out automatically during unpredictable peaks.

Option A is wrong because instances deployed outside the Auto Scaling group are unmanaged - they require manual intervention and don't automate anything.

Option B is wrong because burstable instance types (T-series) rely on CPU credits and are designed for intermittent workloads, not sustained 90%+ CPU loads; switching to them would make performance worse under consistent load.

Option D is wrong because increasing the desired capacity permanently raises the baseline (you always pay for those extra instances), whereas the problem is unpredictable peaks - you want dynamic scaling, not a fixed higher steady state.

Memory tip: Think of max as the ceiling and desired as the floor. If you only raise the floor (D), you overprovision constantly. If you raise the ceiling and automate (C), you scale only when needed - cost-effective and responsive.

No community discussion yet for this question.