Skip to content
tezvyn:

Top 30 Reliability Interview Questions and Answers

30 multiple-choice questions on Reliability, drawn from 30 bites out of the 101 tagged Reliability on Tezvyn. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

  1. Question 1 of 30

    What is the core philosophy behind Site Reliability Engineering (SRE)?

    Show the answer

    Answer: b · To treat operational challenges as software problems that can be solved through engineering.

    SRE's fundamental principle is to approach operations as a software problem, using engineering to automate and manage systems, as stated in the card. Option D is incorrect because SRE was developed as a new approach to overcome the limitations of traditional operations.

    Read the full bite: Site Reliability Engineering (SRE): Ops as a Software Problem

  2. Question 2 of 30

    Why should an internal SLO target be set stricter than the externally promised SLA?

    Show the answer

    Answer: d · To create a safety margin that triggers internal action before the contract is breached

    A stricter SLO gives early warning so the team reacts before violating the SLA and owing penalties. The other options misstate measurement windows, visibility, and the SLI relationship.

    Read the full bite: SLI vs SLO vs SLA: how do they relate?

  3. Question 3 of 30

    What does it signify if an SRE team consistently operates well within its allocated error budget?

    Show the answer

    Answer: b · The team is being overly cautious, potentially sacrificing innovation for unnecessary stability.

    The card explicitly states that having too much error budget left over signals being "too conservative and slowing innovation," indicating that resources might be better spent on new features or calculated risks. Option D is tempting but incorrect because the card notes that users often cannot perceive the difference between high and extreme reliability, making excessive investment in stability pointless.

    Read the full bite: Embracing Risk: Reliability Is a Budget, Not a Goal

  4. Question 4 of 30

    When defining the first SLIs for a user-facing service, what should they primarily measure?

    Show the answer

    Answer: b · Aspects of the service as experienced by users, such as request success and latency

    Good SLIs reflect user-visible behavior, since the goal is to measure user happiness. CPU and deploy counts are internal signals that can look fine while users suffer.

    Read the full bite: How do you set SLOs for a service from scratch?

  5. Question 5 of 30

    What is the typical immediate consequence when a service's error budget is exhausted?

    Show the answer

    Answer: c · All non-essential feature releases are temporarily halted to prioritize reliability work.

    The card states that exhausting the error budget typically triggers a freeze on non-essential releases, redirecting focus to reliability work. The Service Level Objective (SLO) is the target from which the budget is derived; exhausting the budget means the service is failing to meet the SLO, not that the SLO itself should be changed.

    Read the full bite: Error Budgets: Balancing Reliability and Innovation

  6. Question 6 of 30

    An error budget is fully spent early in the quarter. What is the most appropriate first response?

    Show the answer

    Answer: d · Invoke the pre-agreed error budget policy and analyze what consumed the budget

    The budget is a pre-agreed signal that triggers a policy and a data-driven analysis of the burn. Blaming individuals, a permanent ban, or ignoring it all defeat the budget's purpose as an objective tradeoff tool.

    Read the full bite: Error budget exhausted early: what now?

  7. Question 7 of 30

    Why is blamelessness essential to a postmortem's effectiveness at improving reliability?

    Show the answer

    Answer: c · It creates psychological safety so engineers disclose full, honest details needed to fix systemic causes

    Blamelessness removes fear of punishment so people share complete information, and you can only fix what you fully understand. It does not skip root cause or action items, nor magically prevent recurrence by itself.

    Read the full bite: What makes a blameless postmortem effective?

  8. Question 8 of 30

    To achieve the highest leverage and scale SRE's impact across numerous product teams, which engagement model is most effective?

    Show the answer

    Answer: a · SRE Platform, which provides validated, reliable infrastructure for product teams to build upon.

    The SRE Platform model is described as 'the most scalable model' where SREs build reliable infrastructure for product teams to use, allowing them to inherit reliability by default. While Early Engagement is proactive, it still involves direct SRE consultation per team, which offers less leverage and scalability than a shared platform.

    Read the full bite: SRE Engagement Models: From Gatekeeper to Platform Builder

  9. Question 9 of 30

    Which principle is central to High Availability's ability to maintain continuous service during component failures?

    Show the answer

    Answer: a · Implementing redundant components with automatic failover mechanisms to handle detected outages.

    The core of High Availability involves having redundant components and automatically rerouting traffic to a healthy standby when a primary component fails. Distractor B is incorrect because HA specifically emphasizes automatic failover, not manual intervention.

    Read the full bite: High Availability: Designing Systems That Don't Go Down

  10. Question 10 of 30

    Which operation is LEAST suited for an idempotent design in an automation script?

    Show the answer

    Answer: a · Recording each attempt of a user login into an audit trail.

    The card states that "appending a log entry" is an example of an operation where idempotency is the "wrong goal" because you want "each execution to have a distinct effect." The other options describe tasks (package installation, resource provisioning, schema migration) that are explicitly mentioned as scenarios where idempotency is vital for reliable, repeatable automation.

    Read the full bite: Idempotency: Safe to Retry Automation

  11. Question 11 of 30

    A service updates a database and must then send a critical event. How can you best ensure the event is reliably sent if the database update succeeds, even if the service crashes?

    Show the answer

    Answer: b · Write the event to an 'outbox' table within the same database transaction as the primary update. A separate process then sends events from this table.

    D is correct because writing the event and business data in one atomic transaction guarantees the event is durably saved if the business logic succeeds. B is a common but flawed approach; the service could crash after the commit but before sending the event, losing it forever.

    Read the full bite: Guarantee at-least-once delivery for a critical analytics event?

  12. Question 12 of 30

    Which ACID property guarantees that a committed transaction's effects will survive a server crash that happens immediately after commit?

    Show the answer

    Answer: c · Durability

    Durability ensures committed changes persist to non-volatile storage and survive crashes. Atomicity governs all-or-nothing application before commit, not survival of already-committed data after a crash.

    Read the full bite: The ACID properties of transactions

  13. Question 13 of 30

    According to the error budget concept, when should a development team prioritize reliability work over shipping new features?

    Show the answer

    Answer: a · When the error budget is low or exhausted, indicating a risk to the SLO.

    The card states that when the budget is low or exhausted, all non-essential changes are frozen to focus on reliability. Option B describes the opposite scenario, where a healthy budget allows for new features and experiments, not a shift to prioritizing reliability.

    Read the full bite: Error Budgets: The Currency of Reliability

  14. Question 14 of 30

    What is the primary reason the card advises against using calendar months for SLO time windows?

    Show the answer

    Answer: b · Their varying lengths complicate consistent error budget calculations.

    The card explicitly states that calendar months have 'unequal lengths and complicate budget math,' making a 1% error budget represent different amounts of downtime. This inconsistency makes it difficult to calculate and manage the error budget reliably. Option A is a general issue with long windows, not specific to calendar months' primary drawback.

    Read the full bite: SLO Time Windows: Choosing Your Measurement Period

  15. Question 15 of 30

    Why is an SLA typically set looser than the internal SLO for the same service?

    Show the answer

    Answer: d · To provide internal headroom so an SLO miss does not immediately breach a customer contract

    Keeping the SLA below the SLO gives the team a safety buffer, so missing the internal goal does not instantly trigger contractual penalties. The SLI is the raw metric, the SLO the internal target, and the SLA the external promise.

    Read the full bite: Relationship between SLI, SLO, and SLA

  16. Question 16 of 30

    A team's error budget for the quarter is fully consumed. According to error budget policy, what should typically happen next?

    Show the answer

    Answer: b · Risky feature launches pause and effort shifts toward reliability until the budget recovers

    An exhausted budget triggers the policy to slow risky changes and prioritize reliability work until it recovers, giving the budget real teeth. Lowering the SLO to dodge the breach defeats the purpose, and the budget resets each window rather than halting forever.

    Read the full bite: What is an error budget?

  17. Question 17 of 30

    Which statement best describes the fundamental purpose of an SLO document?

    Show the answer

    Answer: c · To establish a formal, measurable agreement on a service's acceptable reliability, guiding engineering decisions.

    The card defines an SLO document as a "formal contract" that specifies "measurable targets" for reliability, guiding "engineering priorities" and "data-driven decisions." Option C directly reflects this core purpose. The other options describe different types of documentation or tools, not an SLO document.

    Read the full bite: SLO Document: Your Service's Reliability Contract

  18. Question 18 of 30

    What is the recommended starting point when defining SLOs for a new critical service?

    Show the answer

    Answer: c · Identify the critical user journeys and derive SLIs that reflect those experiences

    Good SLOs start from what users actually do, so you map critical journeys first and choose SLIs that capture them, then set realistic targets. Reusing dashboards, copying unrelated services, or matching the SLA all ignore the specific user experience.

    Read the full bite: Defining SLOs for a new critical service

  19. Question 19 of 30

    What is the main argument for counting planned maintenance downtime against the error budget?

    Show the answer

    Answer: b · Users experience the outage regardless of intent, so counting it stays honest and pushes toward zero-downtime methods

    From the user's view a planned outage feels identical to an unplanned one, so counting it keeps the SLI honest and incentivizes zero-downtime techniques. The tradeoff is that it can penalize necessary maintenance, which is why excluded windows are the alternative.

    Read the full bite: Handling planned maintenance in SLOs and error budgets

  20. Question 20 of 30

    Three mandatory backends each have 99.95% availability. Why can the user-facing service not also reach 99.95% from these alone?

    Show the answer

    Answer: c · Because availabilities of serial dependencies multiply, yielding a lower combined number

    For required dependencies in series the availabilities multiply, so 99.95% cubed is about 99.85%, already below target. Each critical dependency must be stricter, or you add redundancy and graceful degradation to break the serial chain.

    Read the full bite: Setting SLOs across a dependency chain

  21. Question 21 of 30

    According to the Write-Ahead Logging (WAL) principle, when does a database record an intended data change in its transaction log?

    Show the answer

    Answer: a · Before the data is modified in the main database files, ensuring the log entry is durable.

    The card states, "The log entry is written before the action is taken. This is called Write-Ahead Logging (WAL)." This ensures that a durable record exists for recovery even if a crash occurs during the actual data modification. Option D is incorrect because log entries are written throughout the transaction, not just at commit, to ensure atomicity and durability.

    Read the full bite: Database Transaction Log: Your System's Safety Net

  22. Question 22 of 30

    A cloud storage service advertises 99.999999999% durability but only 99.9% availability. What does this primarily indicate?

    Show the answer

    Answer: b · While your data is extremely unlikely to be permanently lost, it may experience periods where it cannot be accessed.

    High durability (11 nines) means the data is extremely unlikely to be permanently lost or corrupted. However, 99.9% availability implies that the data might be temporarily unreachable, as availability refers to reachability, not data preservation. Option C is incorrect because 99.9% availability does not guarantee accessibility at all times.

    Read the full bite: Data Durability vs. Availability: Lost vs. Unreachable

  23. Question 23 of 30

    Which client-side strategy best maximizes throughput for a 100 req/min API without triggering excessive 429 errors?

    Show the answer

    Answer: b · Bound concurrency to a small worker pool, proactively pace requests using rate-limit headers, and apply exponential backoff with jitter on 429s.

    The correct answer combines proactive throttling, header-aware dynamic pacing, bounded concurrency, and resilient retries as described in the card. Option A is tempting because it limits concurrency, but it still creates burst traffic and ignores headers, relying on the server to punish the client rather than preventing 429s proactively.

    Read the full bite: Design a rate-limited REST API data collection script

  24. Question 24 of 30

    Which approach should you choose when prompt engineering alone fails to produce valid JSON arguments for a complex tool schema?

    Show the answer

    Answer: a · Combine few-shot CoT prompting, JSON Schema validation, constrained decoding, and retry loops with error feedback

    The correct answer layers user-facing prompts with backend guardrails—schema validation, constrained decoding, and retry loops with error feedback—to provide hard guarantees that prompt engineering alone cannot. Option C is a tempting distractor because simply asking the model to be more careful and using regex extraction offers no assurance of syntactically correct or schema-adherent JSON for nested objects.

    Read the full bite: What fixes an LLM agent's incorrect JSON arguments for a complex tool?

  25. Question 25 of 30

    What is the ultimate goal for an on-call engineer, beyond just responding to immediate alerts?

    Show the answer

    Answer: b · To use operational insights to drive engineering projects that reduce future alerts.

    The card states, "The ultimate goal for an on-call engineer is to use their operational insights to drive engineering projects that make their own future shifts quieter." This highlights the proactive aspect of improving systems to prevent future incidents. While documenting incidents (Option C) is important, it is not the ultimate goal of reducing the need for on-call responses.

    Read the full bite: On-Call Rotations: Engineering Reliability Under Pressure

  26. Question 26 of 30

    Beyond raw page count, which metric best reveals that an on-call rotation is generating unnecessary pain?

    Show the answer

    Answer: b · The fraction of pages that were actually actionable

    A low actionability rate shows engineers are being paged for things that needed no action, the hallmark of avoidable pain. Raw counts and dashboard totals miss whether the pages mattered.

    Read the full bite: Measuring on-call health quantitatively

  27. Question 27 of 30

    During the first minutes of a 5xx spike on a critical service, what should usually take priority?

    Show the answer

    Answer: a · Quantifying impact, then mitigating to stop user pain before root-causing

    Triage prioritizes assessing blast radius and stopping user impact, often via rollback, before deep root-cause work. Reading the diff first leaves users failing while no mitigation is in flight.

    Read the full bite: Triaging a 5xx error spike

  28. Question 28 of 30

    What most distinguishes an effective post-mortem document from an ineffective one?

    Show the answer

    Answer: c · It produces prioritized, owned action items that get tracked to completion

    Effective post-mortems drive recurrence prevention through concrete, owned, tracked action items. Naming an individual undermines the blameless culture that surfaces honest information, and length alone does not produce change.

    Read the full bite: Primary goal and sections of a post-mortem

  29. Question 29 of 30

    A web application is running but temporarily loses its connection to the backend database. To prevent new requests from being routed to this unhealthy instance without restarting it, which Kubernetes probe should be configured to fail?

    Show the answer

    Answer: c · The Readiness probe, to temporarily remove the pod from service endpoints.

    The Readiness probe is designed to stop sending traffic to a pod when it's not ready to serve requests, such as when a database connection is lost, without restarting the container. A Liveness probe failure would cause an unnecessary restart, as the application itself is still running and capable of recovery once again connecting to the database.

    Read the full bite: Kubernetes Probes: Liveness, Readiness, and Startup

  30. Question 30 of 30

    Which factor most strongly argues against a fast full rollback during an incident?

    Show the answer

    Answer: d · The release included an irreversible data migration that rollback cannot safely undo

    An irreversible migration makes rollback unsafe, risking data loss, so a targeted mitigation like a feature flag is preferred. Fast recovery and prior review are arguments for, not against, rolling back.

    Read the full bite: Fast rollback versus targeted fix in an incident

Could you explain these out loud?

That is what an interview actually tests. Tezvyn gives you questions like these with what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon