Designing an error budget policy

WHAT THIS TESTS: Whether you understand that error budgets only work when backed by an explicit, pre-agreed policy with real consequences and a clear owner. The interviewer wants governance design, not just the concept of a budget.

A GOOD ANSWER COVERS: Start with the foundation: a clearly defined SLO (for example a target availability or latency over a rolling window) whose complement is the error budget. The policy then defines tiered responses tied to budget consumption. While budget is healthy, teams ship normally. As consumption crosses thresholds, reliability work is increasingly prioritized over features. When the budget is exhausted, a feature freeze takes effect: only reliability fixes, rollbacks, and changes that reduce risk ship until the service recovers. Crucially, define earn-back objectively, for example the service must run back under budget for a defined period and the postmortem or reliability action items must be completed. Name the enforcement authority and an exception path requiring senior sign-off, so the freeze is not silently waived. The policy must be agreed in advance by both SRE and product leadership.

COMMON WRONG ANSWERS: A toothless policy with no enforcement, vague triggers open to interpretation, or no earn-back path so teams feel permanently punished. Forgetting to specify who can grant exceptions invites the policy being bypassed under pressure.

LIKELY FOLLOW-UPS: What if a budget is exhausted by a single rare event rather than chronic unreliability? How do you handle a mandatory security fix during a freeze? How do you prevent gaming the SLO to inflate the budget?

ONE CONCRETE EXAMPLE: A service with a 99.9% monthly SLO burns its budget on day twenty due to repeated bad deploys. The policy auto-triggers a feature freeze; the team spends the remainder hardening deploys with canary analysis. They earn back shipping rights only after a full subsequent window under SLO plus completing the agreed action items.