Exam Prep · SREF · Mock Exam · Set 1

SREF Mock Exam · Set 1

This is the first of five full-length SREF practice papers on this course, and it's built to do one specific job: prove to yourself that the vocabulary from all eight blueprint modules is actually in your head, under a real clock, before anything harder gets thrown at you. Forty single-best-answer questions, five drawn evenly from each module, sat in one unbroken 60-minute block — the same format, timing, and 65% pass mark as the real SRE Foundation exam. Set 1 skews toward straightforward recall on purpose: definitions, formulas, and the classic classify-this-scenario calls the blueprint pages already walked you through, rather than the layered, multi-step traps later sets will add once this baseline is solid. If you've read the eight blueprint pages, this paper is where you find out which of them you actually absorbed and which you only skimmed.

☺ Explain it like I'm 10

Think of the eight blueprint pages as eight chapters you just studied, one at a time, with plenty of time to reread a paragraph if it didn't click. This page is the pop quiz that covers all eight chapters at once, with the clock running and no going back to reread. It isn't trying to trick you — every question here is the kind of thing a careful read of one chapter already taught you. It's just testing whether "I read it" turned into "I know it," which are two very different things once a timer is involved.

🐢🐰Your hosts for this topic: Timmy the Turtle & Remy the Rabbit — Timmy holds the stopwatch and won't stop it for anything, and Remy is this course's quick-recall specialist, which makes him the exact right host for a paper that's deliberately built to reward instant, correct recall over slow deliberation.

Where Set 1 sits in your SREF prep

☺ Like you're 10: This is the warm-up concert — you've practiced all eight songs separately, and now you play all eight, back to back, for the first time.

The natural sequence on this course is: read the eight blueprint modules one at a time, drill each one's checkpoint until it's automatic, then sit this paper as your first honest measurement of the whole syllabus at once — not a new module's worth of studying, but a stress test of what you already covered. Because DevOps Institute doesn't publish a confirmed per-module weighting for the real exam's 40 questions, this paper deliberately assigns exactly five questions to each of the eight modules, spread across the sitting rather than grouped by topic — the same "study evenly across all eight" guidance every blueprint page already gave you, turned into an actual paper. A low score here is unusually actionable: with five questions per module, a domain you get 1/5 or 2/5 on is telling you precisely where to go back and reread, not just that you "did badly" in some vague sense.

This is Set 1 of five, and the five are not identical in difficulty. This paper is the recall baseline — mostly "define this term" and "classify this scenario" questions in the same shape the blueprint pages already showed you being answered. Later sets in this sequence lean harder into layered scenarios, near-miss distractors, and questions that combine two modules in one stem, the way the real exam's harder half tends to. Sit them in order; treat a strong Set 1 score as permission to move on, not as proof you're exam-ready outright.

Sit it like the real thing

☺ Like you're 10: Real quiz rules: no notes, no browser tab, no calculator except your own head, one hour, go.

The SRE Foundation is closed-book — unlike a performance exam that permits official vendor documentation during the sitting, SREF permits nothing at all once the clock starts: no notes, no browser tab, no this course, no colleague, no AI assistant. That's a meaningfully stricter condition than some other certifications on this platform allow, and it's worth sitting this practice paper the same way rather than quietly loosening the rule "just this once." Close every other tab, put your phone away, and treat the forty questions below exactly as you'd treat them in a locked-down exam environment.

⚠ Format specifics can change — verify before you book

Everything on this page — the 40-question count, the 60-minute duration, the 65% pass mark, and the assumption of no per-module weighting — reflects this course's own certifications page, itself sourced from DevOps Institute's published materials at a point in time. Certification bodies revise format details without much notice. Confirm the current specifics on DevOps Institute's own SRE Foundation page before you register for the real thing — treat this paper as calibrated to that format, not as a substitute for checking it yourself.

