Operators need early warning that the city’s multi-AZ web tier is degrading. Which HA operations approach fits?
Select an answer to reveal the explanation.
Short Explanation
If the ALB is coughing up 5xx or targets go unhealthy, that’s your early smoke alarm—watch those metrics, not the town Twitter feed.
Full Explanation
Creating CloudWatch alarms on ALB 5xx errors and unhealthy host counts gives operators early warning that a city’s multi-AZ web tier is degrading. Those metrics work because they sit on the citizen request path: rising ELB 5XX and UnHealthyHostCount (or equivalent target-health signals) indicate the load balancer cannot get successful responses from enough healthy targets, which is exactly the HA symptom operators need before a full outage ticket storm. Alarms can page on-call, trigger Auto Scaling or runbooks, and provide objective evidence during AZ or deployment incidents. For municipal operations, instrumenting the ALB is more actionable than ambient guesses about “the website feeling slow.”
Disabling CloudWatch metrics to reduce cost and relying on citizen tweets as the sole health signal fails by concept because social media is lagging, biased, and not a controlled SLO signal for HA operations. Alarming only on S3 bucket size growth with no ALB or target health metrics fails because object-store growth does not explain web-tier request failures or unhealthy targets. Monitoring only bastion host CPU and ignoring load balancer target health fails because bastion utilization is orthogonal to whether citizen-facing targets behind the ALB are failing health checks.
Exam caveat: alarm thresholds need baselines—too low and you page on blips; too high and you learn about outages from the mayor’s office first. Operational check: enable ALB request and target metrics, set alarms on 5xx rate and unhealthy hosts with sensible periods, route notifications to the civic on-call channel, and validate by failing a target group member in a non-prod drill.