Tax-portal reliability is within its monthly error budget, so product asks to ship a new filing feature this week. What service-level thinking supports that decision?
Select an answer to reveal the explanation.
Short Explanation
An error budget gives you room to ship while reliability remains within the SLO, so you can balance feature velocity with reliability risk. Freezing for one flaky check, letting marketing alone decide, or treating every SLO miss as an automatic vendor lawsuit misses that balance.
Full Explanation
Error budgets quantify how much unreliability you can “spend” while still meeting an SLO, allowing you to balance feature velocity against reliability risk. Because the tax portal is within its monthly error budget, using the remaining allowance to ship the new filing feature this week is the service-level thinking that supports the decision. Always freezing features after any single synthetic check flakes treats a possibly isolated check failure as proof the budget is exhausted, stalling delivery without considering measured SLO performance. Treating the error budget as irrelevant and letting marketing timing alone determine releases ignores reliability measurement and accountability to the tax-filing public. Treating every SLO miss as an automatic SLA vendor lawsuit confuses internal objectives with external contracts and assumes a legal consequence that may not apply. The budget supports a deliberate tradeoff, not a promise that every release is safe or that reliability can be ignored. Exam caveat: remaining budget is not permission to skip tests or bypass normal approvals, especially for a tax portal holding citizen financial data. Practical check: review the portal’s monthly error-budget burn, confirm headroom remains, and ship through the normal pipeline; heighten scrutiny or freeze releases if burn accelerates after deployment.