An e-commerce site experiences a traffic surge every weekday at exactly 9:00 AM when employees log in. The team wants to proactively add EC2 instances before the surge begins, not after it's detected. Which Auto Scaling policy type is MOST appropriate?
- ATarget Tracking Scaling — reactively adds instances when a metric (e.g., CPU) breaches a target value.
- BStep Scaling — reactively scales based on CloudWatch alarm threshold breaches.
- CScheduled Scaling — proactively adjusts capacity at a specific date/time based on a known schedule.✓ Correct
- DSimple Scaling — reacts to a single CloudWatch alarm with a cooldown period between actions.
Scheduled Scaling allows you to set a minimum, maximum, or desired capacity at a specific time. It's ideal for predictable load patterns (business hours, end-of-month batch runs). Target Tracking, Step, and Simple Scaling are all reactive — they respond AFTER a metric breach, which means instances are added during the surge rather than before it.
A company wants to run custom validation scripts on new EC2 instances — installing software and running tests — before the instances begin receiving traffic from the load balancer. Which Auto Scaling feature pauses the instance in the launch process to allow this?
- AEC2 User Data — scripts run at instance boot but Auto Scaling doesn't wait for them to complete before registering.
- BAuto Scaling Lifecycle Hooks — pause instances in Pending:Wait state, allowing custom actions before the instance enters InService.✓ Correct
- CLaunch Template — defines instance configuration but doesn't control lifecycle timing.
- DInstance Refresh — used for rolling updates of existing instances, not for initialising new ones.
Lifecycle Hooks intercept the Auto Scaling launch or terminate process and hold the instance in a wait state (up to 48 hours). During this time, you can run scripts, install software, or run tests via SSM Run Command or EventBridge triggers. Once complete, send a CompleteLifecycleAction call to continue the process.
What does the Auto Scaling default termination policy consider FIRST when deciding which instance to terminate during a scale-in event?
- ATerminate the instance with the highest CPU utilisation.
- BTerminate the instance with the most remaining billing time in the current hour.
- CRebalance Availability Zones — select the AZ with the most instances, then apply the termination policy within that AZ.✓ Correct
- DTerminate the newest instance to preserve stable, long-running instances.
The default termination policy follows this order: (1) Select the AZ with the most instances; (2) within that AZ, find the instance using the oldest launch template/configuration; (3) if there's a tie, terminate the instance closest to the next billing hour. This keeps AZs balanced and prefers newer launch templates.
An Auto Scaling group uses a Target Tracking policy targeting 50% CPU utilisation. A traffic spike pushes CPU to 90%. New instances are launched. However, the instances take 10 minutes to boot and configure, causing brief under-capacity. Which feature reduces the impact of long instance boot times?
- AScheduled Scaling — only helps for known traffic patterns, not sudden spikes.
- BPredictive Scaling — forecasts future traffic but instances still take 10 minutes to boot.
- CWarm Pools — maintains a pool of pre-initialised, stopped instances that can be moved to InService in seconds.✓ Correct
- DInstance Refresh — for rolling replacements of existing instances during deployment updates.
Warm Pools allow you to pre-initialise instances in a stopped or running state. When Auto Scaling needs to scale out, it moves warmed instances from the pool to InService much faster than launching fresh instances. This significantly reduces the time to capacity and improves responsiveness to sudden traffic spikes.
A company wants to deploy new AMI changes to all running EC2 instances in an Auto Scaling group with minimal disruption, replacing instances gradually while maintaining availability. Which feature should they use?
- AScheduled Scaling — changes capacity on a schedule, not AMI configuration.
- BLifecycle Hooks — pause instances during launch/terminate, not for mass instance replacement.
- CAuto Scaling Policy update — changes scaling behaviour, not instance configuration.
- DInstance Refresh — performs a rolling replacement of all instances using the updated launch template while maintaining minimum healthy percentage.✓ Correct
Instance Refresh replaces running instances in batches using the new launch template. You configure MinHealthyPercentage (e.g., 80%) to maintain availability during the refresh. It integrates with ELB health checks and can be paused or cancelled. This avoids the manual process of terminating and relaunching instances manually.