Free SAA-C03 practice scenarios: EC2 Auto Scaling

The spike is time-based and predictable, so scheduled scaling adds capacity at a set time each weekday — ready before the load arrives rather than chasing it. Why not the others: target tracking is reactive, so it only scales after CPU has already climbed, leaving the 09:00 users on under-provisioned capacity for a few minutes. A single large instance pays for peak capacity 24 hours a day and has no resilience. Manual scaling is exactly the toil automation exists to remove. Known clock-time peaks call for scheduled scaling.

Target tracking takes a target value for a metric — here 50% average CPU — and adds or removes instances to hold it, the simplest expression of 'keep this metric at this level'. Why not the others: hourly scheduled actions cannot track a metric that moves unpredictably within the hour. Predictive scaling forecasts future load and is aimed at provisioning ahead of known cycles, more than this requirement asks. A fixed desired capacity does not scale at all. 'Hold a metric at a value' is the definition of target tracking.

Setting the group's health check type to ELB makes it honour the load balancer's health check, which probes the application, so an instance that hangs at the app layer is marked unhealthy and replaced automatically. Why not the others: the default EC2 status checks only verify that the instance and its host are reachable — they pass right through an application-level hang, which is the whole problem. A bigger instance does not detect or replace a hung one. Emailing an operator reintroduces manual intervention. Application-aware replacement means ELB health checks on the group.

An Auto Scaling group configured with subnets in several Availability Zones distributes instances across them and, if a zone fails, launches replacements in the healthy zones — the fleet survives the loss automatically. Why not the others: confining the group to one AZ means a single AZ failure takes the whole tier down. A single large instance is a single point of failure, and Multi-AZ standby is an RDS database feature, not an EC2 compute pattern. Snapshots restore data later; they do not keep a compute tier serving. Compute resilience is spreading the group across AZs.

Predictive scaling analyses historical load to forecast recurring demand and provisions capacity ahead of the predicted peak — exactly 'learn from history and get ahead of it'. Why not the others: target tracking is reactive and only responds once the metric moves. A single scheduled action handles one known time but does not learn a recurring pattern across weeks. Manual planning is the labour predictive scaling replaces. Forecasting recurring demand from history is predictive scaling.

A lifecycle hook puts a terminating instance into a wait state and holds it there until your automation drains connections or finishes jobs and signals completion — the clean way to avoid losing in-flight work on scale-in. Why not the others: termination protection stops an instance from being terminated at all, which would break scale-in entirely. A longer cooldown spaces out scaling actions but does not protect a specific instance that is being removed. A higher minimum keeps more instances running and raises cost without addressing the drain requirement. Graceful shutdown on scale-in is a lifecycle hook.