One more assumption worth stating plainly, because it changes strategy: most closed-book, single-best-answer foundation-level certifications of this shape do not penalize a wrong answer beyond simply not scoring it — there's ordinarily no separate deduction for guessing. If that holds for the real SREF exam (verify it on DevOps Institute's page before you sit the real thing), the correct strategy is to never leave a question blank. Eliminate what you can, then commit to your best remaining option rather than skipping — a considered guess costs you nothing a blank answer wouldn't have cost you anyway, and it has a real chance of being right.

Your 60-minute budget

☺ Like you're 10: Sixty minutes, forty questions — that's a minute and a half each, but some will take ten seconds and some will take three minutes, so budget by block, not by question.

Forty questions in 60 minutes averages 90 seconds each, but no real exam distributes difficulty evenly across its own numbering, and this paper doesn't pretend to either. The table below splits the sitting into five 8-question blocks — one question from each of the eight modules per block — so you can check your pace against a clean checkpoint roughly every twelve minutes instead of discovering with five minutes left that you're only on question 22.

60 minutes · 40 questions · 65% to pass settle 2m Block 1 Q1–8 · 12 min Block 2 Q9–16 · 12 min Block 3 Q17–24 · 12 min Block 4 Q25–32 · 12 min Block 5 Q33–40 · 10 min flag 2m 0 12 24 36 48 58 60 Every block contains exactly one question from every one of the eight modules — no single block leans on one topic, and no single module can sink the whole sitting.

If a question runs past about 90 seconds without you being confident, don't stall: eliminate the options you can rule out, commit to your best remaining guess, and — since there's ordinarily no penalty for a wrong answer — move on rather than spending a third of a block's budget on one stubborn question. There's no folded solution to peek at mid-paper here the way a task-based practice bank might tempt you with; each question's explanation is directly underneath it, so the only discipline required is not opening it before you've committed to an answer.

The paper — 40 questions in exam order

☺ Like you're 10: Forty questions, five blocks of eight, one from every chapter in every block — read the stem, pick one answer, then check yourself before moving on.

Read each stem once, pick your answer, and only then open the explanation underneath it — treating it as a spoiler you peek at mid-question defeats the entire point of a timed sitting. Each question is tagged with its blueprint module in parentheses so you can total your score by module afterward; on the real exam you won't get that label, so once you've sat this paper for the first time, consider re-reading the stems with the tags covered to see how many you can still place correctly on content alone.

Block 1 — Q1–8 (minutes 0–12)

Q1 (Module 1 — SRE Principles & Practices). Who founded Google's SRE function, and approximately when?

Check the answer

B. Ben Treynor Sloss founded SRE at Google around 2003, staffing a roughly seven-person team almost entirely with software engineers. Debois organized the first devopsdays in 2009 (coining "DevOps"), Forsgren led the DORA research behind Accelerate (2018), and Allspaw's early-2010s Etsy work produced blameless postmortems — all real people and dates the exam likes to swap in as tempting distractors.

Q2 (Module 2 — SLOs & Error Budgets). A company's engineering team sets an internal target of 99.9% for checkout success, and separately signs a contract promising customers 99.5% with service credits for any shortfall. What does the 99.9% figure represent?

Check the answer

B. The internal target set by engineering (and product) is the SLO. The SLA is the external, contractual figure — here, 99.5% with service credits — deliberately set looser than the SLO, which is the healthy pattern. No SLI value is stated in the scenario at all: the SLI is the measurement mechanism itself, not a bare percentage.

Q3 (Module 3 — Reducing Toil). Which of the following is not one of the six properties a task must have to formally qualify as "toil"?

Check the answer

C. The six gates are manual, repetitive, automatable, tactical, no enduring value, and O(n) with growth. "Unpleasant" isn't one of them — a task can feel tedious and still fail the formal definition (or feel routine and still pass it), which is exactly why the exam avoids letting you answer on vibes.

Q4 (Module 4 — Monitoring & SLIs). A team says their forty-panel dashboard proves their system is "observable." What's the correct test of that claim?

Check the answer

C. Monitoring answers predefined, known-unknown questions — a set of gauges chosen in advance. Observability is the system property of being able to answer an unanticipated question from telemetry you already collected. A dashboard with many pre-chosen panels is still just monitoring if answering a new question requires shipping a new metric first.

