A municipality’s citizen portal ops team fights every alert with equal urgency and cannot decide which reliability work to fund next. What should leadership introduce to prioritize improvement work?
Select an answer to reveal the explanation.
Short Explanation
Without an error budget, every red light looks like a five-alarm fire and nobody knows which hose to grab. SLOs turn 'the portal should feel reliable' into a measurable allowance for failure. Burn the budget and reliability work jumps the queue; stay under and you can ship features without guilt.
Full Explanation
When a citizen portal ops team fights every alert with equal urgency, leadership cannot fund the right reliability work. Defining service-level objectives and error budgets for the portal ties remaining reliability investment to burned budget and user-facing risk instead of equal panic. That management system works because not all alerts imply equal citizen harm—error budgets quantify when to prioritize reliability over features. Disabling CloudWatch alarms and paging only when the mayor’s office calls fails by outsourcing detection to political escalation. Tracking raw EC2 CPU averages alone and treating any spike above 40% as Sev-1 regardless of user impact fails conceptually: infrastructure vanity thresholds are not SLOs. Prioritizing only cosmetic UI polish until infrastructure backlog expires fails to address reliability investment driven by user-facing risk. Exam caveat: SLOs need careful indicator choice (availability/latency of key journeys) and stakeholder agreement; overly tight objectives create permanent budget burn and alert fatigue. Operational check: pick two resident journeys, define SLIs/SLOs and a 30-day error budget, chart burn in CloudWatch, and use budget policy in the next sprint planning to sequence reliability work.