The Baseline You Need First

The SRE Foundation exam is unusual among the certifications on this Academy: it has no formal prerequisites at all. PeopleCert's own product page says so, training is not mandatory, and nothing on this site or anywhere else has to be passed first. That is a booking rule, and people read it as a study plan. It isn't one. The syllabus underneath the exam is written in the vocabulary of production operations — toil, saturation, blast radius, burn rate, self-healing, auto-scaling, immutable infrastructure — and every one of those words is used as though you already know what it points at. This page is the honest floor: the Linux, the distributed-systems behaviour, the percentage arithmetic, the monitoring concepts and the on-call practice that make the rest of this course land instead of merely scroll past. It ends with ten diagnostic questions and a two-tier self-test with a full answer key, so you find the gaps here, in an afternoon, rather than in the sixtieth minute of a sixty-minute paper.

"No prerequisites" is a booking rule, not a study plan

☺ Like you're 10: Anyone is allowed to sign up. That's not the same as everyone being ready.

Three official statements set the frame for this whole page, and they pull in slightly different directions.

The first is PeopleCert's, on its SRE Foundation product page: there are no prerequisites, and accredited training is recommended rather than required. The second is the DevOps Institute's, in the free SREF Exam Study Guide: although there are no formal prerequisites, it recommends candidates complete at least 16 contact hours of instruction and labs through an accredited Education Partner. The third is the same study guide's statement about difficulty: the exam is constructed at Bloom levels 1 and 2 only — knowledge and comprehension. There are no Bloom 3+ items. Nothing on the paper asks you to apply a technique to a novel situation, analyse a system, or design anything.

Put those together and you get an exam with a genuinely low ceiling and a genuinely real floor. The ceiling is low because Bloom 1 and 2 means recall and understanding, in a fixed vocabulary, with four options and a single best answer. Chris McLeod, who sat and passed the SREF in December 2023 and wrote it up on his personal blog, reached the same conclusion from the inside: he found it broad rather than deep, and said his DevOps background helped with general familiarity but was not essential. That is one person's one sitting, and it was the v1.1-era syllabus — but it corroborates the official Bloom statement exactly, which is the most useful thing a single account can do.

The floor is real because the syllabus never defines the world its concepts live in. The official concept and terminology list — the exam's own vocabulary inventory, printed in that same free PDF — includes Kubernetes, Amazon Web Services, cloud computing, auto-scaling, software-defined networking, immutable infrastructures, application performance management, canary testing, latency, response time and self-healing. Not one of those is taught by the syllabus. They are the furniture of the room the syllabus is describing.

Two different meanings of "I know this"

Everything on this page splits along one line, and it is worth being blunt about it, because the two halves have completely different costs to close.

The exam's standard is recognition: shown four sentences about error budgets, can you pick the one that matches the syllabus? That standard is reachable by a determined beginner in a few weeks of disciplined memorisation, and this course's flashcards, Know It Cold and concept reference exist to get you there efficiently.

The practitioner's standard is different: could you set an SLI for a service you own, defend the number to a product manager, and know what to do at 3am when the budget is gone? Nothing on the SREF paper measures that. Everything in the job does, and so does every serious interview.

The whole floor, at a glance

Five areas. Each gets its own section below, each says which of the eight examined topic areas leans on it, and each ends with the specific pages in this course that close the gap if you find one.

Where the questions actually are

☺ Like you're 10: Not all the topics are worth the same. Three of them are nearly half the paper.

The DevOps Institute publishes something most vendors don't: an explicit maximum number of questions per topic area, summing to the full 40. It appears in the free SREF Exam Study Guide, and it is the single most useful planning artefact for this exam.

The arithmetic below is ours, derived from that official table — it is not a DevOps Institute claim. SRE-2 (6) plus SRE-4 (7) plus SRE-5 (6) is 19 of 40. The pass mark is 65%, which on a 40-question paper is 26 correct. So those three areas alone can carry roughly three-quarters of the marks you need, and two of the three — SLOs and monitoring — sit directly on top of two of this page's baseline areas: availability arithmetic and monitoring concepts. If you close only two gaps before you start, close those two.

Linux and the production operating system

