SRE Foundation common mistakes
SRE Foundation · Understand the traps and how to avoid them.
Choosing 100% (or effectively 99.999%) availability targets for every service, then treating any consumed error budget as evidence the team failed.
Candidates carry over an instinct that 'more nines is always better' and never internalise that an SLO is a deliberately chosen risk threshold; the exam's framing of SLOs as a risk-management tool contradicts that instinct.
What to do instead
State explicitly that an SLO is a target below 100% justified by user expectations and cost, and that the error budget is a spendable resource. Practise writing one sentence per service: 'SLI = proportion of valid requests served under 300 ms; SLO = 99.9% over 28 days; budget = 0.1%.'
Describing SRE as 'operations with a new name', as a tool or product, or as an approach whose goal is to eliminate all manual work and reach fully autonomous operations.
Vendor marketing and job titles blur the definition; candidates latch on to the most visible artefacts (dashboards, automation) instead of the underlying discipline.
What to do instead
Anchor on the textbook definition: applying software engineering to operations problems, with explicit risk acceptance, a toil ceiling (commonly 50%), and shared ownership with development. When a stem mentions automation, ask whether it is the means or the goal.
Mixing up the three standard metric frameworks - attributing 'saturation' to RED, 'duration' to the four golden signals, or listing USE as latency/traffic/errors/saturation.
All three are short lists of English nouns learned by rote; without their scope (user-facing request vs resource) they collapse into one another under exam pressure.
What to do instead
Memorise by scope, not by order: golden signals (latency, traffic, errors, saturation) for user-facing systems; RED (rate, errors, duration) for request-driven services; USE (utilisation, saturation, errors) for resources. Write each set out from memory and label which noun belongs to a request and which to a machine.
Classifying every repetitive or manual activity as toil, including one-off analyses, work that improves the system long-term, or tasks that already run from a mature runbook.
The word 'toil' sounds like plain English 'boring work', so candidates apply the lay meaning and skip the multi-criteria definition.
What to do instead
Test each example against all criteria: manual, repetitive, automatable, tactical, no enduring value, and scaling linearly with service growth. If one criterion clearly fails (e.g. it is a one-off capacity study), it is not toil. Also recall toil is measured as a share of time, not an all-or-nothing label.
Answering that a blameless postmortem should avoid naming the individual involved, or conversely that 'blameless' means no accountability, no root-cause detail and no action items.
Two opposite folk readings circulate: one equates blameless with secrecy, the other with leniency; neither matches the practice of documenting the timeline and system conditions fully while removing punishment.
What to do instead
Separate the two axes: the narrative is fully detailed and names contributing system factors and human actions, while the response is non-punitive and focused on systemic fixes. Actions get owners and due dates; the document is shared, not buried.
Assuming any automation effort reduces toil and pays for itself, or that teams should build their own tooling rather than adopt existing tools.
Automation is presented in the syllabus as the cure for toil, so candidates miss the maintenance cost, and engineering pride biases answers toward bespoke solutions.
What to do instead
Evaluate automation on net time saved versus build plus ongoing maintenance, and prefer off-the-shelf or existing tooling before writing new code. Prioritise high-frequency, low-risk, well-understood tasks, and remember automation can itself create toil if it is fragile or undocumented.
Placing SLO definition and the error-budget policy solely with the SRE team, or positioning SRE as a gatekeeper that approves every production change.
SRE is taught as a specialist team, so candidates model it like a classical ops silo and overlook the negotiation with product owners and the need for management sign-off.
What to do instead
SLOs are agreed between service owners, product/business stakeholders and SRE, and the error-budget policy is ratified by leadership before it is needed. SRE enables through embedded or consulting engagement, self-service platforms and shared on-call, not through change approval queues.
Presenting SRE and DevOps as competing frameworks where an organisation must pick one, or claiming SRE abolishes ITIL practices such as incident, problem and change management.
Exam questions about 'other frameworks' invite contrast, and candidates answer with contrast instead of the intended relationship of implementation and overlap.
What to do instead
State the accepted framing that SRE is a concrete implementation of DevOps principles, and map overlaps explicitly: incident and problem management map to incident response and postmortems; change management maps to progressive delivery and release engineering; Lean concepts map to toil reduction and flow.
Predicting that AIOps, self-healing platforms or platform engineering will remove the need for SRE judgement, SLOs, or human on-call, i.e. picking a 'no-ops' answer for future-facing questions.
Hype around automation makes elimination narratives feel like the modern answer, while the syllabus treats new technology as changing the shape of the work rather than deleting the discipline.
What to do instead
Frame each future trend as a shift in where engineering effort goes: automation absorbs routine detection and remediation, while target-setting, risk decisions, system design and post-incident learning stay human. Choose answers that augment SRE practice rather than abolish it.
Treating the error budget as a reporting metric with no operational consequence, or overcorrecting by saying a team must halt all releases permanently once the budget is exhausted.
Budgets are usually introduced with dashboards and burn-rate maths, and the policy half - the pre-agreed consequence - is skimmed or reduced to a single dramatic rule.
What to do instead
Describe the error-budget policy as pre-agreed, time-bound consequences: prioritise reliability work, freeze non-essential feature launches while allowing critical fixes and security patches, with named exceptions and escalation. The budget recovers as the SLO window rolls forward.