Exam Prep · SRE Foundation (SREF)

Know It Cold — SREF

The SREF is closed-book: no tab to flip to, no glossary open beside you, nothing but what's already in your head when the sixty-minute clock starts. This page is the last-mile crib list for that specific constraint — not a re-teach of the eight modules, which the rest of this course's SREF shelf already covers in full, but the small set of facts you need to be able to produce instantly and without deliberation: the eight module names in the order DevOps Institute lists them, the exact format numbers, the error-budget arithmetic worked against real window sizes, and the handful of term-pairs that single-best-answer questions are built to exploit. Read it once for shape. Then close it, recite it, and check yourself — reading this page a second time feels like studying and mostly isn't.

☺ Explain it like I'm 10

Some tests let you bring a cheat sheet. This one doesn't — so the only cheat sheet that helps is the one you build inside your own head before you walk in. This page is that cheat sheet, written down one last time so you can copy it into memory. The whole point is that by exam day, you shouldn't need the page anymore.

🐰🦥Your hosts for this topic: Remy the Rabbit & Sol the Sloth — Remy is pure reflex, the one who can fire back the eight modules or the pass mark before you've finished asking; Sol is the deliberate counterweight, working the error-budget arithmetic slowly and getting it exactly right instead of fast and wrong. A closed-book exam needs both: instant recall for the vocabulary, careful arithmetic for the one calculation question that shows up in some form almost every sitting.

How to use this page

☺ Like you're 10: Don't just read it — cover it, say it out loud from memory, then peek and see what you missed.

Every section below is written to be recited, not skimmed. The honest way to use this page: read one section, close your eyes or cover the screen, say the whole thing back out loud or on a scrap of paper, then check what you got wrong. What you get wrong the first time is your actual study list — it will be shorter than you expect, and far more specific than "I should review the whole thing again." Anything you miss twice belongs on a flashcard in the flashcards, not on a third read of this page.

The exam format — say it without looking

☺ Like you're 10: Five numbers, memorized cold: how many questions, how long you get, what score you need, how many that actually is, and how many topics it's drawn from.

These numbers should be reflexive before you sit down — not because you'll be tested on them directly, but because pacing depends on them. Full logistics, registration, and cost live on the SREF exam page; this is the compressed version you carry into the room.

FactValue
FormatClosed-book, multiple-choice, single-best-answer — exactly one correct option, no select-all
Questions40
Duration60 minutes — roughly 90 seconds per question if you spend it evenly
Passing score65%26 of 40 correct
PrerequisitesNone
Blueprint8 modules, no published per-module weighting — study all eight as equally likely to show up
⚠ The trap this format sets

"Single-best-answer" means more than one option is often defensible in isolation. The classic distractor is a sentence that's true about SRE but answers a different question than the one asked — an option that correctly defines an SLA when the stem asked about an SLO, for instance. Read the stem twice before touching an option. Answer Triage — SREF and Closed-Book Strategy — No Docs Map drill this specifically; the term-pair table further down this page is the raw material that skill gets applied to.

The eight blueprint modules, in order — with a mnemonic

☺ Like you're 10: Eight topics, always in this order — and one silly sentence makes them stick without any effort.

DevOps Institute lists the SREF blueprint as eight modules. You don't need to recite them in order for the exam itself — questions aren't grouped by module — but having the full set cold means you never blank on "which module was that in" while triaging a hard question, and it means you can audit your own prep against all eight instead of accidentally skipping one. First letters spell a sentence worth memorizing outright:

◆ The mnemonic

"Please Send Reliable Metrics, Then Automate Our Future."
P·S·R·M·T·A·O·F — Principles, SLOs, Reducing toil, Monitoring, Tools, Anti-fragility, Org impact, Frameworks/Future.

#ModuleOne-line scope
1SRE Principles & PracticesSRE's Google origin, "software engineer runs operations," how it relates to and differs from DevOps
2Service Level Objectives & Error BudgetsSLI/SLO/SLA as distinct concepts, error-budget arithmetic, the release-freeze policy
3Reducing ToilToil's six-part definition, the 50% cap, the automation response
4Monitoring & Service Level IndicatorsThe four golden signals, how SLIs get selected, symptom vs. cause alerting
5SRE Tools & AutomationCategories of SRE tooling — monitoring, incident response, automation frameworks — at a conceptual level
6Anti-Fragility & Learning from FailureBlameless postmortems, chaos engineering, systems that get stronger from controlled failure
7Organizational Impact of SRETeam topologies, on-call structure, the cultural shift SRE requires to stick
8SRE, Other Frameworks & the FutureSRE alongside ITIL and Agile, and where the practice is heading