☺ Like you're 10: Nobody will ask you to type a command. Every example quietly assumes you've watched a computer misbehave.

⚖ Where it bites — SRE-3 (Reducing Toil, up to 5 questions) and SRE-5 (Tools & Automation, up to 6). Between them, up to 11 of 40.

This is not a Linux exam. There is no terminal, no console, no cluster, and you will not be asked what a signal number means. What you will be asked is to recognise which of four described activities counts as toil, what kind of work automation should absorb, and what "self-healing" means in practice — and every single one of those questions is set in an operating system whose behaviour is taken as read.

The five places the syllabus quietly touches the OS

Read the concept list and the topic descriptions closely, and the OS shows up at exactly five points. Each one is a place where prior experience turns a memorisation task into an obvious answer.

What "comfortable" looks like

You do not need to be a systems administrator. You need the following to be unremarkable rather than novel — if you read this list and none of it is familiar, that is a real gap, and it is the one most likely to make the toil and automation material feel abstract:

# where did it go wrong, and when
journalctl -u myservice --since "10 min ago"
tail -n 200 /var/log/myservice.log

# is the process even running, and what is it doing
systemctl status myservice
ps aux --sort=-%cpu | head

# what is full
df -h                 # disk
free -m               # memory
ulimit -n             # file descriptor ceiling

# was it killed rather than crashed
dmesg -T | grep -i "out of memory"

The point of that list is not the commands. It is the five questions behind them: did it run, did it stop, was it killed, is something full, and what did it say before it went? Those five questions are the shape of almost every real operational incident, and they are the reason "restart it" feels like a fix when it is only a delay.

If this section found a gap

Toil & automation is the direct fix, and it defines toil precisely enough to apply as a test rather than a vibe. Capacity planning & performance covers saturation as a measurable quantity rather than a feeling. The SRE toolchain names the things that do the healing, and the toil audit drill makes you apply the definition to your own week, which is by far the fastest way to make it stick.

How distributed systems actually fail

☺ Like you're 10: Big systems don't break all at once. One slow part quietly ruins everything attached to it.

⚖ Where it bites — SRE-1 (Principles & Practices) and SRE-6 (Anti-fragility & learning from failure), up to 8 of 40 — plus it silently underwrites most of SRE-4.

The SREF's whole worldview rests on a single premise stated in Google's framing of the discipline: failure is normal. Not rare, not preventable, not a sign that someone did something wrong — normal, expected, and budgeted for. That premise only makes sense if you already know that a distributed system is almost never fully up or fully down. It is partially degraded, for some users, on some requests, some of the time. If your mental model of "down" is a light switch, error budgets will read as accounting rather than as physics.

The eight behaviours worth already knowing

None of these will be asked about by name in a Bloom 1–2 question. All of them make the concepts that are asked about obvious rather than memorised.

If this section found a gap

Distributed-systems reliability fundamentals is the direct read. Reliability patterns covers timeouts, retries, circuit breakers, bulkheads and load shedding as a connected set rather than a list. Queueing theory for SRE is the honest answer to why the utilization knee exists at all, and dependency management and Hyrum's law covers what happens when the thing you depend on changes underneath you.

The arithmetic floor — nines, minutes and budgets

☺ Like you're 10: There is exactly one bit of maths on this exam, and it comes up more than once. It's worth being fast at it.

⚖ Where it bites — SRE-2 (SLOs & Error Budgets), up to 6 of 40 — and it is the only place the paper asks you to compute anything.

The free official study guide includes a full 40-question sample paper with its answer key, and one of the items on it does exactly this: it gives a team a monthly availability SLO of 99.9% and asks how much error budget that allocates. The published key's answer is 43 minutes. That single item tells you two things — that percentage-to-minutes conversion is genuinely examinable, and that the exam uses the simple time-based reading of a "month" (30 days, 43,200 minutes) rather than anything more careful.

The table worth holding in your head

Two columns, one calculation. A 30-day month is 43,200 minutes; a 365-day year is 525,600 minutes. Multiply by one minus the target.