Q5 (Module 5 — SRE Tools & Automation). A team wires five manual runbook commands into a single Slack-triggered job, but a human still has to click the button to run it. Which rung of the automation maturity ladder does this describe?

Check the answer

B. A human still decides when to act — only the mechanical execution moved into a script. Nothing in the scenario has the system itself detecting or deciding anything on its own, which is what would push it to rung 3 or 4.

Q6 (Module 6 — Anti-Fragility & Learning from Failure). In Taleb's framework, what is the true opposite of "fragile"?

Check the answer

C. Robust is the neutral middle of the spectrum — a shock does nothing at all, neither harming nor improving it. Antifragile is the true opposite of fragile: it actively gains from a stressor. "The opposite of fragile is robust" is the single most common wrong answer this module produces.

Q7 (Module 7 — Organizational Impact of SRE). Which of the four SRE adoption models is defined by an SRE permanently placed inside a single product team, reporting to that team's own engineering manager?

Check the answer

C. Embedded means permanent placement inside one team, with maximum local context — but a real risk that standards and tooling drift team to team, and no local peer for the SRE to escalate a hard problem to.

Q8 (Module 8 — SRE, Other Frameworks & the Future). What changed in ITIL 4 (2019) relative to ITIL v3?

Check the answer

B. ITIL 4 was deliberately redesigned in response to criticism that v3 was too document-heavy and change-advisory-board-driven for cloud-native, continuously-deployed software. "ITIL is the old, slow framework SRE replaced" is an accurate description of v3, not of the current version.

Block 2 — Q9–16 (minutes 12–24)

Q9 (Module 4 — Monitoring & SLIs). Which type of monitoring can catch an expired TLS certificate or a broken load balancer that white-box instrumentation inside the application can never see on its own?

Check the answer

A. Black-box monitoring tests the system from the outside with no knowledge of internals — exactly what a real user experiences — and catches infrastructure-level failures like DNS, load-balancer, and TLS problems that white-box instrumentation, by definition, has no visibility into.

Q10 (Module 7 — Organizational Impact of SRE). What is the single structural fact that distinguishes the "centralized" adoption model from the "consulting" model?

Check the answer

C. Both involve a central SRE function, but centralized is a permanent, ongoing service relationship, while consulting is explicitly temporary and ends with ownership formally handed back to the product team. A scenario with a stated start and end date is consulting, even if the same central team runs it.

Q11 (Module 1 — SRE Principles & Practices). Chronologically, which came first — Google's SRE practice or the term "DevOps" — and by roughly how many years?

Check the answer

C. Treynor Sloss began building SRE around 2003; "DevOps" wasn't coined until 2009, at devopsdays Ghent — roughly six years later. Getting this backwards is one of the most commonly tested Module 1 mistakes.

Q12 (Module 6 — Anti-Fragility & Learning from Failure). Which of the following is the best non-software example of something "robust," in Taleb's sense?

Check the answer

B. A rock or a load-rated bridge resists volatility up to its design limit and stays essentially flat — neither harmed nor improved. Option A is fragile; C and D are antifragile examples, since both actively improve because of the stressor.

Q13 (Module 3 — Reducing Toil). An engineer manually clears a stuck message from a dead-letter queue using the same five steps, three or four times a week, and the underlying producer bug has never been fixed. Is this toil?

Check the answer

A. Manual, recurs weekly (repetitive), fully scriptable with no real judgment (automatable), purely reactive to a page (tactical), the queue ends up exactly where it was (no enduring value), and clearing volume scales with message volume (O(n)). Six for six — toil.

Q14 (Module 8 — SRE, Other Frameworks & the Future). Which two of DORA's four key metrics fall under the "stability" dimension?

Check the answer

B. Deployment Frequency and Lead Time for Changes are the throughput metrics; Change Failure Rate and Time to Restore Service are the stability metrics. DORA's key finding is that elite performers score well on both dimensions at once — speed and stability aren't actually a tradeoff.

