SRE Culture, Principles, and Antipatterns
SRE is an engineering discipline applied to operations problems. The foundational principles a candidate must be able to name and reason about are: embracing risk rather than pursuing 100% availability; defining reliability through service level objectives backed by error budgets; eliminating toil through automation; measuring systems rather than eyeballing them; automating away repetitive work; release engineering as a first-class practice; and simplicity as a reliability feature (fewer moving parts, fewer failure modes). Blameless postmortems and a shared, consequence-bearing error budget policy bind these together into a control loop: when the budget burns, feature velocity pauses until reliability work restores headroom.
The traps in exam questions cluster around a few misreadings. "100% reliability" is never the right answer; the right answer is the smallest reliability that satisfies users at acceptable cost. Toil is not "any operational work" - it is manual, repetitive, automatable, tactical, devoid of enduring value, and scales linearly with service growth. Paging humans for symptoms that have no action is an antipattern; so is treating SRE as a ticket queue ("human ops"), renaming an ops team to SRE without changing the work, or running SLOs with no agreed consequence when they are breached. Postmortems that end with "engineer error" are blame-flavoured and will recur; the productive conclusion is which systemic guardrail was missing.
Rule of thumb: if an error budget is never spent, the SLO is too loose; if it is always exhausted, either the service is not reliable enough or the target is unrealistic - both cases argue for changing the number or the architecture, not for ignoring the budget. As a worked example, a service with a 99.9% SLO over 30 days has 43 minutes of budget; three successive user-visible outages of 20 minutes each exhaust it and should automatically trigger the budget policy (release freeze, reliability sprint).