The mental shortcut is worth more than the table: 1% of a 30-day month is about 7.2 hours, and every extra nine divides by ten. 7.2 hours, 43 minutes, 4.3 minutes, 26 seconds. If you can produce that ladder from memory in ten seconds you have covered every version of this question anyone can construct, and you never have to trust a memorised row again.

Budget, burn rate, and the two ways to count

Three formulas, all of which follow from the same idea — the budget is the unreliability the target permits:

• Time-based budget = (1 − SLO) × length of the window. The version the sample paper uses, and the easiest to explain to a non-engineer.
• Request-based budget = (1 − SLO) × total valid requests. The version most real SLOs use, because it weights by actual traffic rather than treating a quiet Sunday night the same as a Monday morning peak.
• Burn rate = the rate you are spending the budget, expressed as a multiple of the sustainable rate. A burn rate of 1× exactly exhausts the budget at the end of the window; 10× exhausts it in a tenth of the window.

Be aware that the two counting methods can genuinely disagree about whether a service met its SLO — a short outage during peak traffic costs far more request budget than time budget, and vice versa. The exam works in the simple time-based frame; production increasingly does not. Both are correct; they answer slightly different questions. SLO window types and composite SLOs covers the difference properly, including rolling versus calendar windows.

If this section found a gap

SLIs, SLOs & error budgets is the core page and does the arithmetic slowly. Measuring & reporting reliability covers what you do with the numbers once you have them. Multi-window burn-rate alerting is the practical use of burn rate, and the SLO and error-budget drill makes you compute one for a service rather than read about it.

Monitoring — the heaviest area, and the highest assumed floor

☺ Like you're 10: The biggest chunk of the exam is about measuring things. It assumes you already know what a measurement is.

⚖ Where it bites — SRE-4 (Monitoring & Service Level Indicators), up to 7 of 40 — the single heaviest topic area on the paper.

This is where the gap between "no prerequisites" and "the syllabus assumes plenty" is widest. The topic area's own description talks about understanding SLIs and how they relate to SLOs, the monitoring landscape, observability, and setting measurable objectives. Every one of those phrases contains an unexploded assumption: that you know what a metric is, what a time series is, what it means to aggregate one, and what a percentile computed from a histogram actually represents.

The vocabulary the questions stand on

The named frames you should recognise on sight

Three of these are general SRE knowledge; the fourth is specific to this syllabus, and that distinction is worth making explicitly.

• The four golden signals — latency, traffic, errors, saturation. From Google's SRE book, and the most likely of the four to appear.
• RED — rate, errors, duration. A request-centric frame for services.
• USE — utilization, saturation, errors. A resource-centric frame for machines and devices.
• VALET — the SLO model named in the official sample paper, where the "T" stands for tickets. This one is exam vocabulary rather than industry-standard vocabulary: many working SREs have never met it, and you will not derive it from experience. Learn it as a term.

If this section found a gap

Monitoring & observability is the core page. Alert design and alert fatigue covers symptom-versus-cause properly and is the single best return on this area. The SRE-4 blueprint module maps it to the exam directly, and if the tooling vocabulary is the gap rather than the concepts, Prometheus, Grafana and OpenTelemetry cover the three names most likely to appear in a sentence you are asked to interpret.

On-call and incident practice

☺ Like you're 10: The exam describes one particular way of handling emergencies as though everyone does it that way. Not everyone does.

⚖ Where it bites — SRE-7 (Organizational Impact, including sustainable incident response and blameless post-mortems) and SRE-6 (Anti-fragility), up to 8 of 40.

The syllabus describes a specific, Google-derived model of incident response: a rotation with a primary and a secondary, an escalation policy, pages that mean something and tickets that don't, a structured response with named roles, and a blameless review afterwards that produces tracked action items. If you have carried a pager under something like that model, this whole area is nearly free marks. If you have carried a pager under a different model — or never carried one — it is vocabulary to learn deliberately rather than intuition to lean on.

The vocabulary that shows up undefined

The mean-time family, and why it is contested

The official concept list names three of these specifically — MTTD (mean time to detect), MTTR (mean time to repair/recover) and MTRS (mean time to restore service) — and listing MTRS separately is itself informative, because most practitioner writing collapses everything into MTTR.

