SREF Mock Exam · Set 4

This is practice paper four of five for the DevOps Institute's SRE Foundation (SREF) exam, and it is built with a different temperament from the first three. An earlier paper might ask "what is an error budget?" This one hands you a specific SLO and a specific number of incident minutes and expects you to work out, on the spot, whether the error-budget policy has actually triggered — the same two-step arithmetic the real exam leans on far more than a glossary quiz would suggest. Forty questions, weighted across the SREF syllabus's eight modules, each with an instant explanation the moment you commit to an answer. Sit Set 1 through Set 3 first if you haven't — they carry the recall-heavy foundation this paper assumes you already have — and keep Set 5 sealed as your final cold run before the real exam.

Where Set 4 fits among the five SREF papers

☺ Like you're 10: Four practice papers built the same way, but this one is the one where knowing the vocabulary stops being enough by itself.

All five SREF papers on this site draw from the same eight-module syllabus and use the same 40-question, 60-minute shape as the real exam, so a score on one is genuinely comparable with a score on another — what changes across the set is the kind of question, not the topics. Sets 1 through 3 lean toward definitions and single-fact recall: what an SLI is, what toil means, what blameless actually requires. Set 4 leans toward scenarios where you're handed two or three numbers and have to combine them correctly before an answer even makes sense. Set 5 is held back as the closest thing to a cold, exam-conditions dress rehearsal.

If you haven't yet worked through the concept reference and at least one earlier paper, this is the wrong page to start on — you'll score badly for the wrong reason and learn little from it. Start with the study plan and how a SREF question is built before sitting anything timed.

Sitting it under real exam conditions

☺ Like you're 10: One clock, no notes, every question answered — the same rules the real exam actually uses.

A mock paper only measures what the conditions you sit it under allow it to measure. The real SREF exam is closed-book — no documentation tab, no second screen, no notes — so a paper worked with a browser tab open somewhere else has measured your search skills, not your readiness.

1. One 60-minute timer, started once. Don't pause it for a phone call or a question you'd rather think about later — the real clock won't pause either.
2. Leave the domain chips on "All 40". Filtering by module during a sitting turns one mixed paper into eight easy little ones; use the chips afterward, for revision, not during.
3. Answer every question. An unanswered question is a guaranteed zero; a considered guess between two options is a coin flip you were offered for free.
4. Commit before you read the explanation. The reveal is instant and generous — read it before choosing and you've converted a test into a reading exercise.
5. Write down every question that surprised you — including ones you got right by luck. Right-for-the-wrong-reason is a gap that will find you again on exam day, in different wording.
6. Don't immediately re-sit. Go and re-derive the arithmetic on the two or three questions that stalled you, then come back and use Shuffle / reset — question order and option order both reshuffle, so you can't pass by remembering which button was green.

How the 40 questions are weighted across the syllabus

☺ Like you're 10: The topic with the trickiest arithmetic gets the most questions, because that's where candidates report the real exam leaning hardest.

With no official percentage weighting to match, this paper's 40 questions are split across the syllabus's eight modules by a study convention rather than a vendor figure: the two modules candidates most often report as arithmetic-heavy on the real exam — Service Level Objectives & Error Budgets and Anti-Fragility & Learning from Failure — carry the largest shares, and the remaining six divide the rest roughly by how much syllabus ground each one covers.

What makes Set 4 harder: multi-step reasoning, not recall

☺ Like you're 10: Almost every question here makes you do two things in your head before you're even allowed to look at the four answers.

Every question on this paper falls into one of five recurring shapes. Learn to name the shape in the first few seconds and you buy yourself real thinking time, because the arithmetic itself is never hard — the only way to lose marks is to skip a step or mix up which number goes where.

• Error-budget-trigger checks. You're given an SLO, a window, and a number of incident minutes, and asked whether the policy has fired. The move is always the same: convert the SLO into an allowed-downtime figure for the window, then compare it against the stated incident total.
• Burn-rate & time-to-exhaustion. You're given a burn-rate multiple and asked how long the budget survives at that rate, or whether the rate clears a named alerting threshold.
• Ratios and percentages. Toil hours over capacity, actionable pages over total pages, failures over requests — always a fraction, always worth writing down as a fraction before picking an answer.
• Timeline arithmetic. Given timestamps, compute MTTD, MTTR, or a rotation's cadence — the trap is almost always using the wrong pair of timestamps for the metric being asked about.
• Composite and weighted calculations. Two components with different traffic and different success rates, asked to blend into one number — the classic wrong answer is a naive, unweighted average.