Q15 (Module 2 — SLOs & Error Budgets). A service has a 99.95% SLO for availability, measured over a rolling 30-day window (43,200 minutes). What is its approximate error budget?

Check the answer

B. (100% − 99.95%) × 43,200 = 0.05% × 43,200 = 21.6 min. A is the budget for 99.99%, C is for 99.9%, D is for 99% — memorize the shape of this table, not just this one row.

Q16 (Module 5 — SRE Tools & Automation). Which of the following is not one of the guardrails a responsible rung-4 (fully autonomous) remediation system should have before it's trusted to act without human approval?

Check the answer

D. That requirement would put the system back at rung 2 or 3 — a human approving every run is the opposite of autonomous. The real guardrails are blast-radius limits, a kill switch, an audit log, idempotency, and staged trust (propose-only before promoting to fully autonomous).

Block 3 — Q17–24 (minutes 24–36)

Q17 (Module 6 — Anti-Fragility & Learning from Failure). A team runs a chaos experiment that kills one service instance; traffic reroutes cleanly and nobody notices. What does this single clean pass actually demonstrate?

Check the answer

B. A single clean pass proves robustness at that specific blast radius, on that day. Antifragility requires the loop that runs after the experiment — failed hypotheses get root-caused, fixed, and re-verified, so tolerance for a whole class of failure trends upward across many repeated events over time.

Q18 (Module 2 — SLOs & Error Budgets). A checkout API serves 2,000,000 requests over a 30-day window and carries a 99.9% success-rate SLO. What is its error budget for that window?

Check the answer

B. 0.1% × 2,000,000 = 2,000 failed requests, for the entire 30-day window, not per day. Watch for the factor-of-ten slip that produces A, and the scope trap that produces C.

Q19 (Module 8 — SRE, Other Frameworks & the Future). What fifth metric did DORA add to its framework in 2021, and how is it typically measured in practice?

Check the answer

B. DORA added "Reliability" — whether a team meets its own user-defined operational targets — measured in practice through exactly the mechanism Module 2 builds: an SLI, an SLO, and the error budget it creates.

Q20 (Module 1 — SRE Principles & Practices). In the "class SRE implements interface DevOps" framing, which of the following is a concrete mechanism the SRE "class" supplies that the DevOps "interface" never mandates?

Check the answer

B. DevOps (CALMS) sets cultural principles with no mandated mechanism; SRE adds concrete, measurable mechanisms — a formal, enforced error-budget policy chief among them — that DevOps never requires. A, C, and D are all DevOps-level cultural values, not SRE-specific mechanisms.

Q21 (Module 5 — SRE Tools & Automation). A team wants a tool that computes rolling-window SLI compliance against a target, tracks burn rate, and fires multi-window burn-rate alerts. Which toolchain category does this describe?

Check the answer

C. Computing rolling compliance against a target and comparing multiple burn-rate windows is specifically what purpose-built SLO/error-budget tooling exists to do — a generic dashboard could plot the same raw data, but has no built-in concept of a compliance window or a multi-window comparison.

Q22 (Module 4 — Monitoring & SLIs). Of the four golden signals, which one almost never makes a good SLI on its own?

Check the answer

D. Users don't experience your CPU or queue depth directly — they experience the latency and error-rate consequences a moment later. Saturation is essential to watch and alert on, but a good SLI measures what the user actually feels, almost always a translated form of latency or errors.

Q23 (Module 7 — Organizational Impact of SRE). Which of the following is not one of the things on-call needs from the organization, beyond team-level scheduling?

Check the answer

D. A leadership-approved budget line, adequate staffing, and a policy with real leadership backing are the three organizational preconditions this module names. Restricting on-call to only the most senior engineer isn't one of them, and actually undermines a sustainable, broadly shared rotation.

Q24 (Module 3 — Reducing Toil). An SRE spends a day investigating a previously unseen intermittent failure, then ships a new alerting rule that catches the failure mode going forward. Is this toil?

Check the answer