Be aware that in the wider industry, MTTR is genuinely ambiguous: different organizations expand the R as repair, recover, restore or resolve, and those measure different intervals ending at different moments. That ambiguity is a real, documented source of confusion in reliability reporting, not a trick. On the exam, answer from the syllabus's definitions rather than your employer's. In a job interview, the better move is to say which definition you are using before you quote a number.

If this section found a gap

Incident management & on-call covers the model the syllabus assumes. Postmortems & blameless culture covers the review that follows, and incident command for large incidents covers the role separation. The incident tabletop drill is the cheapest way to acquire the experience if you have never been on a rotation — it is a rehearsal, and rehearsal is most of what on-call training actually is.

The change, delivery and process vocabulary

☺ Like you're 10: A last set of words the exam uses without stopping to explain — mostly about how software gets released, and how other frameworks talk about the same problems.

⚖ Where it bites — SRE-5 (Tools & Automation, up to 6) and SRE-8 (SRE, Other Frameworks, Trends, up to 4).

Delivery vocabulary

The official v1.1 concept list already names canary testing, automated rollback, immutable infrastructures, auto-scaling, functional and non-functional tests and the software delivery lifecycle. The v1.2 update, per PeopleCert's own training-material notices, added progressive deployments explicitly. You need the release vocabulary at recognition level: what a pipeline is, and the difference between a rolling update (replace instances gradually), blue/green (two full environments, cut traffic across, roll back by cutting back) and a canary (a small slice of real traffic, compared against the baseline before proceeding). The distinction that matters for a best-answer question: blue/green buys you a fast rollback; a canary buys you a comparison — an actual signal about whether the new version is worse, on real traffic, before most users see it. Release engineering & progressive delivery covers all of it.

You also need Kubernetes at reading level — the concept list names it directly. You do not need to operate a cluster, and nothing on the paper will ask you to. You need to be able to read a sentence containing "the orchestrator rescheduled the pod" without stalling. If that sentence stalls you, Kubernetes reliability patterns gives you enough, and this Academy's CKA page describes the proper route if you want more than enough.

Process and framework vocabulary

SRE-8 positions SRE against DevOps, Agile and ITSM. That means a handful of process terms are assumed:

• Incident, problem and change in ITSM terms — an incident is an interruption, a problem is the underlying cause of one or more incidents, a change is a modification to the environment. The distinction is ITIL's, and it is why "incident management" and "problem management" are separate practices.
• The Three Ways — flow, feedback, and continual learning and experimentation, from the DevOps literature. Named directly on the concept list.
• Westrum's organizational typology — pathological (power-oriented, messengers get shot), bureaucratic (rule-oriented, information travels through channels), generative (mission-oriented, information flows to whoever needs it). The concept list names Westrum, "pathological" and "bureaucratic culture" as separate entries, so this is examinable vocabulary rather than background reading. It is also the theoretical backing for why blameless postmortems are a mechanism rather than a nicety.
• The SRE spinoffs — the topic description explicitly mentions Network Reliability Engineering and Customer Reliability Engineering, and the concept list adds Database Reliability Engineering and, unusually, Heritage Reliability Engineering. These are pure vocabulary items: know that they exist and what each one specialises in.

If ITSM is the gap, this Academy's ITIL 4 Foundation page describes the neighbouring credential, and the SRE-8 blueprint module covers exactly what this exam wants from that world — which is considerably less than ITIL itself would want. The SRE-7 module covers the culture material, including Westrum.

Where your intuition will be marked wrong

☺ Like you're 10: Sometimes the exam wants the book's answer, not the true-in-your-job answer. Learn to spot when.

This is the section that separates a working SRE from a working SRE who passes comfortably. Experience helps enormously on this paper — right up until it doesn't, and there are four specific places where it doesn't.

1. When a question names its source, answer from that source

The free official sample paper contains a definition item that explicitly attributes the definition it wants to a named industry survey. Its published answer key selects the terse, technical wording over the more intuitive user-facing one that most practitioners would give. Whether or not you agree with that key, the lesson generalises and is worth internalising: when a question says "according to X," it is testing your recall of X, not your understanding of the concept. Reading past that clause and answering from experience is a reliable way to lose a mark you knew the answer to.

