SRE Principles & Practices
What is SRE? already told this course's version of the story — Google, 2003, Ben Treynor Sloss, the 50% rule — as a narrative you read once and remember. This page is that same territory rebuilt for a closed-book, multiple-choice exam: the exact facts the SRE Foundation (SREF) blueprint's first module wants you holding, the "class SRE implements interface DevOps" framing stated precisely enough to survive a distractor, and the three-way SRE-vs-DevOps-vs-traditional-ops distinctions the exam tests directly. Module 1 is almost entirely vocabulary and origin — no arithmetic yet, no tools yet — so the skill this page drills is definitional precision, not narrative recall.
Think of "DevOps" as a rulebook that just says "developers and the people who keep things running should get along and share the work" — it never says exactly how. "SRE" is one specific team that read that rulebook and wrote down the exact steps: track a number for how reliable you're being, keep a stash of "allowed to break" minutes, and once that stash runs out, stop building new stuff and go fix things instead. Two different teams could both follow the DevOps rulebook and end up doing completely different things day to day — but if a team calls itself SRE, the exam expects you to know the exact steps they're supposed to be following, not just the vague rulebook behind it.
Where this module sits, and what the exam actually tests
☺ Like you're 10: This is question topic one of eight — and it's the one about words meaning exactly what they say, not about any specific tool or formula yet.
The SRE Foundation (SREF) from the DevOps Institute is a closed-book, 40-question, 60-minute multiple-choice exam with a 65% pass mark and no formal prerequisites, organized around eight syllabus modules. This page covers the first: SRE Principles & Practices — the origin, the DevOps relationship, and the vocabulary every later module assumes you already hold precisely. Here's the full map, so you can see where the rest of this course's blueprint coverage is headed from here:
| # | Module | What it covers |
|---|---|---|
| 1 | SRE Principles & Practices ← this page | Where SRE came from, and how it relates precisely to DevOps and traditional ops |
| 2 | Service Level Objectives & Error Budgets | Setting a target for an SLI and spending the budget it creates |
| 3 | Reducing Toil | The six-property test for whether a task legally counts as toil |
| 4 | Monitoring & Service Level Indicators | Deriving a trustworthy SLI from raw telemetry |
| 5 | SRE Tools & Automation | The operational toolchain that implements Modules 2–4 |
| 6 | Anti-Fragility & Learning from Failure | Chaos engineering and blameless postmortems |
| 7 | Organizational Impact of SRE | Team topologies, on-call, and adoption |
| 8 | SRE, Other Frameworks & the Future | How SRE relates to ITIL, DevOps, and where it's heading |
Some certifications publish an exact percentage per domain — CNPE, covered elsewhere on this platform, states its GitOps domain is worth 25% of that exam, for example. The SREF blueprint doesn't work that way: DevOps Institute does not publish a confirmed per-module breakdown of its 40 questions, so there's no legitimate "Module 1 is worth 12% of the exam" figure to study to, whatever number you might see quoted secondhand. Treat the table above as a syllabus map, not a scored weighting — budget your study time roughly evenly across all eight modules, and confirm the current syllabus and any weighting claims against DevOps Institute's own SREF page before you calibrate around a specific percentage.
Where SRE actually came from
☺ Like you're 10: The short version for the exam: 2003, Google, Ben Treynor Sloss, about seven engineers, and one sentence worth being able to quote.
For the full narrative, read what is SRE? first — this page assumes it and drills three facts the exam wants held precisely rather than loosely paraphrased. First, the who and when: Ben Treynor Sloss founded Google's SRE function around 2003, staffing a roughly seven-person team responsible for keeping google.com running almost entirely with software engineers instead of traditional operators. Second, his own definition, which the exam likes to quote directly or paraphrase as a near-miss distractor: SRE is "what happens when you ask a software engineer to design an operations function." Third — and this is the fact candidates most often get backwards — the chronology. SRE predates the word "DevOps." "DevOps" wasn't coined until 2009, when Patrick Debois organized the first devopsdays conference in Ghent, building on the case for closer Dev/Ops collaboration that John Allspaw and Paul Hammond had made a few months earlier in their widely cited Velocity talk on deploying at Flickr. Google's SRE team had already been running in something like its current form for roughly six years by the time the word "DevOps" existed at all.
That ordering matters for how you should picture the relationship: SRE isn't something Google built on top of an existing DevOps movement — it's a concrete engineering practice that predates the term, which the wider industry later recognized, once the vocabulary existed, as one specific, working answer to the question DevOps was asking. For the artifact that turned Google's error-budget idea from an internal habit into an enforced organizational policy, see Google & the error-budget policy.
"class SRE implements interface DevOps"
☺ Like you're 10: DevOps is a rulebook that never says exactly how; SRE is one team that read the rulebook and wrote down the exact steps.
A framing that's become common in SRE practitioner circles, and one the SREF blueprint borrows directly, states the relationship in a single line of pseudocode familiar to anyone who's written object-oriented software: class SRE implements interface DevOps. Read it literally. An interface defines a contract — what must be true of anything that satisfies it — but supplies no working implementation of its own. DevOps is that interface: a set of cultural principles, commonly summarized as CALMS (Culture, Automation, Lean, Measurement, Sharing), describing how Dev and Ops should relate, without mandating any specific mechanism for getting there. A class that implements an interface must satisfy every method the interface declares, but it also fills each one in with a concrete, working, testable body — and it's free to add methods of its own that the interface never required. SRE is that class: it must satisfy DevOps's principles, but it does so with specific, measurable mechanisms, several of which — a formal error-budget policy, a numeric toil ceiling, mandatory blameless postmortems with tracked action items — have no DevOps equivalent at all.
Google's own Site Reliability Engineering book makes this concrete by mapping five widely cited DevOps pillars to the specific mechanism SRE uses to satisfy each one. Read the diagram below as the interface's method signatures on the left and SRE's method bodies on the right:
Because SRE implements the DevOps interface, everything a well-run SRE team does is a valid instance of DevOps — but the reverse doesn't hold. A team practicing continuous delivery, decent postmortem hygiene, and shared tooling is doing real DevOps without necessarily running an error budget, a formal toil ceiling, or a mandated blameless-postmortem process with tracked action items. The exam's favorite way to test this: describe a team doing genuinely good DevOps work and ask whether they're "doing SRE." Check for the specific mechanisms, not the general vibe, before you answer yes.
SRE vs. DevOps vs. traditional ops — the exam's three-way split
☺ Like you're 10: Three different answers to "who keeps the lights on, and how" — the exam wants you to sort a described team into the right one of the three, fast.
The exam doesn't only test the SRE/DevOps distinction in isolation — it regularly adds a third option, traditional operations (sometimes labeled ITOps), and expects you to place a described team or practice into the correct one of three buckets rather than just recognizing SRE when it's already labeled for you. The table below is the exam-speed version of that sort.
| Dimension | Traditional ops | DevOps | SRE |
|---|---|---|---|
| What it fundamentally is | A distinct operational role, separate from development | A cultural philosophy — no fixed role or job title mandated | A specific engineering discipline that implements one version of that philosophy |
| Governing mechanism | Uptime targets held informally; change-control boards | None mandated — principles only (CALMS) | SLOs with an explicit, enforced error budget |
| Primary metric | Incident count / uptime, often felt more than measured | Deployment frequency, lead time, MTTR, change-failure rate | SLIs measured against SLOs, with a spendable error budget |
| Recurring manual work | Accepted as the nature of the job, uncapped | Automation valued culturally, no formal ceiling | Named "toil," capped at roughly 50% of an engineer's time, tracked toward zero |
| Release / change philosophy | Risk-averse; batched releases behind approval boards | Frequent, small, continuous changes | Error-budget-gated — fast while budget remains, frozen once it's spent |
| On-call & postmortems | Separate ops/NOC team pages; failure often traced to a person | "You build it, you run it" — no explicit cap on load or format | Engineers on call, bounded by the 50% rule; postmortems formally blameless with tracked actions |
(1) Treating "SRE" and "DevOps" as fully interchangeable synonyms — the exam tests the containment relationship precisely: every well-run SRE team is practicing a form of DevOps, but plenty of valid DevOps implementations aren't SRE, because DevOps never mandates an error budget, a toil ceiling, or a formally blameless postmortem process. (2) Assuming DevOps itself prescribes tools or numeric targets — CALMS is principle-level; it never specifies a metric, a percentage, or a review format the way SRE's mechanisms do. (3) Assuming SRE eliminates on-call — it doesn't; it bounds it with the 50% rule and pushes excess load back to the owning team rather than absorbing it indefinitely, a distinction covered in full in incident management & on-call. (4) Calling a renamed ops team "SRE" because they adopted the title — the exam, like Google's own SRE book, is explicit that the job title without the mechanisms is traditional ops wearing a new name tag; see SRE anti-patterns & pitfalls for exactly this failure mode and others like it.
Vocabulary you're expected to define, not recognize
☺ Like you're 10: The exam doesn't ask "which of these counts as toil" — it expects you to already know the definition before it shows you four almost-right answers.
Module 1 questions lean harder on precise recall than almost any other module in this blueprint, because these terms get used loosely everywhere in the industry and precisely nowhere except in an exam like this one. The table below is deliberately compressed to the exact, defensible one-line definition the exam wants — full derivations, formulas, and worked classification examples for the SRE-specific terms live on the pages linked in the right column.
| Term | The precise definition the exam expects | Covered in depth |
|---|---|---|
| Site Reliability Engineering (SRE) | The discipline of applying software-engineering practices and rigor to operations problems; originated at Google c. 2003 under Ben Treynor Sloss. | What is SRE? |
| DevOps | A cultural philosophy — summarized as CALMS (Culture, Automation, Lean, Measurement, Sharing) — for how Dev and Ops should relate, with no mandated mechanism for achieving it. | What is SRE? |
| Traditional operations / ITOps | A distinct operational role, separate from development, typically governed by uptime targets and formal change-control approval rather than an error budget. | Comparison table above |
| Toil | Manual, repetitive, automatable, tactical operational work with no enduring value, that scales linearly (O(n)) with a service's growth. | Reducing Toil · Toil & automation |
| Error budget | The numeric allowance for unreliability — 100% minus the SLO — that governs whether a team ships fast or freezes to fix reliability. | SLOs & error budgets · SLIs, SLOs & error budgets |
| Blameless postmortem | A written incident review that treats failure as a systems problem to fix, not a person to blame, and closes with tracked action items. | Postmortems & blameless culture |
| 50% rule (toil ceiling) | Google's guideline capping an SRE's operational work at roughly half their time, with at least half reserved for engineering work that reduces future toil. | What is SRE? |
| "class SRE implements interface DevOps" | The framing that SRE is one concrete, prescriptive implementation of DevOps's cultural interface — not a synonym for it, and not a replacement of it. | This page, above |
Module 2 picks up exactly where the vocabulary table's fifth row leaves off — Service Level Objectives & Error Budgets turns "error budget" from a one-line definition into the arithmetic the exam actually expects you to compute. Organizational Impact of SRE and SRE team topologies return to the traditional-ops-vs-SRE comparison above in much greater depth once you've got the whole blueprint's vocabulary in hand.
Foxy: Okay, be honest — SRE is just DevOps with a fancier name and a pager, right?
Professor Owl: Wrong on purpose, Foxy — that's exactly the distractor the exam writes. DevOps is the interface: culture, automation, lean, measurement, sharing, no mandated mechanism. SRE is one class that implements it, with the mechanisms filled in.
Nutty the Squirrel: And the glossary's open right here — "toil" isn't just "work I don't like." Manual, repetitive, automatable, tactical, no enduring value, and it grows with the service. Miss one of those and it's just... a task.
Remy the Rabbit: SLI! SLO! Error budget! Fifty percent rule! Blameless postmortem! Done — next card!
Sol the Sloth: ...Slow down, Remy. Knowing the words fast isn't the same as defining one correctly when the exam's fourth answer choice is deliberately, almost right.
Timmy the Turtle: And nobody's quoting me a made-up percentage for how much of the exam this module is worth, either. DevOps Institute hasn't published one — say that honestly or don't say it at all.
1. In the "class SRE implements interface DevOps" framing, what does the interface represent and what does the class represent? Name one concrete mechanism the SRE "class" adds that the DevOps "interface" never mandates. 2. Chronologically, which came first — Google's SRE practice or the term "DevOps" — and by roughly how many years? 3. Give three dimensions on which SRE, DevOps, and traditional operations differ, using the precise terms this page defined. 4. What does DevOps Institute publish about the SREF exam's per-module question weighting, and what's the safe assumption in its absence? 5. A task is manual and happens every single week — using the toil vocabulary from this page, name one additional property it would still need to satisfy before you could call it toil.
Check your answers
- The interface (DevOps) is a contract — cultural principles with no mandated mechanism for satisfying them. The class (SRE) is one concrete implementation that must satisfy that contract but fills in specific, testable mechanisms. Any of: a formal error-budget policy, a numeric toil ceiling (the 50% rule), or mandatory blameless postmortems with tracked action items — none of which DevOps as a philosophy requires.
- Google's SRE practice came first. Ben Treynor Sloss began building it around 2003; the term "DevOps" wasn't coined until 2009 (devopsdays Ghent) — roughly six years later.
- Any three of: what each fundamentally is (role vs. philosophy vs. discipline), governing mechanism (change-control boards vs. none mandated vs. SLOs + error budget), primary metric (uptime felt informally vs. DORA's four keys vs. SLIs against SLOs), treatment of recurring manual work (accepted vs. valued culturally with no cap vs. named toil and capped at ~50%), release philosophy (risk-averse and batched vs. frequent and continuous vs. error-budget-gated), or on-call and postmortems (separate NOC team, blame-prone vs. "you build it you run it" vs. bounded on-call with mandated blameless postmortems).
- DevOps Institute does not publish a confirmed per-module weighting for the SREF exam's 40 questions. The safe assumption is to treat all eight modules as roughly equally likely to appear and budget study time evenly across them, verifying any specific claim against DevOps Institute's own current exam page rather than a secondhand percentage.
- Being manual and recurring alone isn't enough — it would also need to be automatable (no genuine judgment call required), tactical (interrupt-driven rather than planned), have no enduring value (the system ends up exactly where it started), and scale roughly linearly (O(n)) with the service's growth. Failing any one of those disqualifies it, however manual and frequent it is.