B. A genuinely novel investigation fails "repetitive" outright, and shipping a durable alerting rule fails "no enduring value" — the system is measurably better afterward. This is engineering project work, even though it was unplanned and reactive in the moment.

Block 4 — Q25–32 (minutes 36–48)

Q25 (Module 3 — Reducing Toil). An engineer spends 40 minutes each week filling out a self-assessment form ahead of a quarterly performance review. How should this be classified?

Check the answer

B. The prior question before running the six gates is "is this about operating the production service, or not?" A self-assessment form isn't — it's overhead, and it never even reaches the six-gate test, however recurring or tedious it feels.

Q26 (Module 8 — SRE, Other Frameworks & the Future). What is the key difference between DORA's Change Failure Rate and an SRE error budget?

Check the answer

B. A service can have a low, healthy Change Failure Rate and still be burning its entire error budget on causes CFR was never designed to see — a traffic spike, a bad dependency, a cloud-provider incident, or a config change that wasn't a code deploy at all.

Q27 (Module 5 — SRE Tools & Automation). A tool shows a tree of timed spans across a multi-service call chain, stitched together by a propagated request ID, to reveal exactly where time went for one slow request. Which toolchain category is this?

Check the answer

B. Distributed tracing shows where in a multi-service call chain time actually went, as a tree of timed spans linked by a propagated request ID — a capability that aggregated numeric metrics and discrete log lines don't provide on their own.

Q28 (Module 2 — SLOs & Error Budgets). Which of the following is not something a properly implemented, written error-budget policy is expected to specify in advance?

Check the answer

D. A written policy specifies a trigger, an enforcement action, and an exception path — agreed before anyone is under pressure. Assigning individual blame has no place in a blameless SRE framework and isn't a component of a legitimate error-budget policy.

Q29 (Module 7 — Organizational Impact of SRE). Why does a blameless postmortem culture depend on more than a well-designed document template?

Check the answer

B. The practice depends on engineers believing that reporting a mistake honestly costs them nothing. That belief is destroyed instantly, company-wide, the first time a senior leader blames someone by name — no template recovers from that quickly.

Q30 (Module 1 — SRE Principles & Practices). Which dimension most clearly distinguishes SRE from both traditional operations and DevOps, per the blueprint's three-way comparison?

Check the answer

B. All three practices can involve engineers, on-call, and incident response in some form; the distinguishing governing mechanism is SLOs tied to an explicit, enforced error budget, which neither traditional ops (informal uptime targets) nor DevOps (principles only, no mandated mechanism) has.

Q31 (Module 6 — Anti-Fragility & Learning from Failure). Who coined the term "antifragile," and in which book?

Check the answer

B. Taleb coined "antifragile" in his 2012 book of that name, the third installment of his Incerto series, arguing that English lacked a word for "helped by disorder" even though it had words for "harmed by" (fragile) and "unaffected by" (robust).

Q32 (Module 4 — Monitoring & SLIs). A batch data pipeline doesn't produce a clean stream of individually countable events. Which SLI aggregation approach fits it best?

Check the answer

B. Windows-based SLIs suit systems without a clean stream of discrete countable events — batch pipelines and streaming jobs are the textbook case — scoring good windows ÷ total windows against a per-window threshold instead.

Block 5 — Q33–40 (minutes 48–58)

Q33 (Module 7 — Organizational Impact of SRE). Which of the following is one of the problems that specifically shows up at "SRE at scale" — once dozens of teams practice it simultaneously — but doesn't exist when only one team does?

Check the answer

B. At scale, a steering group or reliability council typically reviews error-budget policy consistently across teams. SLO culture propagation, this governance question, standardized paved-road tooling, and a real SRE career ladder are the four scale-specific problems this module names; the other options are all early, single-team concerns.

Q34 (Module 5 — SRE Tools & Automation). What is the core lesson the exam wants you to draw from the Knight Capital Group's 2012 trading incident?

Check the answer

B. A deployment script failed to update one of eight production servers, leaving dormant test code active and trading live with no real-time human review. The lesson is that removing the human from the loop removes the safety net a human represents — exactly why blast-radius limits, audit logs, and kill switches matter at rungs 3 and 4.

