Companion question bank for the 4-part tutorial series in this folder: 01-what-is-sre.md, 02-slis-slos-slas.md, 03-error-budgets.md, 04-toil-and-postmortems.md.

Organized by tutorial part, then conceptual → applied/scenario → quick-fire. Answers are intentionally concise — expand verbally in the interview using the diagrams and worked examples from the tutorials.

---

Part 1 Questions: What Is SRE? History, Definition & Comparison

Conceptual#

1. What is SRE, and how does it differ from traditional operations?#

SRE applies software engineering practices to operations problems. Instead of manually keeping systems up, SREs write automation, define measurable reliability targets (SLOs), and treat reliability as a budgetable resource rather than an unlimited requirement. Traditional ops is graded on "keep it up"; SRE is graded on "meet the agreed target — no more, no less." Ben Treynor Sloss's own definition: "SRE is what happens when you ask a software engineer to design an operations team."

2. How is SRE different from DevOps? How does Platform Engineering fit in?#

DevOps is a cultural philosophy describing what should happen — dev and ops collaborating, breaking down silos. SRE is one concrete implementation of that philosophy with specific mechanisms: SLIs/SLOs, error budgets, blameless postmortems, toil budgets. Platform Engineering is a related but distinct discipline focused on building self-service internal developer platforms and "golden paths" so product teams can do the right thing by default; it often collaborates closely with SRE, which owns the reliability outcomes and operational discipline on top of whatever platform exists.

3. Is SRE older or newer than the term "DevOps"?#

SRE is actually older — Google started building SRE teams around 2003, while the term "DevOps" was coined around 2009 at DevOpsDays. It's a common simplification to call SRE "Google's implementation of DevOps," but historically SRE predates the term.

4. What single mental shift does Ben Treynor Sloss's "core insight" describe, and why does it matter?#

Reliability is not a binary "up or down" property — it's a spectrum, and moving further along it costs exponentially more (in engineering time, infrastructure spend, and velocity). This is why SRE explicitly rejects "maximize uptime" as a goal and replaces it with "meet an agreed target" — the entire SLI/SLO/SLA framework (Part 2) is the precise, measurable version of this idea.

5. Name at least five of the SRE book's core principles beyond SLOs and error budgets.#

Embracing risk, eliminating toil, monitoring distributed systems, the evolution of automation (through five stages, ending in autonomous/self-healing), release engineering, simplicity (treated as the root cause of most reliability problems), postmortem culture, and reducing MTTR through deliberate practice (chaos engineering, game days).

6. Could one person or small team realistically do "DevOps," "SRE," and "Platform Engineering" work simultaneously?#

Yes, especially at a small startup — a single small team often writes the deploy pipeline (DevOps), defines and tracks an SLO (SRE), and builds shared infrastructure modules (Platform) all at once. The distinction becomes organizationally significant once a company is large enough that these concerns start pulling in different directions — e.g., a platform team over-optimizing for self-service at the expense of operational discipline — which is exactly when larger orgs split them into separate, deliberately collaborating functions.

Part 2 Questions: SLI/SLO/SLA Framework

Conceptual#

7. Define SLI, SLO, and SLA, and explain how they relate.#

• SLI: a quantitative measurement of user-facing behavior, typically (good events / valid events) × 100.
• SLO: the internal target for that SLI (e.g., 99.9% success rate over 28 days).
• SLA: a contractual promise to customers, tied to the SLO, with financial/legal consequences if missed. Relationship: SLI is measured continuously → compared against the SLO target → the SLA is a subset of the SLO made external and contractual, usually set looser than the internal SLO to provide a safety buffer.

8. What are the two parts of a well-specified SLI, and why does the distinction matter?#

