Reliability and Business Continuity practice questions

Step scaling sizes the capacity adjustment to how far the metric breached the alarm threshold, using step adjustments you define.

Only step scaling lets you say 'a small breach adds one instance, a large breach adds four' — the adjustment scales with breach magnitude. Target tracking holds one value and hides its alarms; simple scaling makes exactly one fixed adjustment per cooldown; scheduled scaling ignores metrics entirely.

1. Identify the requirement: different response sizes at different severity levels of the same metric.
2. Create a CloudWatch alarm on average CPU for the Auto Scaling group.
3. Attach a step scaling policy with step adjustments: +1 instance for the 70–90% band, +4 instances above 90%.
4. Configure instance warmup so newly launched instances are counted correctly during multi-step responses.

Exam tip: Tiered responses sized to breach severity are the signature use case for step scaling.

Scheduled scaling changes an Auto Scaling group's min, desired, and max capacity at specific times or on a recurring schedule, which suits predictable demand cycles.

The load pattern is known and repeats every business day, so capacity should be provisioned ahead of time rather than in reaction to a breaching metric. Reactive policies (simple, step, target tracking) all launch after load has risen; raising the max alone launches nothing; the grace period is a health-evaluation setting, not a capacity trigger.

1. Confirm the demand pattern is time-driven and recurring, not random.
2. Create a recurring scheduled action that raises min and desired capacity shortly before 9:00 AM on weekdays.
3. Create a second recurring action that lowers capacity after 6:00 PM.
4. Optionally keep a target tracking policy alongside for unexpected intraday spikes.

Exam tip: Predictable, clock-driven demand cycles are the trigger phrase for scheduled scaling — provision before the surge, not after.

Predictive scaling forecasts load from historical patterns with machine learning and launches capacity before the demand arrives.

The scenario combines the two cues for predictive scaling: a recurring pattern (so the forecast has something to learn) and long instance lead time (so reactive launches arrive too late). All three reactive policies — target tracking, step, and simple — only act after the metric has moved, which is precisely the failure being described.

1. Recognize the two cues: recurring demand pattern plus long instance startup lead time.
2. Enable predictive scaling on the Auto Scaling group so it learns the historical load curve.
3. Keep a target tracking policy alongside to absorb deviations from the forecast.
4. Validate that instances launched by the forecast are in service before the daily peak.

Exam tip: Recurring patterns plus instances that need lead time to be ready point to predictive scaling.

When an alarm breaches but no instances launch, either the group has no headroom (desired already equals max) or launches are being attempted and failing — and the activity history records both.

Reading the activity history and comparing desired to max covers the main causes in one check: capacity stuck at max, failed launches from an EC2 instance quota, an instance type unavailable in an AZ, a deleted launch-template AMI, or a suspended Launch process. Grace period and deregistration delay affect health evaluation and connection draining respectively, not launches; launch configurations are legacy and irrelevant here.

1. Open the Auto Scaling group's activity history and look for failed or absent scaling activities.
2. Compare desired capacity to maximum — if they are equal, raise the maximum if the load is legitimate.
3. If activities show launch failures, act on the stated reason: quota increase, alternate instance type or AZ, or a valid AMI.
4. Check the suspended-processes list — a suspended Launch process silently stops all launches.

Exam tip: Alarm in breach with nothing launching → read the activity history first, and check whether desired already equals max.

The health-check grace period gives a newly launched instance time to boot and start its application before the Auto Scaling group begins evaluating its health.

Instances dying at ~90 seconds while the app needs three minutes is the textbook symptom of a grace period shorter than real startup time: the group evaluates health mid-boot, sees failures, and terminates. Raising the target group's unhealthy threshold nibbles at the symptom but the grace period is the purpose-built control; scale-in protection covers scale-in selection, not health replacement; faster probing accelerates the false failures.

1. Measure the application's true startup time from instance launch to serving traffic.
2. Set the Auto Scaling group's health-check grace period comfortably above that time.
3. Confirm new launches now survive and enter service.
4. Distinguish this from instance warmup, which controls when a new instance's metrics join the group aggregate.

Exam tip: New instances terminated before the app boots → the health-check grace period is shorter than real startup time.

Scale-in protection — settable on the group or per instance — excludes instances from being selected for termination when the Auto Scaling group scales in.

The requirement is that instances doing long-running work must never be chosen at scale-in, which is exactly what per-instance scale-in protection provides. A Terminating:Wait lifecycle hook is the tempting distractor: it delays a termination already in motion and expires on a timeout, so a two-hour job still loses. Termination policies reorder selection without protecting busy instances, and cooldown only spaces out scale-in events.

1. Have the worker set instance scale-in protection when it picks up a job.
2. Have it clear the protection when the job completes, making the instance eligible again.
3. Keep the scale-in policy as is — idle instances are still terminated normally.
4. Optionally add a Terminating:Wait hook for graceful cleanup of the instances that are selected.

Exam tip: Long-running work surviving scale-in is the use case for instance scale-in protection, not lifecycle hooks.