Q35 (Module 4 — Monitoring & SLIs). In the standard SLI formula, what do the numerator and denominator represent?

Check the answer

B. An SLI is a ratio of good events (those meeting the "good" criteria, such as non-5xx and under a latency threshold) to valid events (everything that counts toward the denominator at all, correctly excluding things like health-check traffic).

Q36 (Module 8 — SRE, Other Frameworks & the Future). A vendor markets an AIOps product as offering "fully autonomous, self-healing incident response." What should you check before taking that claim at face value?

Check the answer

B. Most real deployments for judgment-heavy incident response still sit at rung 2 or 3 of the automation maturity ladder — automating the mechanical steps or proposing a fix behind human approval. True rung-4 autonomy remains reserved almost entirely for low-blast-radius, already-well-understood actions.

Q37 (Module 6 — Anti-Fragility & Learning from Failure). A team runs blameless postmortems, but the tracked action items routinely never get finished. What is the practical result?

Check the answer

B. Skipping the follow-through on tracked action items is what practitioners call "postmortem theater" — the paperwork looks right, but no fix actually lands, and the system stays exactly as vulnerable as before, just with better documentation of why.

Q38 (Module 3 — Reducing Toil). A senior engineer manually reviews the diff and approves every production database schema migration, checking specifically for destructive operations. Is this toil?

Check the answer

B. Manual and repetitive, yes — but real judgment that a script can't safely replace fails the "automatable" gate. Don't let "manual + high frequency" override the judgment-call test; if the review were a rubber stamp on anything CI passed, the calculus would change.

Q39 (Module 1 — SRE Principles & Practices). A company renames its existing operations team "Site Reliability Engineering" but keeps the same uptime targets, the same change-approval board, and no error budget. What is this team actually doing?

Check the answer

C. The mechanisms — SLOs, an error budget, a formal freeze policy, a toil ceiling — are what make SRE falsifiable and auditable. A title change without them is traditional ops with new job titles, the single most common failure mode this course warns about.

Q40 (Module 2 — SLOs & Error Budgets). A team's error budget is fully consumed with eleven days left in the window. What does a properly implemented error-budget policy require?

Check the answer

C. This is exactly what the policy exists to enforce. B is the most-tested wrong answer — moving the target to match the failure defeats the entire purpose of having one. A is punitive and off-framework; D ignores the policy as if budget exhaustion carried no consequence at all.

Score yourself

☺ Like you're 10: Count your correct answers, turn it into a percentage against 65%, then look at which module cost you the most points — that second part is the useful part.

Total your correct answers out of 40 for your raw percentage against the 65% pass mark (26 correct or more). Then do the more useful arithmetic: total each module separately out of its five questions. A 30/40 built from five solid modules and a 30/40 built from seven near-perfect modules plus a zero on one are very different results — the second is one bad question draw away from failing the real exam, even though both score the same here.

ModuleQuestions in this paperYour scoreIf under 4/5, go here
1 · SRE Principles & PracticesQ1, Q11, Q20, Q30, Q39/5SRE Principles & Practices
2 · SLOs & Error BudgetsQ2, Q15, Q18, Q28, Q40/5Service Level Objectives & Error Budgets
3 · Reducing ToilQ3, Q13, Q24, Q25, Q38/5Reducing Toil
4 · Monitoring & SLIsQ4, Q9, Q22, Q32, Q35/5Monitoring & Service Level Indicators
5 · SRE Tools & AutomationQ5, Q16, Q21, Q27, Q34/5SRE Tools & Automation
6 · Anti-Fragility & Learning from FailureQ6, Q12, Q17, Q31, Q37/5Anti-Fragility & Learning from Failure
7 · Organizational Impact of SREQ7, Q10, Q23, Q29, Q33/5Organizational Impact of SRE
8 · SRE, Other Frameworks & the FutureQ8, Q14, Q19, Q26, Q36/5SRE, Other Frameworks & the Future
Total40 questions/4065% (26/40) to pass

