Error Budget Exhausted: Should You Deploy an Urgent Customer Feature?

PCDOE By islever Editorial Last updated

Balancing change, velocity, and reliability of the service.

Short answer

A Delay the urgent customer feature release until the exhausted error budget is replenished and the production deployment freeze is lifted.

Question

You manage your company’s primary revenue-generating application. You have an error budget policy in place that freezes production deployments when the application is close to breaching its SLO. A number of issues have recently occurred, and the application has exhausted its error budget. You need to deploy a new release to the application that includes a feature urgently required by your largest customer. You have been told that the release has passed all unit tests. What should you do?
  1. Delay the deployment of the feature until the error budget is replenished. Correct Answer
  2. Re-run the unit tests, and start the deployment of the feature if the tests pass.
  3. Start the deployment of the feature immediately.
  4. Deploy the feature to a subset of users, and gradually roll out to all users if there are no errors reported.

Key Takeaways

It tests whether you treat the error budget policy as a binding deployment gate rather than letting customer urgency or passing unit tests override it.

This PCDOE scenario tests whether an exhausted SRE error budget overrides business urgency. The correct action is to delay the urgent feature deployment (A) until the error budget is replenished and the freeze is lifted.

Common mistake: D is tempting because a gradual rollout limits blast radius, but it still deploys during a policy freeze and creates no documented exception; canarying cannot substitute for restoring the error budget.

Expert Analysis

The error budget policy is the controlling constraint

The application has exhausted its error budget, and the stated policy freezes production deployments when the service is close to breaching its SLO. That makes the freeze the governing rule for this release. The fact that the feature is urgently required by the largest customer is business pressure, not a policy exception. The fact that the release passed unit tests only shows that some code-level checks succeeded; it says nothing about whether the change will consume more error budget or whether the service can safely accept it while already out of budget. Option A—delay the deployment until the error budget is replenished—is the action consistent with the policy.

Why the other options fail

Option C deploys immediately and directly violates the freeze. Option B reruns the same unit tests and then deploys if they pass; that does not change the SLO position, restore the error budget, or satisfy the policy gate. Option D is more sophisticated because a subset rollout or canary can limit blast radius, and that is why it is tempting. Some discussion of this question treats a "business critical release" as a case for an exception with risk mitigation, making D look operationally safer. The stronger reading, however, is that the policy says deployments are frozen unless an exception is explicitly defined and approved; nothing in the stem provides one. A gradual rollout is still a production deployment and would let urgency override the error budget.

Adjacent knowledge and what would change the decision

This question tests the boundary between change velocity and reliability. Related decisions include how an error budget policy defines freezes, who can approve exceptions, and whether a release is a reliability-restoring fix rather than a new feature. If the scenario changed to a critical security fix, or stated that an executive exception had been approved, a canary or phased rollout could become defensible. The operational consequence of choosing D or C here is that the error budget becomes advisory: teams learn to bypass the freeze under customer pressure, incidents are more likely while the service is already unreliable, and the SLO loses credibility with stakeholders. The safe exam answer is A.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When a PCDOE question mentions an error budget policy, read the policy as the governing rule and separate it from release mechanics. Passing unit tests, customer pressure, and canary options are distractors unless the stem describes an approved exception or a reliability-restoring fix. Ask whether the proposed action is allowed under the freeze before evaluating rollout quality.

Frequently Asked Questions

Does an urgent feature for the largest customer justify an exception to an exhausted error budget?

Only if the error budget policy defines and approves an exception. The scenario provides no such exception, so the production deployment freeze still applies and the release should be delayed until the budget is replenished.

Why isn't a canary rollout to a subset of users acceptable here?

A canary reduces blast radius but is still a production deployment prohibited by the freeze. It does not address the exhausted error budget, and gradual rollout would bypass the governance the policy is meant to enforce.

What would change the answer?

An explicit policy exception for a critical reliability or security fix, or a scenario stating the error budget has been replenished, could permit deployment. Without that, passing unit tests does not satisfy the SLO-based gate.

More PCDOE FAQ →

Community Votes

A
60%
D
40%

60% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 7 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 7

  1. lyona 👍 4 Answered D
    D - it's a business critical release. SRE best practices allow for exceptions to deployment freezes with risk mitigation. In this scenario a gradual rollout is the best course of action.
  2. maurer 👍 3 Answered D
    D. Deploy the feature to a subset of users, and gradually roll out to all users if there are no errors reported. Explanation: Since the error budget is exhausted, normal practice is to freeze production deployments to protect reliability. However, there is an urgent customer need for this new feature, so a controlled, gradual rollout (e.g., canary or phased deployment) is the safest way to proceed. This approach: Limits risk by exposing only a subset of users to the new release. Allows monitoring for new errors or performance issues during rollout. Enables quick rollback if issues are detected, minimizing impact on overall user base. This aligns with SRE principles balancing risk management and business needs.
  3. Caletrio 👍 2 Answered A
    ✅ Correct answer: A. Delay the deployment of the feature until the error budget is replenished. Why?: The policy explicitly states that production deployments are frozen when the error budget is depleted. Ignoring that rule would violate your reliability governance. Even though the new feature has passed unit tests, that only proves that the code compiles and basic functionality works — it says nothing about production reliability, latency, or user impact. The correct action is to stabilize the system first, fix the underlying issues, and wait for the error budget to recover before deploying anything new.
  4. gaurav517 👍 1 Answered D
    The situation presents a conflict between the SRE Error Budget Policy (which requires a freeze) and a critical business need (largest customer requires the feature now). The SRE best practice is to always operate within the framework of the error budget policy, but the policy must have an escalation path and a defined procedure for deploying critical fixes or urgent business features even when the budget is exhausted.
  5. BlackCoffee 👍 1 Answered A
    C and D are incorrect: Proceeding with the deployment immediately or trying a gradual rollout both violate the deployment freeze. Unless the release is a critical fix specifically intended to restore the system's reliability, no new feature work should be pushed into production until the system is stabilized.
Show 2 more comments
  1. BlackCoffee 👍 1
    That's true but only urgent critical fixes. Here they mention critical feature and not fix.
  2. a36df5b 👍 1 Answered A
    A. Delay the deployment of the feature until the error budget is replenished.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Mitigating Downstream Service Failures with Circuit Breakers

S-grade

Choosing a Latency SLO from Measured p90/p95 Performance

S-grade

SRE Postmortem Triggers: External Stakeholders and Data Loss

S-grade

Centralizing Production Folder Logs with an Aggregated Log Sink

S-grade

Practice All PCDOE Questions

Access 75 questions with complete answers and detailed explanations.

View Full PCDOE Practice Test →

← Back to PCDOE Study Guide