Knowledge check

Check your knowledge

Choose an answer to see why it is right or wrong.

JavaScript is off, so every explanation is shown at once.

1. 01A Tier-1 service targets 99.9% availability over a 30-day rolling window. What is its error budget, and what does that number mean operationally?

   • 0.1% of the window, about 43 minutes of allowed downtime - the currency the error-budget policy spends before it freezes feature velocity.Correct. Error budget = (1 - SLO) x valid events in the window; at 99.9% that is 0.1%, which the reliability standard's worked example puts at about 43 minutes over 30 days.
   • 99.9% of the window, because the budget is the SLO target itself, not its complement.Incorrect. The budget is the allowed unreliability, (1 - SLO), not the SLO target. Reporting the SLO itself as the budget inverts the math.
   • Zero, because a Tier-1 service is not allowed any downtime under the standard.Incorrect. The standard's whole thesis is that 100% is the wrong target - it is unaffordable and unnecessary. Every tier, including Tier-1, ships with a nonzero, computed budget.

2. 02Which SLI is the right basis for a service's SLO, per the reliability standard?

   • A user-facing SLI drawn from the critical user journey - the thing a customer would open a ticket about - not an infrastructure metric.Correct. The standard requires SLOs to be defined from user-facing SLIs on the critical journey; an infrastructure metric like CPU usage tells you nothing about whether a user succeeded.
   • CPU and memory utilization, since they are the earliest warning of a coming failure.Incorrect. Infrastructure metrics may be useful internal signals, but the standard is explicit that an SLI measured on infrastructure does not tell you whether a user succeeded, so it is not the SLO basis.
   • Whichever metric is easiest to instrument first, since any SLO is better than none.Incorrect. An SLO chosen for instrumentation convenience rather than the user's journey produces a number nobody can act on - the standard ties the SLO to the journey specifically so it operates as a real contract.

3. 03A service's monthly error budget is exhausted and burn is still climbing. Per the error-budget policy, what happens?

   • The service enters a feature freeze - only reliability fixes, rollbacks, and security/critical patches may deploy - and reliability work moves to the top of the backlog until the budget recovers.Correct. This is the governing rule of section 3: budget exhausted or projected to exhaust triggers a per-service freeze, enforced in the deployment pipeline, not by good intentions.
   • The whole estate freezes deployments until every service's budget is healthy again.Incorrect. The freeze is explicitly per-service - one service's blown budget does not freeze unrelated services.
   • Product can override the freeze at will, since the SLA is a product-owned commitment.Incorrect. Product owns the SLA but does not get to override a freeze by fiat - overriding the policy is itself a logged, RFC-class decision with an accountable approver.

4. 04What operating practice does the error budget's freeze policy sit alongside, according to the standard's on-call and toil rules?

   • A sustainable primary/secondary on-call rotation scoped to user-facing SLO symptoms, plus a toil cap of about 50% with a rule-of-three that turns repeated manual work into automation.Correct. Section 4 requires a bounded, humane on-call rotation paging only on SLO symptoms, and section 5 caps toil at ~50% of reliability time, converting a third manual repeat into an automation ticket or runbook.
   • A single on-call engineer who owns the pager permanently, since consistency reduces incident response time.Incorrect. A pool of one is explicitly called out as a standing incident to escalate, not an acceptable rotation - the standard requires at least two people in the pool with a primary and secondary.
   • Paging on any infrastructure anomaly, so nothing goes unnoticed even if it isn't in a user's SLO.Incorrect. The anti-fatigue rule forbids paging on a metric that is not in a user's SLO; cause-based anomalies are tickets or dashboards unless they themselves burn the budget.