Beyond the module breakdown, sort your misses into two piles, because on a recall-focused paper like this one they mean different things. A question you got wrong because you genuinely didn't know the term or the formula is a real content gap — reread the linked module and redo the exact question cold in a couple of days. A question you got wrong despite roughly knowing the material — you second-guessed yourself, or ran out of time and guessed under pressure — is a pacing or confidence problem, not a knowledge gap, and the fix is simply sitting more timed papers, not rereading content you already have. If more than a handful of your misses are the second kind, that's exactly what Set 2 is for.

For deeper, module-specific reps beyond a full 40-question sitting, this course's practice banks split the same ground into focused sets: Practice · SRE Principles, SLOs & Toil, Practice · Monitoring & SRE Tools, and Practice · Anti-Fragility & Organizational Impact — plus the full SREF Practice Questions bank and Answer Triage for the general technique of eliminating options by what a term or model structurally can't be, which several of the questions above lean on directly.

🎬 At the Reliability Watch
🐰

Remy the Rabbit: Thirty-four out of forty! Antifragile, toil, SLO math — done, done, done, next!

🐢

Timmy the Turtle: Which module was the zero-out-of-five hiding in, Remy? Thirty-four sounds great until one module ate all six of your misses.

🐰

Remy the Rabbit: ...Organizational Impact. I kept mixing up centralized and consulting.

🦥

Sol the Sloth: That's not a speed problem, then. You answered fast and confidently — you were just confidently wrong on one specific distinction. Reread that one table slowly before you sit anything else.

🦉

Professor Owl: And that's the whole point of scoring by module instead of just by total. Eighty-five percent looks like a pass. It's also hiding the exact page you need to reread tonight.

🐢

Timmy the Turtle: Fix that one gap, then sit Set 2 once it's actually fixed — not before, or you'll just confirm the same gap twice.

✓ Checkpoint

1. Why does this paper assign exactly five questions to each of the eight modules, rather than weighting some modules more heavily? 2. What's the safe assumption about guessing penalties on a closed-book, single-best-answer exam like the SREF, and what strategy follows from it? 3. You score 30/40 overall but 1/5 on one specific module — why is that more actionable than a flat 75% average would suggest? 4. What's the difference between a wrong answer caused by a genuine content gap and one caused by pacing or second-guessing, and why does each need a different fix?

Check your answers
  1. Because DevOps Institute doesn't publish a confirmed per-module weighting for the real SREF exam's 40 questions — treating all eight modules as equally likely, and studying (and testing) them evenly, is the safe assumption every blueprint page on this course already recommends.
  2. Most closed-book, single-best-answer foundation exams of this shape don't deduct extra for a wrong answer beyond simply not scoring it. If that holds, never leave a question blank — eliminate what you can and commit to your best remaining guess, since a considered guess can only help, never hurt, relative to skipping.
  3. Because a flat 75% hides where the gap actually is. A module score of 1/5 is a concentrated, specific content gap you can fix by rereading one page, while a flat, evenly-spread 75% wouldn't tell you where to focus at all — the per-module breakdown converts an average into a diagnosis.
  4. A genuine content gap means you didn't know the term or formula — the fix is rereading the linked module and retesting yourself on it directly. A pacing or confidence miss means you roughly knew the material but ran out of time or talked yourself out of a correct instinct — the fix is sitting more timed papers, not rereading content you already have.

That's the full sitting. Reset the timer, close every tab except this one, and let the forty questions above show you exactly which of the eight blueprint modules is still soft — then go fix precisely that, and nothing else, before you move on to Set 2.

📝 The five sets

Set 1 (you are here) · Set 2 · Set 3 · Set 4 · Set 5. All five are 40 questions, evenly spread across the eight blueprint modules, scored against the same 65% pass mark — later sets lean progressively further from straightforward recall toward layered, multi-step scenario questions. See the SREF study plan for how to sequence all five against your remaining prep time, and the SREF exam for the real thing's day-of logistics.