The SREF Concept Reference
The SRE Foundation exam gives you nothing to look up — no docs tab, no split screen, no man pages, just forty questions and sixty minutes with whatever's already in your head. This page is built for exactly that constraint. It isn't a tutorial to read once; it's a reference organized the way the exam is organized — by the eight SREF blueprint domains — with the pairs of terms that sound like synonyms but aren't pulled out and set side by side wherever the real syllabus puts them next to each other. SLA, SLO, and SLI look like one idea wearing three hats. Toil has a precise five-part definition, not a vibe. Robust and anti-fragile get used interchangeably outside this course, and on the SREF that substitution is a wrong answer. Read it once for structure, then come back and quiz yourself against the confusion table near the bottom until nothing on it makes you pause.
Imagine a vocabulary quiz where the hard part isn't the big scary words — it's two easy-looking words that mean almost the same thing but not quite. "Hot" and "warm" are both temperature words, and a quiz that only checks "do you know what a temperature word is" would never catch you swapping them. This page goes hunting specifically for SRE's "hot vs. warm" pairs — SLA vs. SLO, robust vs. anti-fragile, blameless vs. blame-aware — and makes you look at each pair side by side instead of trusting that reading each half separately, once, was enough.
The SRE Foundation is a multiple-choice, closed-book exam from the DevOps Institute: 40 questions, 60 minutes, a 65% pass mark, and — unlike some vendor exams — no permitted reference material, no allowlisted docs site, nothing installed locally to fall back on. See the certifications page for the full logistics. That single fact is why this page exists in its current shape: there is no "look it up during the exam" recovery move available here, so every definition below has to already be load-bearing in your memory before you sit down, and every confusion has to be resolved now, not in the moment you're staring at a question that hinges on it.
Exam logistics — price, question count, pass mark, delivery method — move without much announcement and this page is a snapshot, not a live feed. Verify current logistics on the DevOps Institute's own SRE Foundation page before you book, and let that override anything written here.
How this page is organized
☺ Like you're 10: Same eight folders the real exam uses, plus a "these two look the same, they aren't" note stapled to the front of every folder that has one.
Everything below is grouped under the same eight domains the SREF blueprint itself uses, in the same order: Principles & Practices, SLOs & Error Budgets, Reducing Toil, Monitoring & SLIs, Tools & Automation, Anti-Fragility & Learning from Failure, Organizational Impact, and Frameworks & the Future. Each domain gets a short card for every concept worth knowing cold, and — where the real confusion lives — a highlighted box that puts two look-alike terms next to each other and says, plainly, what actually separates them. If you've already read the eight blueprint pages in full, this page is your compression pass: it deliberately strips out the worked examples and case studies those pages carry and keeps only the definitions and the distinctions, so a re-read here takes minutes, not hours.
Don't mistake recognizing a definition for owning it. Reading "SLI is a measurement, SLO is a target, SLA is a promise" and nodding is not the same skill as producing that sentence correctly under a 90-second-per-question clock with no cue that it's the thing being tested. Use the practice question bank and the flashcards to convert this page from something you recognize into something you can produce unaided — this page is the map, not the workout.
Domain 1 — SRE Principles & Practices
☺ Like you're 10: The starting philosophy — operations is a software problem, perfect reliability is the wrong goal, and "reliable" is a number you pick, not a feeling you hope for.
Full walkthrough: SRE Principles & Practices. This domain is the foundation the other seven sit on, and the exam tends to test it as recognition of the core stance rather than deep mechanics.
class SRE implements interface DevOps. Full treatment in What is SRE?Availability is one measurable dimension of reliability: the fraction of time or requests a service behaves correctly, usually written as a percentage of "nines." Reliability is the broader property — it also covers correctness, durability, and consistency, and a system can be highly available while still being unreliable in ways availability alone never catches, such as silently serving corrupted data at 100% uptime. Availability is the easiest reliability dimension to measure, which is exactly why exam questions like to test whether you'll conflate "measured" with "complete."
Domain 2 — Service Level Objectives & Error Budgets
☺ Like you're 10: Three letters that all start with "S," all mean something different, and the exam will absolutely make you tell them apart.
Full walkthrough: Service Level Objectives & Error Budgets. This is the SREF's densest domain and the one most worth over-preparing — its vocabulary also underpins burn-rate alerting and SLO windows if you want the deep-dive version later.
SLI is a measurement — a number you observed. SLO is a target — the number you've decided that measurement needs to clear internally. SLA is a promise — an external commitment, usually looser than the SLO on purpose, so there's margin between "we're worried" and "we're in breach." Read them in that order and the mnemonic writes itself: Indicator measures, Objective targets, Agreement promises. A single exam stem will often describe all three in one scenario and ask you to name which is which — the tell is always the audience: internal engineering number is the SLO, contractual customer-facing number is the SLA, raw measurement underneath both is the SLI.
The error budget is arithmetic: (1 − SLO) × total valid events, a single figure that shrinks every time the SLI misses. The error-budget policy isn't a number at all — it's the governance document that says what happens when that figure hits zero. A service can have a perfectly calculated error budget and no policy behind it, which in practice means: when the budget's exhausted, nothing happens, because nobody agreed in advance what should. On the exam, "the error budget is exhausted" describes a state; "the error-budget policy" describes the response to that state — don't answer a question about one with a definition of the other.
| SLO | Allowed downtime / year | Allowed downtime / 30 days |
|---|---|---|
| 99% ("two nines") | ~3.65 days | ~7.3 hours |
| 99.9% ("three nines") | ~8.76 hours | ~43 minutes |
| 99.95% | ~4.4 hours | ~22 minutes |
| 99.99% ("four nines") | ~52.6 minutes | ~4.3 minutes |
| 99.999% ("five nines") | ~5.3 minutes | ~26 seconds |
Worked arithmetic, the way a question is likely to stage it: an SLO of 99.9% measured over a rolling 28-day window. The window is 40,320 minutes long. The error budget is (1 − 0.999) × 40,320 ≈ 40.3 minutes of allowed unavailability for the entire 28 days — spend it in one bad afternoon and, if the error-budget policy says so, every release freezes until the rolling window moves forward and the budget refills. Every SLO-math question on this exam reduces to some version of that one multiplication; the number changes, the shape never does.
Domain 3 — Reducing Toil
☺ Like you're 10: Not "boring work" in general — a specific five-part checklist, and a task only counts as toil if it clears all five.
Full walkthrough: Reducing Toil. Toil is the SREF's other favorite trap domain, because "toil" gets used loosely in everyday speech to mean any tedious work — the exam wants the precise definition, not the vibe.
- Manual — a human is doing the hands-on work, not a machine.
- Repetitive — the same task recurs; it isn't a one-off.
- Automatable — a machine could do it just as well. If genuine human judgment is essential, it isn't toil, even if it's manual and repetitive.
- Tactical — interrupt-driven and reactive, not part of a deliberate strategy.
- No enduring value — completing it leaves the service in the same state it was in before; nothing about the system is durably better afterward.
A task has to clear all five to count as toil under the strict definition — miss one and it's something else (overhead, legitimate engineering work, or a one-time migration that just looks tedious). Google's own SRE book also cites a widely-known sixth trait worth knowing even though it's not one of the core five: toil tends to scale roughly linearly, O(n), with service growth — a task that gets proportionally worse as the service gets bigger is a toil red flag even before you check it against the five.
Automation is the second-best fix for toil, not the best one. The best fix is elimination — removing the need for the task entirely, by redesigning the system so the manual step no longer has to happen at all. Automating a task that shouldn't exist just means a script now does something nobody needed done, faster. When a question asks for "the best response to recurring toil," don't reflexively reach for "write a script" if "stop needing to do this" is also on the answer list.
Domain 4 — Monitoring & Service Level Indicators
☺ Like you're 10: Watching the dashboard you already built vs. being able to ask the system a brand-new question at 2am — those are two different skills with two different names.
Full walkthrough: Monitoring & Service Level Indicators. Deep-dive detail on the biggest confusion here lives in alert design & alert fatigue if you want it beyond exam depth.
Monitoring answers questions you already thought to ask: is this specific metric inside its threshold right now. It's built around known-unknowns — dashboards and alerts defined in advance for failure modes someone anticipated. Observability is the broader property of being able to ask an arbitrary new question of a system's internal state without shipping new code first — the tooling (high-cardinality traces, structured logs, ad-hoc queries) that lets you investigate an unknown-unknown nobody built a dashboard for because nobody knew to. Monitoring tells you that something's wrong against a signal you predicted; observability is what lets you find out why once the failure mode is one nobody predicted. Full course treatment in Monitoring & observability.
Domain 5 — SRE Tools & Automation
☺ Like you're 10: A runbook tells you exactly what to click; a playbook tells you how to think when nothing on the runbook quite matches what's happening.
Full walkthrough: SRE Tools & Automation. This exam domain tests categories and vocabulary far more than specific product names — the SRE toolchain page and this course's tool pages, from Prometheus to PagerDuty, cover named products in depth if you want that layer too.
A runbook is exact: known trigger, known fix, ordered steps, minimal judgment required — the artifact toil elimination is trying to eventually delete by automating it away entirely. A playbook is a framework for judgment when the trigger or the fix isn't fully known yet — how to triage severity, who to page next, what questions to ask first. Mature incident response usually has both: runbooks for the failure modes that recur often enough to be worth scripting, and a playbook for everything else, including the failure the runbooks don't cover.
Domain 6 — Anti-Fragility & Learning from Failure
☺ Like you're 10: Three different things can happen when you stress-test a system — it breaks, it shrugs, or it actually comes back stronger — and the exam wants you to name all three correctly, not just the first two.
Full walkthrough: Anti-Fragility & Learning from Failure. Chaos engineering mechanics live in chaos engineering and, beyond exam depth, chaos engineering at scale; postmortem process lives in postmortems & blameless culture.
Robust (sometimes "resilient") means a system absorbs a shock and returns to the same state it was in beforehand — the shock changes nothing, for better or worse. Anti-fragile, Nassim Taleb's term, means the system comes out of the shock better than it went in, because the disruption exposed a weakness that then got permanently fixed. They aren't the same property, and anti-fragile isn't simply "robust, but more" — a system can only become genuinely anti-fragile by repeatedly converting real weaknesses into fixes, which requires a robust-enough foundation to survive the exposure in the first place. On the exam, treat "robust" as the correct answer whenever a system merely withstood a failure unchanged, and reserve "anti-fragile" for scenarios where the write-up explicitly says the system, process, or team improved because of the failure — chaos engineering's entire premise is deliberately manufacturing that improvement instead of waiting for production to supply it for free.
Blameless describes the norm: no individual is named, punished, or singled out as the cause, because the working assumption is that people acted reasonably given what they knew at the time. Blame-aware is a related but distinct stance some practitioners use (tracing back to writing on "Just Culture" by Sidney Dekker and popularized in SRE circles by John Allspaw and Dave Zwieback): it keeps the no-punishment norm but is explicit that individual decisions and actions are still examined in real detail — the argument being that pretending nobody made any decisions produces a shallower postmortem than acknowledging the decisions and still declining to punish them. On the SREF, "blameless" is the term the syllabus centers and the one to default to; treat "blame-aware" as the nuance that shows you've read past the flashcard version, not as a competing answer to swap in.
"MTTR" gets expanded four different ways in the wild, and they measure different things: mean time to Detect (fault occurs → someone notices), mean time to Acknowledge (alert fires → a human confirms they're on it), mean time to Recover (fault occurs → service restored, even via a workaround), and mean time to Resolve (fault occurs → the underlying cause is actually fixed, not just mitigated). A rollback can make Recovery fast while Resolution is still hours away. If a question gives you a number and calls it "MTTR" without saying which one, read the surrounding scenario for which milestone it's actually describing before you trust the label.
Domain 7 — Organizational Impact of SRE
☺ Like you're 10: Where the SRE team actually sits in the org chart, and who's allowed to say "no more releases this week," turn out to matter as much as any formula.
Full walkthrough: Organizational Impact of SRE. Team-shape detail beyond exam depth lives in SRE team topologies; readiness-gate mechanics in production readiness reviews.
"You build it, you run it" (associated with Amazon and Werner Vogels) puts the development team fully on the hook for operating what they shipped, with no separate operations function at all. The classic SRE model keeps a distinct SRE function — often centralized or embedded — that will operate a service on the dev team's behalf, but only after it clears an explicit gate (the production readiness review above) and only within the error budget the dev team is spending. They solve the same underlying problem — don't let developers throw code over a wall to an ops team that doesn't understand it — with a structurally different answer: one has no separate operator at all, the other has a separate operator with veto power tied to a number.
Domain 8 — SRE, Other Frameworks & the Future
☺ Like you're 10: SRE didn't invent "keep production running" — it's one specific answer to a question older frameworks like ITIL also tried to answer, just with different tools.
Full walkthrough: SRE, Other Frameworks & the Future. Reliability's overlap with cost sits in reliability economics; its overlap with security sits in security's overlap with reliability.
| ITIL term | SRE's closer analogue | What actually differs |
|---|---|---|
| Incident Management | Incident response | Similar goal (restore service fast); SRE typically runs it with an explicit incident commander role and ties severity directly to error-budget impact rather than a fixed ITIL priority matrix. |
| Problem Management | Postmortem / root-cause analysis | ITIL separates "problem" records into a tracked known-error database; SRE's postmortem is blameless by default and produces action items folded directly into the team's own reliability backlog rather than a separate database. |
| Change Management (CAB) | Error-budget policy | ITIL gates a change through a Change Advisory Board's human approval. SRE gates the same decision through whether the error budget has room — often removing the human approval step entirely once the budget is healthy, and tightening it automatically once it isn't. |
The master confusion table — every pair, one place
☺ Like you're 10: If you only re-read one table on this whole page the night before the exam, make it this one.
This table exists for one purpose: a fast, final pass across every look-alike pair on this page, without re-reading the surrounding paragraphs. If a row makes you pause, that's your actual remaining study list — go back to that domain section above, not just to this row.
| The pair | The trap | The actual distinction |
|---|---|---|
| SLI vs. SLO vs. SLA | Treating all three as "the reliability number" | SLI = measured. SLO = internal target. SLA = external promise, deliberately looser than the SLO. |
| Error budget vs. error-budget policy | Answering a "what happens when the budget's gone" question with the formula instead of the governance | Budget = a number, (1 − SLO) × volume. Policy = the pre-agreed rulebook for what that number's exhaustion triggers. |
| Toil vs. overhead | Calling any tedious task "toil" | Toil is manual, repetitive, automatable, tactical, and of no enduring value — and tied to running the service. Overhead is necessary non-operational work (email, meetings) that fails that last test. |
| Toil vs. technical debt | Treating them as the same reduction target | Technical debt is a property of the system's design. Toil is a property of the manual operational work a human keeps repeating. |
| Automation vs. elimination | Assuming "automate it" is always the best fix for toil | Elimination — removing the need for the task entirely — beats automation. Automation is the strong second-best, not the goal itself. |
| Monitoring vs. observability | Using them as synonyms | Monitoring answers questions defined in advance (known-unknowns). Observability lets you ask a brand-new question of the system's state without shipping new code first (unknown-unknowns). |
| White-box vs. black-box monitoring | Assuming "monitoring" only ever means one of these | White-box comes from the system's own internal instrumentation. Black-box comes from testing externally-visible behavior, the way a user or a probe would. |
| Symptom-based vs. cause-based alerting | Paging on every internal threshold crossed | Symptom-based pages on user-visible impact (an SLO burn). Cause-based pages on a suspected internal condition that may or may not have caused any actual impact. |
| Robust (resilient) vs. anti-fragile | Using "anti-fragile" as a fancier word for "robust" | Robust returns to the same state after a shock. Anti-fragile comes out of the shock measurably better — a stronger, rarer property, not a synonym or an automatic upgrade. |
| Blameless vs. blame-aware | Reading "blame-aware" as secretly punitive | Both decline to punish. Blameless avoids dwelling on individual decisions; blame-aware still examines those decisions in detail while still declining to punish them. |
| Postmortem vs. retrospective | Using either word for any team review meeting | Postmortem is scoped to one specific incident with tracked corrective actions. Retrospective is a periodic review of how the team works generally, incident or not. |
| COE vs. postmortem | Thinking they're different practices | Same underlying practice — Amazon's "Correction of Errors" and Google's "postmortem" are two vendors' names for one concept. |
| MTT-Recover vs. -Resolve vs. -Acknowledge vs. -Detect | Assuming "MTTR" always means the same milestone | Detect = notice it. Acknowledge = a human confirms ownership. Recover = service restored, even via workaround. Resolve = root cause actually fixed. A fast rollback can make Recovery quick while Resolution is still hours out. |
| Runbook vs. playbook | Using either term for any incident document | Runbook = exact steps for a known failure mode. Playbook = a decision framework for an unfamiliar or broader class of incident. |
| Embedded vs. centralized vs. consulting SRE | Assuming there's one correct SRE team shape | Embedded sits inside one product team. Centralized builds shared platforms for many teams. Consulting raises a team's practice temporarily, then hands ownership back. |
| "You build it, you run it" vs. classic SRE | Treating both as "developers own reliability" | "You build it, you run it" has no separate operator at all. Classic SRE keeps a distinct SRE function that operates the service on the dev team's behalf, gated by a readiness review and an error budget. |
| Reliability vs. availability | Using "reliable" and "available" interchangeably | Availability is one measurable dimension (uptime %). Reliability is the broader property, also covering correctness, durability, and consistency. |
Cover the right two columns of the table above with your hand — or better, open a blank page and don't look at the table at all. For each pair in the left column, write one sentence that states the actual distinction without using either term to define the other (no "an SLA is like an SLO but…"). If you can't finish a sentence without circling back to the word you're supposed to be defining, that pair isn't actually learned yet — it's just recognized, which is the exact gap this exam is built to expose. Then check yourself against the practice question bank, which stages several of these pairs as scenario questions rather than straight definitions — the harder and more realistic test of whether the distinction survived contact with a story instead of a glossary card.
Remy the Rabbit: Quiz me. SLI, SLO, SLA — go.
Nutty the Squirrel: SLI is what you measured. SLO is what you promised yourself. SLA is what you promised the customer — and it's looser than the SLO on purpose.
Remy the Rabbit: Correct, under a second. Next — robust vs. anti-fragile, go.
Foxy: Careful — those aren't a pair where one's just a fancier version of the other. Robust survives the shock unchanged. Anti-fragile comes out of it better than it went in.
Sol the Sloth: And "unchanged" is still a win — don't let the word "anti-fragile" make robust sound like the disappointing option. Most production systems should earn robust first and anti-fragile later, if ever.
Timmy the Turtle: Nutty, that error-budget-policy card — checked against a real source, or filed from memory?
Nutty the Squirrel: Checked against Google's own SRE workbook chapter on the subject before it went on this page. Every card here got checked once — because on the actual exam, nobody's checking it for you.
That's the full reference: eight domains, the terms worth knowing cold inside each, and every look-alike pair pulled out and set side by side instead of left for you to notice on your own mid-exam. Pair it with the SREF study plan for how to sequence studying this against the blueprint pages, closed-book strategy for tactics on the day itself, answer triage for what to do when two options both look defensible, and the five mock exams for full-length timed practice once every row of the confusion table above stops making you pause.
1. Put SLI, SLO, and SLA in order from "what you measured" to "what you promised a customer," and say which is normally the loosest, and why. 2. Name toil's five defining properties. 3. What actually separates "robust" from "anti-fragile" — and which one should most production systems target first? 4. A service's error budget hits zero and nothing happens operationally. What's actually missing, and what's the term for it? 5. What does "blame-aware" add to "blameless" that the plain word alone doesn't say?
Check your answers
- SLI (measured) → SLO (internal target) → SLA (external promise). The SLA is normally the loosest of the three, set that way deliberately so the team discovers trouble via its own SLO before a customer discovers it via a breached SLA.
- Manual, repetitive, automatable, tactical, and devoid of enduring value. (A widely-cited related sixth trait — toil tends to scale linearly, O(n), with service growth — is worth knowing but isn't one of the core five.)
- Robust means the system absorbs a shock and returns to the same state it was in before — unchanged, for better or worse. Anti-fragile means the system comes out of the shock measurably better, because the shock exposed a weakness that then got fixed. Most production systems should target robust first; anti-fragility without a robust foundation is just fragility with better storytelling.
- What's missing is an error-budget policy — the pre-agreed document defining what a zeroed-out budget actually triggers (a freeze, an escalation, an exception process). The budget itself is just arithmetic; without a policy attached to it, exhausting it has no defined consequence.
- "Blameless" avoids dwelling on individual decisions when reviewing an incident. "Blame-aware" keeps the same no-punishment norm but is explicit that individual actions and decisions are still examined in real detail — the position being that ignoring the decisions people made produces a shallower postmortem than examining them honestly while still declining to punish anyone for them.