2. Reliability is targeted, not maximised

The same sample paper includes a true/false item on whether the error budget should be spent down over the period, and the published key treats a fully-spent budget as the intended outcome rather than a failure. That surprises people whose instinct is that less downtime is always better. It is, in fact, the core economic argument of the whole discipline: an unspent error budget means you bought reliability nobody asked for, at the cost of the features and velocity you could have bought instead. Reliability economics covers the argument properly, and Google's own error-budget policy is the primary source. Learn the reasoning, not just the answer — it is the thing most likely to come back at you in an interview.

3. "Open book" does not mean what you think it means

PeopleCert's product page states that the SREF is open book and that the only permitted material is the Official Training Materials, whether supplied directly or through an accredited training organization. That is a much narrower permission than it first sounds. Chris McLeod's write-up makes the practical consequence concrete: he did not have the official materials with him and therefore worked from memory throughout, which is the situation almost every self-studier will be in. If you did not buy an accredited course, plan as though it is closed book, because functionally it is. That is exactly the assumption this course's closed-book strategy page is built on, and it is the right one. Also note the arithmetic: 40 questions in 60 minutes is 90 seconds each. Even with materials open in front of you, there is no time to study from them.

4. Two different certifications share this name

Ten questions that find the gap

☺ Like you're 10: Cover the page. Answer out loud. The ones you can't answer are the ones worth a week.

Deliberately not multiple choice. Recognising the right option is exactly the skill that hides a baseline gap, and this course already gives you plenty of that in the exam simulator, the practice question bank and five mock exams. Answer each of these in a sentence or two, from memory, before opening the key. Track which baseline area each miss belongs to — that mapping is the output of the exercise, not the score.

1. (Arithmetic) A team has a monthly availability SLO of 99.9%. How many minutes of error budget is that? Now say what changes if the window is a rolling 30 days rather than a calendar month.
2. (Arithmetic) A service handles 20 million requests a month against a 99.9% success SLO. How many failed requests may it spend? Exactly halfway through the window it has spent 14,000. What is its burn rate, and is it on track?
3. (Distributed systems) One downstream dependency gets slow. Your service starts failing requests that never touch that dependency at all. Name the mechanism, and give two mitigations.
4. (Distributed systems) Mean latency is unchanged; p99 has doubled. What can that mean? And why can you not compute a service's overall p99 by averaging the p99s of its instances?
5. (Monitoring) Define a metric, an SLI, an SLO and an SLA in one sentence each. Which one has money attached, and which of the SLO and SLA is normally the tighter number?
6. (Monitoring) Name the four golden signals. Which of them is measured at the resource rather than at the request, and why is it the one most often missing from a dashboard?
7. (Linux / toil) A cron job restarts a service every night at three and nobody remembers why. Apply the definition of toil and give a verdict — then say what the right fix is and why the cron job is not it.
8. (On-call) What do MTTD, MTTR and MTRS each measure? Give one concrete reason a team's MTTR can fall while users are having a worse time.
9. (Delivery) Blue/green versus canary: what does each one actually reduce, and which of the two gives you evidence rather than just an escape route?
10. (Process) A team's incident reviews name an individual in the summary line. Which of Westrum's organizational types does that indicate, and what does it cost the organization in practical terms?

Score yourself — the baseline self-test

☺ Like you're 10: Tick only what you could genuinely do right now. The empty boxes are the useful part.

Two tiers, for the two standards from the top of this page. Tier 1 is the vocabulary floor — the standard the exam actually applies. If you cannot tick these, blueprint study will be uphill, because you will be translating rather than learning. Tier 2 is the production floor — each item asks whether you have done a thing, not whether you could describe it. Be strict with yourself on Tier 2 in particular; it is the tier that decides the last two options on a best-answer question, and the one nobody can bluff in an interview. Your ticks are saved on this device.

Tier 1 — the vocabulary floor

