Risky launch with a near-empty error budget?

WHAT THIS TESTS This advanced question checks whether you can act as an enabler who balances revenue opportunity against reliability using concrete architecture and process, rather than playing gatekeeper or rubber stamp. It also tests negotiation and risk-framing skills.

A GOOD ANSWER COVERS Reframe the goal as launching the feature while controlling its contribution to budget burn. Architecturally, gate it behind a feature flag so it can be disabled instantly, roll it out progressively to a small canary cohort first, and instrument it so its specific error rate and the live budget burn are visible. Tie rollout advancement to budget consumption: pause or auto-rollback if burn accelerates. Isolate the feature, for example a separate path, dependency, or circuit breaker, so its failure does not blow the whole service's SLO. On process, make the risk explicit: present leadership with the burn data and have them formally accept the residual risk, possibly authorizing borrowing against the next period's budget. Document the decision and the abort criteria in advance.

COMMON WRONG ANSWERS A flat refusal, positioning SRE as the team that blocks the business. The opposite, shipping with no canary, flag, or rollback because revenue trumps reliability. Failing to escalate the tradeoff to a decision owner. Ignoring blast-radius isolation so one feature can exhaust the entire budget.

LIKELY FOLLOW-UPS Who has the authority to accept the risk? What metrics define the abort threshold? How do you isolate the feature's budget impact technically? What if the canary already burns budget fast?

ONE CONCRETE EXAMPLE The feature ships behind a flag to one percent of users with its own latency and error monitoring and a circuit breaker that disables it if its error rate crosses a set bound. Leadership signs off on borrowing a defined slice of next quarter's budget. The canary stays healthy, so rollout widens in stages, each gated on burn staying within the approved slice, delivering the revenue feature without risking a full SLO breach.