Specification (what counts as a "good"/"valid" event, conceptually — agreed with stakeholders) and implementation (how it's actually computed/collected — an engineering detail). The distinction matters because the implementation can change (e.g., switching from log-based metrics to a service mesh sidecar) without changing what was promised to stakeholders.

9. Where should you measure an availability SLI, and what's the tradeoff?#

Ideally as close to the real user as possible (client-side/RUM), since that's most accurate but hardest to instrument. Load balancer/edge is a common practical compromise — close to the user, easy to instrument, but misses client-side network/DNS issues. Application-level is easiest to instrument but has a critical blind spot: it misses failures before the request even reaches the app (DNS failure, LB outage, network partition) — a classic gotcha many candidates miss.

10. Why doesn't SRE target 100% reliability?#

Three reasons: (1) diminishing returns — each additional "nine" costs exponentially more engineering effort; (2) users often can't perceive the difference above a certain point, since client-side/network failures already introduce noise; (3) chasing 100% kills release velocity by making every change maximally risky and heavily gated, which has its own competitive cost.

11. What's the difference between an SLO and an SLA?#

An SLO is an internal engineering target with no direct financial consequence — a tool for decision-making. An SLA is a customer-facing contract with penalties (credits, refunds, termination rights) if breached. Best practice: set the internal SLO stricter than the SLA so you have a buffer before you're in actual contractual/financial breach.

12. Give the quick mental-math method for calculating allowed downtime from an SLO.#

Allowed downtime = (1 − SLO) × total time in the window. For a 30-day month (43,200 minutes): 99.9% → 43.2 min; 99.99% → 4.32 min; 99% → 432 min (~7.2 hrs). Key pattern: each additional nine divides allowed downtime by 10 — memorize the pattern, not the whole table.

13. Why do storage/durability SLIs typically use far more "nines" than availability SLIs (e.g., 11 nines vs 99.9%)?#

Availability incidents are usually recoverable (retry, wait, failover — the data comes back). Durability incidents (data loss/corruption) are usually permanent and irreversible. Because the cost of failure is qualitatively different, storage systems justify far stricter targets for durability specifically — e.g., AWS S3 and Google Cloud Storage both advertise 99.999999999% (11 nines) annual durability while their availability SLAs sit around 99.9%.

14. What's the difference between a rolling window and a calendar window SLO?#

Rolling window (e.g., trailing 28 days) smoothly slides forward daily, avoiding the "reset to fresh 100% on the 1st" problem and avoiding weekday/weekend skew (28 days = exactly 4 weeks). Calendar window resets on a fixed schedule, aligning with billing/reporting cycles but can mask an incident right before the reset and can psychologically encourage riskier releases right after a reset.

15. Why is 28 days a more common SLO window than 30 days?#

28 days is exactly 4 full weeks, so it always contains the same number of each weekday — avoiding skew from weekday/weekend traffic pattern differences that a 30-day window would introduce inconsistently depending on where the month starts.

16. What happens mathematically when you chain multiple services, each individually meeting a 99.9% SLO, into one user journey?#

Reliabilities multiply, not average. Three services at 99.9% chained sequentially: 0.999³ ≈ 99.7%, which is worse than any individual service's SLO. This is why microservice architectures need higher per-service reliability than a monolith would need to deliver the same end-to-end experience, and why end-to-end journeys should have their own directly-measured SLI (via synthetic transactions) rather than being inferred from individual service SLOs.

17. Should engineering teams write SLOs as code/config rather than just a slide or doc?#

Yes — mature orgs define SLOs as version-controlled config (e.g., YAML specifying the good/valid event queries, target, and window) that directly generates dashboards and alerting rules. This keeps the SLO as living operational infrastructure rather than a static document nobody references.

Applied / Scenario#

18. How would you define an SLI for a checkout API from scratch?#

Identify the user journey step (submit checkout → get confirmation). Define "good event" as HTTP status < 500 AND latency under an agreed threshold (e.g., 400ms), measured as close to the real user as possible. Define "valid events" carefully — exclude synthetic health checks, include only real traffic. Aggregate over a rolling window (e.g., 28 days) to smooth noise.

19. A stakeholder says "why can't we just aim for zero downtime?" How do you respond?#

Walk through: diminishing returns (each nine costs exponentially more), user-perception limits (client-side/network failures already dominate perceived reliability above a certain point), and velocity cost (near-zero-downtime engineering means near-zero deploy velocity, which has its own competitive cost). Propose picking an SLO based on actual user tolerance and competitive benchmarks, backed by the downtime-per-nines table.

20. You inherit a service with no SLOs defined. How do you bootstrap one?#

Measure the SLI historically (e.g., actual availability/latency over the past 90 days) for a realistic baseline instead of guessing. Talk to consumers/product about actual user tolerance. Set an initial SLO slightly below the historical baseline (achievable, not aspirational) so the team isn't immediately in breach, then tighten it over time as reliability work pays off.

21. How would you design SLIs/SLOs for a batch data pipeline, where "availability" doesn't really apply the same way?#

Focus on freshness (e.g., pipeline completion time − data arrival time < 30 minutes) and correctness (e.g., % of rows processed without schema validation errors) instead of a request-based availability SLI. This shows you understand the method (user-centric, measurable, actionable) generalizes beyond request/response services.

22. A customer complains a file was "unavailable for an hour." Your storage SLA promises 11 nines durability but only 99.9% availability. Is this a durability breach?#

No — durability and availability are separate SLIs/SLAs measuring different failure modes. An hour of unavailability doesn't imply data loss, as long as the file is retrievable afterward. This distinction (recoverable vs. permanent failure) is exactly why the two get very different acceptable failure rates.

23. How would you explain SLI/SLO/SLA to a non-technical stakeholder in one sentence each?#

• SLI: "This is the speedometer — what we're actually measuring right now."
• SLO: "This is the speed limit we've set for ourselves internally."
• SLA: "This is the ticket (and fine) we agreed to pay the customer if we're caught going over the contractual limit."

---

Part 3 Questions: Error Budgets

Conceptual#

24. What is an error budget, and how do you calculate it?#

Error budget = 100% − SLO. If SLO = 99.9% over 28 days, the error budget is 0.1% of requests/time, convertible to ~40.32 minutes of allowed full downtime in that window (for an availability SLO) or to a count of allowed bad events (for latency/correctness SLOs, which don't cleanly convert to "minutes").

25. Why can't you always express an error budget as "minutes of downtime"?#

Only pure availability SLOs convert cleanly to a downtime duration. A latency SLO ("99% of requests under 400ms") has an error budget expressed as a count of allowed slow requests, not a time duration — you can't say "X minutes of slow latency" the same way. Interviewers sometimes test whether you blindly apply the downtime framing where it doesn't fit.

26. What is "burn rate," and why is it more useful than a static "% budget remaining" number?#

Burn rate = actual error rate ÷ allowed error rate implied by the SLO. A rate of 1 is sustainable (exhausts exactly at window close); 10 means you'll exhaust a 28-day budget in ~2.8 days. It's more useful than a static remaining-balance snapshot because a healthy-looking remaining percentage can still represent a dangerously fast burn — e.g., 30% remaining but consumed at a rate that would exhaust it in 1 day.

27. Explain multi-window, multi-burn-rate alerting and why it uses two time windows instead of one.#

It evaluates burn rate over both a short window (e.g., 5 min, for fast detection) and a long window (e.g., 1 hour, to confirm it's not just noise) simultaneously — both must exceed the threshold to page. A long-window-only alert is slow to detect severe outages; a short-window-only alert is noisy on transient blips. Requiring both gets fast detection with confirmation. Google's published recipe uses roughly 14.4x burn rate over 1hr+5min for immediate paging, ~6x over 6hr+30min for a lower-urgency page, and ~1x over 3 days for a ticket only.

28. List what typically consumes an error budget, beyond just "outages."#

Unplanned incidents, planned maintenance windows (a real design decision whether these count), risky/bad deploys, downstream dependency failures, deliberate chaos engineering experiments, and capacity-related degradation from unprovisioned traffic spikes.

29. What is an error budget policy, and why must it be pre-agreed rather than decided during an incident?#

It's the tiered set of consequences triggered as budget is consumed (e.g., healthy → watch → constrained → frozen → escalated). It must be pre-agreed by engineering, product, and leadership before it's needed — deciding "what happens now" during an active incident or heated planning meeting turns it back into the same political argument the error budget was meant to eliminate.

30. Why should an error budget policy have graduated tiers instead of a single binary "frozen / not frozen" state?#

A binary policy is brittle — either it's routinely ignored because it's too strict for minor dips, or it's meaningless because it only ever triggers on catastrophic exhaustion. Tiers let the response scale proportionally: increased review rigor at moderate consumption, longer canary durations as it tightens, full freeze only at true exhaustion, with senior escalation for repeated breaches.

31. What should a team do with a large, unused error budget surplus?#

Actively use it, not just enjoy the headroom passively: ship faster (shorter canary durations, bigger release batches) or deliberately run chaos engineering experiments to validate resilience while there's room to absorb the risk. A team that consistently has a huge surplus every quarter may actually be over-engineered/overly conservative relative to its real SLO — worth investigating, not just celebrating.

32. In a multi-team microservices architecture, if Team B's dependency outage causes Team A's SLI to drop, whose error budget gets debited?#

By convention, the consuming team's (Team A's) — because the error budget reflects what the user experienced, and users don't care which internal team caused the problem. This should trigger a cross-team conversation and can motivate defining internal SLOs between teams (Team B promises Team A a specific reliability level) to make dependency risk explicit.

33. Describe Google's actual published error budget policy pattern.#

If a service's error budget is exhausted, feature launches are frozen — except for launches specifically intended to improve reliability — until the service is back within SLO. A named senior stakeholder (e.g., the VP of the affected product area) can grant an exception, but doing so is a visible, logged decision they personally own, which discourages casual overrides.

Applied / Scenario#

34. Your team's error budget is fully exhausted, but Product wants to ship a major feature this week that carries real reliability risk. What do you do?#

Surface the data transparently: current burn, remaining budget, and the error budget policy's default consequence (freeze). Let the pre-agreed policy drive the default decision rather than an ad hoc argument. If leadership overrides, that becomes a documented, conscious risk acceptance — not a silent SLO violation. I'd also propose de-risking options: feature flag, slower canary, or a kill switch to reduce blast radius if it does ship.

35. A dashboard shows 30% error budget remaining, comfortably above your Tier 3 (25%) threshold — but the last 24 hours alone consumed 15% of the total budget. Should the team be worried?#

Yes. That 24-hour consumption implies a burn rate around 28x sustainable pace, which would exhaust the remaining 30% in about a day — even though the static "% remaining" number alone looks only moderately concerning. This is exactly why burn rate trend matters more than a point-in-time balance check, and why alerting should be burn-rate-based, not threshold-based.

36. Two services have identical 99.9% availability SLOs over 28 days. Service A gets 1,000 requests/day, Service B gets 100M requests/day. Both have a 10-minute full outage. Which is in more danger of breaching its SLO?#

Neither is in more danger in SLO-breach terms — for a pure availability SLO, the time-based budget (40.32 min/28 days) is traffic-independent, so a 10-minute outage consumes the same ~24.8% of either service's budget. However, in absolute user-impact terms, Service B's failed-request count from that same outage is vastly larger. The key interview point: SLO breach risk and absolute blast radius are different questions — don't conflate them.

37. How do error budgets change the conversation between Dev and SRE/Ops?#

Without them, "should we slow down and stabilize, or keep shipping" is a subjective, often political argument. With one, it's a shared, objective number both sides agreed to upfront — if budget remains, ship; if it's exhausted, the pre-agreed policy kicks in automatically, moving the debate from opinions to data.

---

Part 4 Questions: Toil & Blameless Postmortems

Conceptual#

38. Define "toil" using all the formal criteria, and explain why all of them typically need to hold.#

Manual, repetitive, automatable, tactical (reactive/interrupt-driven), no enduring value, and scales O(n) with service growth. All criteria generally need to hold — a task that's manual and repetitive but genuinely requires human judgment (e.g., deciding whether to declare a SEV1) is not toil even if it feels similarly tedious; it's legitimate operational work.

39. Is on-call itself toil? What about the diagnostic steps within an on-call response?#

On-call itself is generally not toil, since responding to a novel incident requires judgment a machine can't yet replace. However, the repetitive, identical-every-time sub-steps within it — e.g., always running the same 5 diagnostic commands first — are classic toil and should be automated into a runbook or self-diagnosing alert.

40. What is "overhead" in the SRE book's taxonomy, and how is it different from toil?#

Overhead is administrative work not tied to running a production service (HR paperwork, all-hands meetings) — a real organizational cost, but not something engineering automation can target the way toil can. Don't lump overhead into toil in an interview answer; they're distinct categories with different remedies.

41. What's Google's guideline for toil budget, and what should a team do if it exceeds that threshold?#

No more than 50% of an SRE's time should go to toil. If consistently exceeded, that's an organizational signal (not an individual failing) — options include investing in an automation sprint, adding headcount, or the team refusing to onboard additional services until it's resolved. Notably, SRE teams can and do push back on taking operational ownership of insufficiently automated/reliable services.

42. How would you prioritize which toil to automate first?#

By ROI: (frequency × time-per-occurrence × number of people affected) minus the one-time build cost and ongoing maintenance cost. Not all toil is worth automating — a task that happens once a year and takes 15 minutes probably isn't worth a week of engineering effort; a well-documented runbook can be the more pragmatic investment for rare tasks.

43. What does "blameless" mean in a blameless postmortem, and what's the underlying premise?#

It means the process explicitly avoids attributing fault to an individual, on the premise that, given the information available at the time, the person made a reasonable decision — so the real question is why the system allowed that reasonable decision to become an outage (missing confirmation step, incomplete information, no safety check, unclear docs).

44. Mechanistically, why does blame-focused postmortem culture make future incidents worse, not just "feel bad"?#

Blame → people become defensive/fearful → they avoid necessary risky work or under-report near-misses and mistakes → future postmortems get incomplete/defensive accounts → root cause analysis stays shallow → the real systemic issue never gets fixed → the same class of incident recurs. It's a compounding vicious cycle, not just a morale issue — blameless culture produces structurally better root-cause data because people aren't incentivized to hide information.

45. Walk me through the Five Whys technique, with an example.#

Start from the symptom, keep asking "why" until you reach a systemic/process-level answer rather than stopping at "a human made a mistake." Example: outage → DB ran out of connections → connection pool leak in new deploy → no load test catches pool exhaustion → load testing isn't a CI gate → no one owns load-test infrastructure. The real fix is assigning ownership and adding the CI gate, not "tell the engineer to be more careful." Note: it's a discipline (keep asking why), not a strict five-question rule — sometimes it branches or resolves in three or seven questions.

46. What criteria typically trigger a mandatory postmortem?#

Incidents that breach or significantly consume the error budget; customer-visible impact above a severity threshold (SEV1/SEV2); incidents requiring rollback or emergency manual intervention; near-misses that could have caused significant impact but were caught in time; and any data-loss or security-relevant event regardless of duration.

47. Who should facilitate a postmortem meeting, and why does that choice matter?#

Someone neutral — not the person most involved in causing the incident — so nobody has to simultaneously defend themselves and run an objective discussion. Larger orgs sometimes maintain a rotating pool of trained facilitators specifically for this reason.

48. What makes a good vs bad postmortem action item?#

Good: specific, owned by a named person, has a priority/deadline, tracked in the normal work-tracking system, and targets the system (e.g., "add JSON-schema validation for payment gateway config, enforced in CI"). Bad: vague and behavioral (e.g., "be more careful," "retrain the team") — not actionable, not verifiable, and doesn't fix anything structural.

49. How do you know if a postmortem culture is actually working, versus just producing "postmortem theater"?#

Track meta-metrics: % of action items completed by deadline, and critically, the repeat-incident rate — the % of incidents that are recurrences of a previously postmortemed root cause. A repeat-incident rate that isn't trending toward zero is the strongest signal the process is theater — documents are being written but the systemic fixes aren't happening or aren't effective.

Applied / Scenario#

50. A senior engineer causes an outage by running a destructive command in production. How do you run the postmortem?#

Focus on the systemic gap: why was a destructive command runnable without confirmation/dry-run? Why no permission boundary or approval step for prod-destructive actions? Reconstruct the timeline collaboratively, run a Five Whys to reach the process gap, and assign concrete action items (confirmation prompts, restricted prod write access, staging parity) — not a note about the individual's mistake. Explicitly thank them for reporting quickly and transparently to reinforce blameless culture.

51. During a postmortem, someone says "if Dave had just checked the runbook first, this wouldn't have happened." How do you redirect this?#

Reframe from individual behavior to systemic cause: "Why wasn't checking the runbook the obvious first step? Was it easy to find? Should the alert payload have linked directly to the relevant runbook and didn't?" This turns an unactionable statement about one person into an actionable fix (e.g., "alerts must link directly to their runbook").

52. Your team has written 12 postmortems this quarter, and 4 of them share the same root cause: database connection pool exhaustion. What does this indicate, and what would you do?#

This is the repeat-incident signal — the postmortem process is documenting the same root cause repeatedly without actually fixing it. I'd escalate this above individual postmortem action items into a dedicated P1 reliability project (e.g., a connection pooler like PgBouncer, load-tested sizing, circuit-breaking near exhaustion) rather than another "add monitoring" action item, and flag the pattern to leadership given the repeats.

53. Give an example of toil you've encountered (or expect in an SRE role) and how you'd eliminate it.#

Example: manually rotating expiring TLS certificates by SSHing into hosts. Fix via automation — e.g., cert-manager in Kubernetes or a scheduled job hitting an ACME endpoint, auto-renewing, with alerting only on failure. Frame the answer with the ROI lens: frequency × time × pain, tackling the worst offender first, and measuring the reduction afterward.

54. A team's toil measurement is 30% — well under Google's 50% guideline. Does that alone mean their operational practices are healthy?#

Not necessarily. The measurement could be undercounted (inconsistent ticket tagging, toil silently absorbed by one overworked person rather than spread across the team average). I'd sanity-check methodology, look at the distribution across individuals (not just the average), and cross-reference with on-call burnout self-reports and how much roadmap work is actually shipping vs. being crowded out by uncounted "quick" interrupts.

---

Quick-Fire / Rapid Recall#