The error-budget formula — worked cold, every window size

☺ Like you're 10: One formula, and four numbers about how many minutes are in a day, a week, a month, and a quarter — memorize both and you can answer almost any error-budget question on the spot.

This is the one calculation the SREF is likely to ask you to actually perform, in some form, and it only takes two things memorized cold: the formula, and how many minutes live inside whatever window the question gives you. Full derivation and the "burning vs. banking" policy are on SLIs, SLOs & error budgets; this is the arithmetic stripped down to what you recite.

Error budget = (100% − SLO) × window, expressed in the window's own units

Step 1: convert the window to minutes
Step 2: subtract the SLO from 100% to get the allowed failure rate
Step 3: multiply
WindowTotal minutes
1 day1,440
1 week (7 days)10,080
30-day month43,200
90-day quarter129,600

Cross those against the SLO and you get the standard "nines" table — the single most quotable set of numbers in the whole discipline, and exactly the shape of fact a closed-book exam rewards having memorized rather than derived under pressure:

AvailabilityAllowed downtime / year/ 30-day month/ week
90% (one nine)36.5 days72 hours16.8 hours
99% (two nines)3.65 days7.2 hours1.68 hours
99.9% (three nines)8.76 hours43.2 min10.1 min
99.95%4.38 hours21.6 min5.04 min
99.99% (four nines)52.56 min4.32 min~1.0 min
99.999% (five nines)5.26 min~25.9 sec~6.1 sec

Notice the pattern that makes this table reconstructible even if you blank on one cell: each additional nine divides the allowed downtime by roughly 10x. If you remember 99.9% → 43.2 minutes a month, you can derive 99.99% by dividing by ten (≈4.32 min) and 99% by multiplying by ten (≈432 min = 7.2 hours) without memorizing every row separately.

⚠ The trap: "haven't breached yet" ≠ "have budget left"

A service sitting at exactly its SLO — say, 99.9% attainment against a 99.9% SLO — has already spent its entire error budget for the window. There is zero margin left, not "almost none." The correct read of that situation is identical to having gone slightly under: the release-freeze policy applies. A question that describes a service sitting precisely on its SLO line and asks whether the team can still ship a risky change is testing exactly this distinction.

The trap-question term pairs — cold

☺ Like you're 10: Most wrong answers on a test like this aren't from not knowing the topic — they're from mixing up two words that sound almost the same. Here's the exact one-line test for each pair that trips people up.

Single-best-answer questions are built around near-miss pairs: two terms that sound related, where only one is actually correct for the question asked. The fix isn't studying harder in general — it's having the exact distinguishing sentence for each pair ready to fire, so a distractor built around the wrong half of the pair stops working on you. These are pulled directly from where this course's SREF shelf covers them; follow the links if any one of these feels shaky rather than solid.

The pairThe one-line test
SLI vs SLO vs SLASLI = the measurement. SLO = your internal target for it. SLA = the external contract, deliberately looser than the SLO so normal noise doesn't trigger a penalty. See the full page.
Error budget burning vs bankingBurning = spending remaining budget on deliberate risk (faster ships, chaos experiments). Banking = the budget is exhausted, so the team freezes risky releases and shifts to reliability work until the window rolls forward.
Toil vs. work that's merely hard or unpleasantToil needs all six: manual, repetitive, automatable, tactical, devoid of enduring value, and O(n) with growth. A design doc or a novel outage debug is hard but leaves something behind — not toil. See the full page.
Symptom-based vs cause-based alertingSymptom-based pages on what users actually feel (p99 latency, error rate) — it scales and stays actionable. Cause-based pages on internal conditions that might become a problem (CPU at 85%) — it doesn't scale and trains people to ignore pages. Causes belong on a dashboard, not the pager. See the full page.
Golden signals vs USE vs REDGolden signals (Latency, Traffic, Errors, Saturation) are generic, for any service. USE (Utilization, Saturation, Errors) targets one resource — CPU, a connection pool. RED (Rate, Errors, Duration) targets a request-driven service end to end and is essentially the golden signals minus saturation.
SEV1 vs SEV2 vs SEV3SEV1 = full outage, pages immediately 24/7. SEV2 = partial degradation or an SLO threshold crossed without full unavailability, pages during business hours. SEV3 = minor, stays inside budget, becomes a ticket and never pages anyone. See the full page.
Blameless investigation vs. assigning blameBlameless is an information-gathering strategy, not politeness — punishing the person who held the pager teaches everyone else to hide the same systemic flaw better. A five-whys chain that terminates on a person ("the engineer should've been more careful") has stopped one why too early. See the full page.
Chaos experiment vs game dayA chaos experiment is hypothesis-driven and tests whether the system degrades the way it's designed to. A game day is a scheduled exercise that tests whether the team knows what to do — paging, runbooks, incident-commander handoff. "Let's see what happens if we kill X" is neither — it has no stated pass condition, so it isn't a hypothesis at all. See the full page.
DevOps vs SREDevOps is a cultural philosophy (CALMS) with no mandated mechanism. SRE is one prescriptive implementation with concrete mechanisms DevOps doesn't require — SLOs and error budgets, a 50% toil cap, blameless postmortems. Remember it as "class SRE implements interface DevOps." See the full page.

