A public portal sees weekday peaks and overnight quiet periods. Which mechanism adjusts EC2 capacity as load changes?
Select an answer to reveal the explanation.
Short Explanation
Busy mornings, sleepy nights—Auto Scaling adds and removes EC2 capacity so the portal flexes with load. That is elasticity in plain terms. Shield, SMS-only alarms, and Config are valuable tools, but they are not the capacity scaler.
Full Explanation
A public portal with weekday peaks and overnight quiet periods should use Amazon EC2 Auto Scaling to adjust EC2 capacity as load changes. Auto Scaling policies add or remove instances based on metrics, schedules, or predictive patterns so the city pays for fewer instances overnight while meeting daytime citizen demand. Elasticity for EC2 fleets is the core Auto Scaling value proposition at Cloud Practitioner level.
AWS Shield Advanced provides enhanced DDoS protections; it is not the primary instance scaler. CloudWatch Alarms can signal conditions and invoke actions, but “alarms that only send SMS and never act” do not themselves resize fleets—Auto Scaling (often triggered by alarms) performs the capacity change. AWS Config evaluates configuration compliance and does not resize instance counts as its purpose.
Exam caveat: Auto Scaling changes capacity; load balancers distribute traffic. They often work together but are not interchangeable. Shield and Config solve security/compliance problems, not fleet elasticity.
Operational check: attach an Auto Scaling group to the portal’s launch template across two AZs, scale on CPU or ALB request count, add a scheduled scale-down overnight, load-test weekday peaks, and review scaling activity history after the first month of production traffic.