• ① Measurement & arithmetic
• Convert any availability target into minutes per 30-day month without a calculator
• State the error-budget formula in both its time form and its request form
• Define burn rate and say what a 1× burn rate means at the end of a window
• Distinguish SLI, SLO and SLA in one sentence each, and say which has money attached
• Explain why an unspent error budget is a signal, not a win
• ② Distributed-systems behaviour
• Explain what p99 latency is, and why you cannot average two p99s
• Describe how retries without backoff turn a slow dependency into an outage
• Name the mechanism by which one slow dependency fails requests that never touch it
• Say what idempotency is and why automated remediation depends on it
• Explain why latency rises non-linearly as a resource approaches full
• ③ Monitoring & telemetry
• Name the four golden signals and say which is measured at the resource, not the request
• Distinguish a counter, a gauge and a histogram, and say which one percentiles come from
• Explain symptom-based versus cause-based alerting and which one should page
• Say what cardinality is and why it constrains what you can put in a label
• Distinguish black-box from white-box monitoring by what each can and cannot see
• ④ Operations & process vocabulary
• Apply the definition of toil to a real recurring task and get the verdict right
• Say what MTTD, MTTR and MTRS each measure, and why MTTR is ambiguous in the wild
• Name the roles in a structured incident response and say who decides what
• Distinguish an incident, a problem and a change in ITSM terms
• Name Westrum's three organizational types and say which a named-and-blamed postmortem indicates

Tier 2 — the production floor

• ⑤ Things you have actually done
• Carried a production pager for a real service, on a real rotation
• Been paged for something that turned out to be an alert problem, not a service problem
• Written or substantially edited a runbook that somebody else then used
• Read a dashboard mid-incident and worked out which signal was lying
• Defined an SLI for a real service and argued with someone about the threshold
• Automated a recurring manual task and watched it run unattended for a month
• Contributed to a postmortem whose action items had owners and dates — and were done
• Watched a rollout be stopped by an automated signal rather than by a human noticing
• ⑥ Judgement and reading
• Look at a latency graph and say whether the problem is the service or its dependency
• Read a proposed SLO and explain why the number is wrong for that business
• Tell a page that should exist from one that should have been a ticket
• Identify what a scenario question is testing before you read the options
• Answer a "BEST" question by ranking four workable options, not by eliminating wrong ones
• Spot when a question names its source and answer from that source rather than experience
• Hold a 90-seconds-per-question pace without rushing the last ten

What your score means

Count the unticked boxes in each tier separately. The gaps are the signal; a combined total tells you nothing useful, because the two tiers fail in completely different ways and are closed by completely different work.

Closing the gaps you found

☺ Like you're 10: You now have a specific list. Fix the things on it — don't start the whole course over.

Resist the urge to re-read everything. You have a named list of gaps, and named lists are closed by specific work rather than by general study.

For vocabulary gaps

Say the item out loud, from memory, in one paragraph — then check it against the section above and mark what came out thin. That retrieval loop is the entire method, and it is what the closed-book strategy page builds a schedule around. The flashcards and the glossary are for the terms you keep dropping; Know It Cold is the shortlist of definitions that have to be exact rather than approximately right; and the concept reference is the lookup when a term needs more than a card. Print the official concept list alongside them and use it as your checklist of record — it is the exam's own inventory, and nothing this course writes outranks it.

For production gaps

Experience is only ever built one way, but it can be simulated more cheaply than people expect. The toil audit makes you apply a definition to your own week. The SLO and error-budget drill makes you compute a budget for something real. The incident tabletop is a rehearsal you can run at a desk with colleagues, which is most of what on-call training actually is anywhere. The alert-design drill and the postmortem-writing drill close the two most common Tier 2 gaps on this page. And if you want the whole arc rather than a piece of it, the reliability capstone runs from defining SLOs through building monitoring to an incident and its postmortem, in order.

Then, and only then, start the blueprint

Once this page's boxes are ticked, everything downstream gets cheaper — because "error budget" is now arithmetic you can do rather than a phrase you recognise, "saturation" is a thing you have watched fill up, "toil" is a task you can name from last Tuesday, and "blameless" is a mechanism with a reason rather than a nice sentiment. That is the whole return on this week: not new knowledge, but the disappearance of the quiet translation cost that makes foundation-level study feel harder than it is. Go to SRE-1 and work forward, or straight to SRE-2 and SRE-4 if you want the heaviest areas first.