The alerting rules behind the burn-rate questions on this paper aren't abstract — they're the same shape a real Prometheus alerting rule takes once an SLO is defined. A fast-burn rule for a 99.9% SLO (allowed error fraction 0.001) commonly compares a 1-hour rate against a 5-minute rate, both against a 14.4× multiplier:

- alert: ErrorBudgetFastBurn
  expr: |
    (
      sum(rate(http_requests_total{status=~"5.."}[1h]))
      /
      sum(rate(http_requests_total[1h]))
    ) > (14.4 * 0.001)
    and
    (
      sum(rate(http_requests_total{status=~"5.."}[5m]))
      /
      sum(rate(http_requests_total[5m]))
    ) > (14.4 * 0.001)
  for: 2m
  labels:
    severity: page
  annotations:
    summary: "Fast error-budget burn on checkout — budget gone in ~2 days at this rate"

See multi-window, multi-burn-rate alerting for the full design, and Prometheus for the query language this rule is written in.

The paper — 40 questions

☺ Like you're 10: Pick an answer. It turns green or red right away and tells you why yours was wrong too.

Click an option to lock it in — the correct answer is marked, your mistake (if any) is marked, and the explanation appears underneath immediately. Each explanation covers both the right answer and the most tempting wrong one, because on a reasoning-heavy paper the near-miss is exactly what's worth understanding. The counter and bar above the questions track your progress and score; the chips filter by module for revision afterward; Shuffle / reset reshuffles both the questions and the options and starts a fresh attempt. Your best score is remembered on this device only — nothing is sent anywhere.

Scoring yourself, honestly

☺ Like you're 10: Write down your score per module, not just the one big number at the top.

The counter gives you a raw percentage against the real SREF bar of 65% — 26 out of 40. Treat that number as a thermometer, not a verdict: this paper's wording is ours, not the DevOps Institute's, and it isn't calibrated to the real exam's actual difficulty. What matters more than the headline figure is the shape underneath it.

What to do with the wrong answers

☺ Like you're 10: Keep a list of what you got wrong and why your answer was wrong — that list becomes your whole revision plan.

Whatever you scored, the paper has only done its job if it produces a list. For every miss, write — in your own words — why the option you picked was wrong, not why the correct one was right. That's a different sentence, and a harder one, and it's the sentence that stops you repeating the mistake once the real exam changes the numbers on you.

mkdir -p ~/sref-revision
cat > ~/sref-revision/set4-wrong-answers.md <<'EOF'
# SREF Mock Set 4 — wrong answers

| Q | Module | What I picked | Why MY answer was wrong | Page to re-read |
|---|--------|----------------|--------------------------|------------------|
|   |        |                |                          |                  |
EOF
open ~/sref-revision/set4-wrong-answers.md

After a few papers, sort the rows by module. If most of your misses sit in one module, that's your next afternoon. If they're spread evenly but share a shape — every burn-rate question, say, or every question where you reached for a naive average — you've found something cheaper to fix than a syllabus gap: a habit.

The fastest way to make an error-budget number permanently intuitive is to compute one for a real, if toy, service instead of only ever seeing it in a question stem. Pick any endpoint you can measure locally, decide an SLO for it, and run the arithmetic against a real day of traffic:

SLO=99.9
WINDOW_DAYS=30
python3 -c "
slo = $SLO / 100
window_min = $WINDOW_DAYS * 24 * 60
budget_min = (1 - slo) * window_min
print(f'Window: {window_min:.1f} min, budget: {budget_min:.2f} min')
"

Then compare that budget figure against your own service's actual downtime for the month, exactly like question 7 on this paper — the calculation stops being an exam trick the moment it's attached to a number you watched happen.

Where each module is taught

☺ Like you're 10: Every question here traces back to one of eight pages. Go back to the page, not to a search engine.

Nothing on this paper is examined that isn't taught somewhere in this course. The eight module pages below are the answer key at exam depth.

Around them sits the rest of the SREF kit: the study plan for pacing, the practice-question bank and answer triage for technique, know it cold and the closed-book strategy for the final week, and the shared course tools — the flashcards, the exam simulator, and the glossary for anything a question assumed you already knew. For hands-on repetition rather than more multiple choice, work the SLO & error-budget drill, the capacity-forecast drill, and the chaos-experiment-design drill.