Practice · Monitoring & SRE Tools
This page is the focused practice deck for Module 4 — Monitoring & Service Level Indicators and Module 5 — SRE Tools & Automation: sixteen single-best-answer questions, eight per module, in the exact closed-book shape the real SREF uses — one correct option, three plausible distractors, and a full worked explanation underneath every single question, not just the ones you miss. Where the full mock exams spread five questions per module across all eight to simulate the real sitting, this page stays inside just these two modules and goes deeper on each — enough repetitions that the monitoring-vs-observability trap and the runbook-automation-vs-autonomous-remediation trap stop being traps at all.
Module 4 was about building good sensors — knowing what a percentage like "99.9% good" actually measures and where it came from. Module 5 is about who's allowed to act on what those sensors say — a person reading instructions off a wall, a person clicking a button, or a machine that notices and fixes things entirely on its own. This page is sixteen pop quiz questions split evenly between those two ideas, closed-book, with the teacher's explanation printed right under every single answer instead of hidden in a separate book at the back.
How to drill this bank
☺ Like you're 10: Cover the answer, actually decide, then look — reading the explanation first feels like studying and isn't.
Read each stem once, commit to an answer before you touch the <details> toggle, and only then open the explanation — treating it as a spoiler you peek at mid-question defeats the entire point of a closed-book drill. The real SREF gives you 90 seconds per question on average across all forty; hold yourself to roughly the same pace here even though this set is untimed, because the skill you're building is fast, confident recall under a clock, not slow, correct recall with no clock at all. Background reading for both modules lives at Monitoring & observability and the SRE toolchain if a question below reveals a gap worth going back to fill before you continue.
Sit all sixteen back to back, no notes, no browser tab open on anything but this page. Give yourself roughly 90 seconds per question — the same average the real 40-question, 60-minute paper allows — and flag rather than agonize over anything that runs long. Score yourself out of 16 and treat anything under 13 (81%, well above the exam's own 65% bar) as a signal to reread the matching section of Module 4 or Module 5 before you move on to the SLO & toil set or the anti-fragility & culture set.
Module 4 — Monitoring & Service Level Indicators
☺ Like you're 10: Eight questions about where a percentage like "99.9% good" actually comes from, and the two words — monitoring and observability — the exam refuses to let you use interchangeably.
These eight track Module 4 in the order that page teaches it: the monitoring-vs-observability distinction first, then the two ways raw telemetry gets sourced, then the two ways it gets aggregated into a ratio, then the four golden signals, then the PromQL mechanics an SLI recording rule actually runs on, and finally the quiet hygiene mistake — counting the wrong traffic as "valid" — that corrupts a technically-correct-looking SLI without anyone noticing until a postmortem.
"We have dashboards, therefore we have observability" is the trap the exam returns to more than any other line in Module 4. The three pillars — metrics, logs, traces — are necessary for observability but not sufficient for it. The actual test, repeated three separate ways below (Q1 directly, and implicitly in Q4 and Q7), is behavioral: can an engineer answer a question nobody anticipated, using data already collected, without shipping new code first? If the honest answer is "we'd need to add a metric and redeploy," that system is monitored, not observable — no matter how many panels the dashboard has.
Q1 (Monitoring vs. observability). An SRE lead points at a Grafana instance with thirty-eight panels and says the platform is "fully observable." What is the correct test of that claim?
- A. Whether the dashboard has more than 30 panels covering the service
- B. Whether every panel has a configured alert threshold attached to it
- C. Whether an engineer can answer a question nobody anticipated in advance, using telemetry already being collected, without shipping new code or a new metric first
- D. Whether the dashboard's refresh interval is under 60 seconds
Check the answer
C. Monitoring is a predefined set of gauges chosen in advance to catch known-unknowns; observability is a property of the system's telemetry that lets you answer unanticipated, unknown-unknown questions after the fact. A panel count, an alert-threshold count, and a refresh interval are all monitoring-quality signals — real and worth having, but none of them is the actual test. If answering a new question requires deploying new instrumentation first, the system was monitored, not observed.
Q2 (Black-box vs. white-box sources). A checkout service's internal application metrics all read healthy — no elevated error rate, no latency spike — while real users are unable to complete checkout at all, because the load balancer in front of the service is silently dropping connections. Which monitoring source would have caught this, and why did the application's own white-box metrics miss it?
- A. White-box monitoring, because internal metrics always catch load-balancer failures eventually
- B. Black-box monitoring, because a synthetic external probe tests the system exactly the way a real user reaches it — including everything in front of the application, like DNS, the load balancer, and TLS — none of which the application's own internal instrumentation can see
- C. Windows-based SLI aggregation, because it tolerates a single bad minute better than request-based aggregation does
- D. Saturation monitoring, because CPU and memory usage would have spiked first
Check the answer
B. White-box telemetry is generated from inside the application, so it is structurally blind to anything that fails before a request ever reaches the app's own code — a misconfigured load balancer, an expired certificate, a DNS problem. Black-box monitoring — a synthetic probe hitting the checkout endpoint from outside, the way a real user does — sees exactly the failure a user sees, regardless of where in the path it happened. This is the concrete, textbook reason a well-monitored service needs both sources, not one or the other.
Q3 (SLI aggregation — request- vs. windows-based). A nightly batch ETL pipeline doesn't produce a clean stream of individually countable HTTP-style events; the team instead wants to say "this job's run was healthy" or "unhealthy" for each scheduled execution window. Which SLI aggregation approach fits, and what does it actually compute?
- A. Request-based — good events ÷ valid events, counted per discrete request
- B. Windows-based — each fixed time interval is scored good or bad as a whole against a per-window threshold, and the SLI becomes good windows ÷ total windows
- C. Black-box aggregation — an external probe scores the whole pipeline once per day
- D. Saturation-based — CPU and memory usage averaged across the run
Check the answer
B. Windows-based SLIs exist precisely for systems that don't produce a clean stream of discrete, individually-countable events the way an HTTP API does — batch pipelines and streaming jobs are the canonical examples. Each window (here, each scheduled run) is scored good or bad as a unit, and the ratio is good windows over total windows, rather than good events over valid events.
Q4 (The four golden signals). Latency, traffic, errors, and saturation are Google's four golden signals, and all four deserve a dashboard and usually an alert. Which one should almost never be promoted directly into an SLI on its own, and why?
- A. Latency, because it varies too much to measure reliably
- B. Traffic, because it has no failure mode of its own
- C. Errors, because error rates are usually too noisy to threshold
- D. Saturation, because users don't experience it directly — they feel the latency and error-rate consequences a moment after a resource fills up, which is what a good SLI should measure instead
Check the answer
D. Saturation — how full a resource is relative to its limit (CPU, memory, queue depth, connection-pool usage) — is essential to watch and often worth paging an engineer on, but a good SLI measures what the user actually feels. Users don't feel your CPU utilization directly; they feel the latency spike or error it eventually produces. Promoting a raw saturation number straight into an SLI skips the translation step the exam expects you to know is missing.
Q5 (PromQL mechanics — order of operations). An engineer writes sum(http_requests_total{code=~"5.."}) / sum(http_requests_total) as an error-rate SLI query. It works fine most of the time, but spikes to nonsensical values every time a pod restarts. What's the mistake?
- A. The query is missing a
by (route)clause - B. Counters must be passed through
rate()before they're summed — summing raw counters and dividing directly breaks the moment any underlying series resets on a pod restart, since a counter reset makes the raw value briefly meaningless as an absolute count - C. The query needs
histogram_quantileinstead of plain division - D. The metric should be windows-based instead of request-based
Check the answer
B. A Prometheus counter only ever increases during a process's lifetime and resets to zero when that process restarts. rate() is specifically designed to handle that reset correctly per series, producing a smooth per-second rate; summing and dividing the raw counter values directly, with no rate(), means a restart produces a nonsensical instantaneous drop or spike in the ratio. The fix is always rate() first, sum() second.
Q6 (PromQL mechanics — histogram_quantile). A team writes histogram_quantile(0.99, sum by (service) (rate(http_request_duration_seconds_bucket[5m]))) to get p99 latency, and it returns no data at all even though the raw _bucket series clearly exist in Prometheus. What's the most likely cause?
- A. The recording interval is too short
- B. The
lelabel was dropped by thesum by (service)clause —histogram_quantileneeds thele(bucket boundary) label to still be present on the series it's given, so it must be included in theby (...)list - C.
rate()should not be used on a histogram metric - D. The bucket metric needs to be windows-based first
Check the answer
B. histogram_quantile works by reading the le label on each bucket series to know where each bucket's upper boundary sits. sum by (service) (...) collapses every label not named in the parentheses — including le — so the function is left with nothing to compute a quantile from and silently returns empty. The fix is sum by (le, service) (...), keeping le in the grouping every single time.
Q7 (Good vs. valid — SLI hygiene). A checkout availability SLI is defined as non-5xx responses ÷ all responses on the /checkout route, but a load balancer's health-check probe also hits /checkout every five seconds and is included in both the numerator and the denominator. What effect does this have on the reported SLI, and what's the fix?
- A. No effect — health-check traffic is negligible in volume
- B. It artificially inflates the SLI, because health-check pings almost never fail the way real user traffic does, so they dilute the true user-facing failure rate — the fix is to filter the query to only count genuine user requests as "valid"
- C. It deflates the SLI, making the service look worse than it is
- D. It automatically converts the SLI from request-based to windows-based
Check the answer
B. A load-balancer health check almost always succeeds — that is its entire job. Counting a large volume of near-perfect synthetic traffic in the same denominator as genuine, occasionally-failing user traffic mathematically pulls the ratio toward "good," making the service look more reliable to users than it actually is. The fix is a label filter (excluding the health-check user-agent, source IP, or a distinct health-check path) so "valid" means only real user-facing requests.
Q8 (Request- vs. windows-based — the trade-off). Which statement correctly compares a request-based SLI to a windows-based SLI computed over the same underlying traffic?
- A. Windows-based is strictly more accurate in every case
- B. A request-based SLI lets any single bad event count directly against the ratio, while a windows-based SLI can let one bad request inside an otherwise-healthy time window pass without sinking that window's score — a deliberately gentler aggregation
- C. The two are mathematically identical for any traffic pattern
- D. Windows-based aggregation cannot be applied to an HTTP API
Check the answer
B. Request-based scores every discrete event individually, so one failed request is one failed unit in the ratio, full stop. Windows-based scores an entire fixed interval as a single pass/fail unit against a per-window threshold, so a single slow or failed request inside an otherwise-compliant window doesn't automatically fail that window — a real trade-off, not a strict improvement. Neither statement about universal accuracy or exclusivity to non-HTTP systems is correct; windows-based aggregation is a design choice, not a system-type restriction.
Module 5 — SRE Tools & Automation
☺ Like you're 10: Eight questions about two things only — which rung of the automation ladder a story describes, and which drawer of the toolbox a tool belongs in — because those are the two ideas this whole domain actually tests.
Module 5 is the domain candidates most often study in the wrong direction, memorizing vendor names instead of the two questions the exam actually asks: who decided to act (the four-rung automation maturity ladder), and what does this tool compute (one of five functional toolchain categories). These eight questions drill both directly, plus the guardrails a system needs before it's trusted to act without a human approval gate.
Q9 (Automation ladder — rung 1). A wiki page lists seven exact commands an on-call engineer must type, in order, by hand, to fail a database over to its replica during an incident. No part of this is scripted. What rung of the automation maturity ladder is this?
- A. Runbook
- B. Runbook automation
- C. Human-approved (semi-autonomous) remediation
- D. Autonomous remediation (self-healing)
Check the answer
A. A human notices the problem, a human decides to act, and a human types every command by hand — nothing here is scripted or automated in any way. This is rung 1, a runbook, whose entire value is consistency: even an engineer three weeks into the job can follow the same steps correctly at 3am.
Q10 (Automation ladder — rung 3). During a rollout, a canary-analysis tool detects a metric regression and automatically posts a message to the on-call Slack channel: "checkout p99 latency breached threshold — recommend rollback to v2.3.1 — react ✅ to proceed." An engineer reacts, and only then does the rollback execute. What rung is this?
- A. Runbook automation, because a script performs the rollback
- B. Human-approved (semi-autonomous) remediation — the system itself detected the anomaly and proposed the specific fix, but a human still had to approve execution before anything changed
- C. Autonomous remediation, because the detection was fully automatic
- D. This cannot be placed on the ladder without knowing which chaos-engineering tool triggered the analysis
Check the answer
B. The decision splits in exactly the way rung 3 describes: the system decides what should happen (propose the specific rollback), but a human still decides whether it actually happens (the ✅ reaction). Runbook automation (rung 2) still requires a human to notice the problem and initiate the response in the first place — here, the system did the noticing and the proposing on its own, which is what pushes it to rung 3, not rung 2.
Q11 (Automation ladder — rung 4). Argo Rollouts runs an automated metric analysis during a canary release. The moment the analysis breaches its configured failureLimit, Argo Rollouts itself aborts the rollout and shifts traffic back to the stable version — with no button click, approval, or human review of any kind before the action completes. What rung is this?
- A. Runbook automation
- B. Human-approved remediation
- C. Autonomous remediation (self-healing) — the system detects, decides, and executes on its own, notifying a human only after the fact rather than asking beforehand
- D. This is not automation at all, since Argo Rollouts is a delivery tool, not an SRE tool
Check the answer
C. No human notices, decides, or approves anything before the rollback happens — the system's own analysis triggers the action directly, and a human only finds out afterward. This is rung 4 by definition. Being built for progressive delivery doesn't disqualify a tool from also being an automation-maturity example; the ladder is about the decision structure of the action, not which product category the tool markets itself under.
Q12 (Guardrails — the lesson of Knight Capital). Knight Capital Group's August 2012 trading incident — where a botched deployment left old test code live on one of eight production servers, executing unreviewed trades for roughly 45 minutes and costing the firm hundreds of millions of dollars — is a case the exam associates with which lesson about automation maturity?
- A. Automation above rung 2 is inherently too dangerous to use in production
- B. Removing a human from the decision loop also removes the human who would otherwise have caught the mistake in real time — which is exactly why guardrails like blast-radius limits, a kill switch, and an audit log are not optional polish on rung-3/4 automation, but the thing that makes the trade defensible
- C. The incident proves chaos engineering should never be run against production systems
- D. The incident shows that runbook automation (rung 2) is always safer than autonomous remediation (rung 4)
Check the answer
B. The exam's point is not "automation is bad" — it's that autonomy has a specific, structural cost: nobody was watching this code execute in real time, because the whole point of automating it was to remove that human step. That cost is exactly why guardrails exist, and a rung-3 or rung-4 system without them is a design that hasn't paid for the speed it's claiming.
Q13 (Guardrails — idempotency). An autonomous pod-restart remediation fires twice within the same second because a flapping alert triggered its detector twice in quick succession. What property must the remediation action itself have to guarantee this doesn't cause two restarts (and double the resulting disruption)?
- A. Idempotency — a retried action produces the same end state as running it once, so firing twice has no worse effect than firing once
- B. Blast-radius limiting — capping how many pods can be restarted per time window
- C. Staged trust — running the automation in propose-only mode before promoting it to fully autonomous
- D. An audit log recording who or what triggered the action
Check the answer
A. Idempotency is specifically the property that a duplicate or retried trigger doesn't compound the action's effect — restarting an already-restarting pod should be a no-op, not a second restart. Blast-radius limiting (B) caps damage across a broader population, not duplicate firings on the same target; an audit log (D) records what happened but doesn't prevent the duplication; staged trust (C) is about promotion between rungs, not about handling retries.
Q14 (Toolchain category — SLO tracking vs. generic dashboarding). A team wants a tool that computes rolling 30-day SLI compliance against a target and automatically evaluates a multi-window burn-rate comparison to decide when to page. Why is "a generic dashboarding tool" the wrong category to name here, even though it could technically be made to plot the same underlying data?
- A. Generic dashboards cannot query Prometheus at all
- B. A generic dashboard has no built-in concept of a rolling compliance window or a multi-window burn-rate comparison — you'd have to hand-build and maintain that math yourself, whereas purpose-built SLO/error-budget tooling computes it natively
- C. Dashboards are read-only and cannot trigger a page under any circumstances
- D. This scenario actually describes a chaos-engineering tool, not a monitoring one
Check the answer
B. A generic dashboard will happily chart whatever PromQL query you hand it, but it has no native understanding of "SLO," "error budget," or "burn rate" — that logic has to be hand-rolled and kept correct by you. Dedicated SLO tooling (the category this scenario describes) exists specifically to compute rolling compliance windows and multi-window burn-rate comparisons as a first-class feature, which is the functional distinction the exam is testing, not whether a dashboard can plot a line at all.
Q15 (Toolchain category — chaos engineering). A tool deliberately and unpredictably terminates production instances, injects network latency, and exhausts memory on live services — not to break things for its own sake, but to verify that autoscaling, failover, and circuit breakers actually work under real conditions rather than only on a whiteboard. Which toolchain category does this describe?
- A. Metrics & monitoring
- B. On-call & paging
- C. Chaos engineering — deliberate, controlled failure injection used to verify resilience mechanisms hold under real conditions
- D. Distributed tracing
Check the answer
C. The defining feature is deliberate, controlled fault injection against a live system in order to test whether the resilience mechanisms you believe exist actually function — this is exactly what separates chaos engineering from every other category on the list, none of which intentionally breaks anything.
Q16 (Toolchain category — distributed tracing). A single slow user request fans out across six microservices, and an engineer needs to see exactly which one of those six downstream calls consumed the most time. Which toolchain category is purpose-built for this, and how does it work?
- A. Metrics & monitoring — aggregate numeric time series would show which service's dashboard looks unusual
- B. Distributed tracing — a tree of individually timed spans, stitched together across all six services by a single propagated request ID, showing exactly where the time went hop by hop
- C. On-call & paging — an escalation policy would route the investigation to the right team
- D. SLO/error-budget tracking — a burn-rate alert would identify the slow service
Check the answer
B. Distributed tracing exists specifically for this shape of question — not "is something slow" (which metrics can already tell you) but "which specific hop, in which specific service, in this specific request, was slow." A propagated trace ID ties spans from all six services into one tree, and the width of each span shows exactly where the time went. Metrics, paging, and SLO tracking all matter to the incident but none of them localizes the fault the way a trace does.
Benny the Beaver: I got Q10 wrong — I called the Slack-approval rollback "runbook automation." It has a script behind it, doesn't it?
Nutty the Squirrel: Wrong drawer, Benny. Every rung from two up has a script behind it — that's not the question. The question is who decided to trigger it. Here the system proposed the fix on its own. That's rung three.
Ellie the Elephant: And I nearly missed Q7 the same way — I read "checkout SLI" and assumed the denominator was clean. It wasn't. The health check was quietly sitting inside "valid" the whole time.
Foxy: So the trap isn't the math. It's assuming the inputs to the math are already correct.
Timmy the Turtle: Which is exactly why I never trust a number in a postmortem until someone's checked what's actually inside "valid." Sixteen questions, and that's the one line worth keeping.
Benny the Beaver: Fine. Rung, then category, then check what's actually inside the ratio. In that order, every time.
Score yourself honestly — 13 or better out of 16 clears the real exam's own 65% bar with real room to spare. If Module 4 or Module 5 was the weaker half, go back to the Module 4 blueprint or the Module 5 blueprint before moving on. From here, continue to Practice · SRE Principles, SLOs & Toil and Practice · Anti-Fragility & Organizational Impact to cover the remaining six modules, drill Drill — Redesign a Noisy Alert for the hands-on version of the burn-rate reasoning behind Q14, use Answer Triage — SREF to sharpen how you eliminate distractors under time pressure, and when you're ready to see all eight modules in one sitting, move on to the full 40-question mock exam.
1. What is the exam's actual behavioral test for "observability," and why is a large panel count not sufficient on its own? 2. Name the two source methods for building an SLI and the two aggregation methods, and give one concrete reason you'd choose windows-based over request-based. 3. What is the one factor — not "whether a script is involved" — that separates runbook automation from autonomous remediation? 4. Name two guardrails a rung-4 autonomous system needs before it should be trusted, and what each one specifically protects against. 5. When a question names a monitoring or automation tool you don't recognize, what should you read for instead of the product name?
Check your answers
- Whether an engineer can answer a question nobody anticipated, using telemetry already being collected, without shipping new code or a new metric first. A large panel count only proves a lot of known-unknowns were anticipated in advance — it says nothing about whether an unanticipated question could be answered from existing data.
- Sources: black-box (external, no knowledge of internals — synthetic probes) and white-box (internal state the system exposes — metrics, logs, traces). Aggregations: request-based (good events ÷ valid events, scored per discrete event) and windows-based (good windows ÷ total windows, each fixed interval scored as a unit). Windows-based fits systems without a clean stream of discrete, individually countable events — a batch pipeline or streaming job scored "healthy this run" rather than per-request.
- Who decides to trigger the action. Runbook automation still has a human deciding when to run the script; autonomous remediation has the system itself detect and decide, notifying a human only afterward. A script exists at both rungs, which is exactly why "does a script run it" is the wrong question to ask.
- Any two of: blast-radius limits (caps how much damage one bad automated decision can cause per window), a kill switch (disables the automation immediately, independent of what triggered it), an audit log (so an autonomous action shows up in the incident timeline the same way a human action would), idempotency (a retried trigger can't double the action's effect), or staged trust (running propose-only before promoting to fully autonomous).
- What the tool actually computes or does — read the functional description in the stem (does it inject failure? compute a rolling compliance window? stitch spans across services by request ID?) and match it to one of the five categories: metrics & monitoring, distributed tracing, on-call & paging, chaos engineering, or SLO/error-budget tracking. The exam is closed-book specifically so you can't look a vendor name up mid-question — category recognition by function is the only reliable strategy.