A smaller set worth having cold too, even though they sit more at the edges of the eight-module blueprint than at its center — closed-book questions still lean on this vocabulary when a scenario needs a concrete resilience mechanism named correctly:

🐰 Remy's 90-second recall drill

Cover the whole page. Out loud or on paper, produce all of the following without looking back: the five format numbers; the eight module names, in order, using the mnemonic sentence; the error-budget formula plus the minutes-per-window table; and, for five term-pairs of your choosing from the table above, the one-line distinguishing test. Then uncover the page and grade yourself line by line. Anything you missed is not a sign you don't understand SRE — it's a sign that specific fact hasn't crossed from "recognized when I see it" to "recalled when I need it," which is the only distinction a closed-book exam actually tests. Run this drill daily in your final week, not once.

🎬 At the Reliability Watch
🐰

Remy: Eight modules. Go. Principles, SLOs, Toil, Monitoring, Tools, Anti-fragility, Org, Frameworks. Two seconds.

🦊

Foxy: Show-off. Okay — service sits at 99.9% against a 99.9% SLO. Budget left or not?

🦥

Sol: ...None. Zero. Sitting exactly on the line means the whole thing's already spent, not spare. I don't rush that one, but I don't get it wrong either.

🐢

Timmy: And a database sitting at 85% CPU with checkout latency completely flat — does that page anyone?

🐰

Remy: No! Cause, not symptom. Dashboard, not pager. Next.

🦥

Sol: Speed's fine once it's correct, Remy. That's the whole exam in one sentence — sixty minutes is generous if you actually know it, and it evaporates if you're re-deriving arithmetic you should have had cold.

That's the full crib sheet — five format numbers, eight modules behind one mnemonic sentence, one formula plus the minutes to run it against any window, and the term-pairs a single-best-answer question is built to exploit. Pair it with the SREF Concept Reference for definitions in full, Closed-Book Strategy — No Docs Map for exam-day tactics, and Answer Triage — SREF for practice spotting exactly these distractors in context. Then test the recall for real against the practice bank and a timed full mock exam before you book the sitting described on the exam guide.

✓ Checkpoint

1. Recite the eight SREF modules in order using the mnemonic sentence. 2. Say all five exam-format numbers from memory: question count, duration, pass percentage, the raw score that represents, and the module count. 3. A service holds a 99.99% SLO measured over a 7-day window. How many minutes of error budget does that allow? 4. Give the one-line distinguishing test for the SLI/SLO/SLA trio and for symptom-based vs. cause-based alerting, without looking back at the table. 5. What's the functional difference between what a chaos experiment tests and what a game day tests?

Check your answers
  1. Please Send Reliable Metrics, Then Automate Our Future → SRE Principles & Practices, Service Level Objectives & Error Budgets, Reducing Toil, Monitoring & Service Level Indicators, SRE Tools & Automation, Anti-Fragility & Learning from Failure, Organizational Impact of SRE, SRE Other Frameworks & the Future.
  2. 40 questions, 60 minutes, 65% to pass, which is 26 of the 40 correct, drawn from 8 blueprint modules with no published per-module weighting.
  3. 0.01% × 10,080 minutes = 1.008 minutes, roughly one minute of allowed downtime across the week.
  4. SLI is the measurement, SLO is your internal target for it, SLA is the external contract set looser than the SLO on purpose. Symptom-based alerting pages on what users actually feel (latency, error rate); cause-based alerting pages on internal conditions that might eventually cause a problem (CPU, disk) and belongs on a dashboard, not the pager.
  5. A chaos experiment is hypothesis-driven and tests whether the system degrades the way it was designed to — largely a test of the automated failover and resilience code. A game day is a scheduled exercise that tests the team and the response process itself — paging, runbook accuracy, incident-commander handoff — not just whether the system's automation works.