A city’s citizen portal Auto Scaling group currently registers targets in only one Availability Zone behind an Application Load Balancer. Leadership wants production-grade high availability. What should the architect change?
Select an answer to reveal the explanation.
Short Explanation
One AZ behind a load balancer is still a single neighborhood going dark. Spread the ASG across two or more AZs so the ALB has healthy targets when one zone hiccups. Bigger boxes in one zone do not buy AZ isolation.
Full Explanation
A citizen portal Auto Scaling group that registers targets in only one Availability Zone behind an Application Load Balancer is not production-grade high availability, even if the ALB itself is multi-AZ capable. The architect should spread the Auto Scaling group across at least two Availability Zones and keep the ALB multi-AZ so healthy targets remain available when one zone is impaired. Multi-AZ capacity is the core SAA-C03 pattern for compute tiers that serve municipal public traffic: lose an AZ, keep serving from another.
Pinning the target group to a single AZ and increasing instance size in that AZ only fails because larger instances in one neighborhood do not protect against AZ failure. Replacing the load balancer with a single EC2 reverse proxy in the same AZ fails by introducing a worse single point of failure and discarding managed multi-AZ load balancing. Disabling Auto Scaling health checks so failed instances remain in the one-AZ pool longer fails because it preserves unhealthy capacity instead of healing and does nothing to add a second AZ.
Exam caveat: spreading the ASG across AZs requires subnet capacity, balanced desired counts, and ALB target registration in those AZs—drawing two AZs on a diagram without placing instances there does not create HA. Operational check: confirm the ASG has subnets in two or more AZs, verify the ALB shows healthy targets in multiple AZs, and run an AZ-impairment game day to prove the portal continues serving citizens.