GCP Professional Cloud DevOps Engineer Practice Question 1: Error Budget Policy Exhaustion

The entire point of an error budget policy is that the decision is made *in advance*, in writing, by the people who will later be under pressure to argue about it. The policy states what happens when the budget is exhausted, typically a freeze on feature launches with engineering effort redirected to reliability work, and it is signed by product, development, and SRE leadership so that no single team can unilaterally overrule it during an incident's aftermath. A good policy also defines an escalation path for genuine exceptions (a regulatory deadline, a security fix), so the correct move is to follow the policy and escalate through it rather than around it.

Option A is exactly the failure mode the policy exists to prevent. Moving the target after missing it makes the SLO a description of whatever the service happened to do, not a commitment, and it destroys the budget's value as a neutral arbiter between velocity and reliability.

Option B is the same manoeuvre in different clothing. Stretching the compliance window dilutes a real, customer-visible outage until it no longer registers. Window length should be chosen for how the business reasons about reliability and then left alone; changing it retroactively is gaming the measurement.

Option D confuses alerting with policy. A burn-rate alert is a useful signal, but leaving the launch decision to whoever happens to be holding the pager reintroduces exactly the ad-hoc, authority-based negotiation that an error budget policy replaces, and the on-call engineer has neither the mandate nor the context to arbitrate product priorities.

Reference: Error Budget Policy (The Site Reliability Workbook)