Top 30 SRE Interview Questions and Answers
30 multiple-choice questions on SRE, drawn from 30 bites out of the 205 tagged SRE 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.
Question 1 of 30
Which task best fits the SRE definition of toil rather than overhead or engineering project work?
Show the answer
Answer: a · Manually rerunning the same failed batch job every night by hand
Manually rerunning the same job nightly is manual, repetitive, automatable, and scales with the service, the hallmarks of toil. Designing a system is engineering; meetings and interviews are overhead.
Question 2 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
Question 3 of 30
Which of the following best exemplifies 'toil' in an engineering context?
Show the answer
Answer: c · Manually running a script to provision resources for each new customer
Option C perfectly matches the definition of toil: it is manual, repetitive, automatable, tactical, provides no lasting value, and scales linearly with service growth. Option A, attending meetings, is explicitly categorized as 'overhead' rather than toil, as it doesn't scale with service load in the same way.
Read the full bite: Toil: The Repetitive Work That Kills Engineering Velocity
Question 4 of 30
Which statement best captures the relationship between SRE and DevOps?
Show the answer
Answer: a · SRE is a prescriptive implementation of the broader DevOps philosophy
SRE provides concrete practices, SLOs, error budgets, blameless postmortems, that implement the abstract DevOps principles. They are complementary, not competing, and they operate at different levels of abstraction.
Question 5 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
Question 6 of 30
Which characteristic is most crucial for an effective Service Level Indicator (SLI)?
Show the answer
Answer: c · It directly reflects the user's experience or perception of service performance.
The card explicitly states that an effective SLI measures what matters to the user, focusing on their experience rather than internal system metrics. Option D describes a common pitfall, as system metrics are causes, not symptoms felt by users, and should not be primary SLIs.
Read the full bite: Service Level Indicators: Measuring What Matters
Question 7 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
Question 8 of 30
What is the best way to prioritize which toil to automate first?
Show the answer
Answer: c · Rank by return on investment, weighing frequency and time saved against automation effort and risk
Prioritizing by ROI, frequency times time saved versus effort and risk, maximizes recovered engineering time. Irritation, ease alone, or script count are poor proxies for actual impact.
Read the full bite: How do you find and eliminate toil systematically?
Question 9 of 30
Which core principle defines the 'blameless' approach in a postmortem?
Show the answer
Answer: b · Human errors are symptoms of systemic issues, and everyone involved acted with good intentions.
The card explicitly states that a blameless postmortem 'assumes that everyone involved in an incident acted with good intentions' and 'treats human error not as the cause of failure, but as a symptom of a deeper, systemic issue.' Option A describes a blame-focused approach, which is the antithesis of a blameless postmortem.
Read the full bite: Blameless Postmortems: Fix Systems, Not Blame
Question 10 of 30
What is the primary reason a service provider's internal Service Level Objective (SLO) is typically set higher than its external Service Level Agreement (SLA)?
Show the answer
Answer: a · To provide a safety margin for the engineering team before contractual penalties are triggered.
The card explicitly states that "The buffer between the SLO and SLA gives engineering a margin for error before a failure costs the company money." This means the higher SLO acts as an internal target that, if met, ensures the external, contractually binding SLA is also met, thus avoiding financial penalties. Option D describes a potential positive outcome, but not the primary strategic reason for the buffer from the provider's perspective.
Read the full bite: Service Level Agreement (SLA): The Contract Behind Uptime
Question 11 of 30
What fundamentally distinguishes the SRE response to a recurring high-volume alert from a traditional ops response?
Show the answer
Answer: a · SRE treats it as a defect to automate or eliminate so effort scales sublinearly with load
SRE applies software engineering to remove the recurring work entirely, breaking the link between load and headcount. Faster manual response, more dashboards, or more engineers are the linear-scaling ops pattern SRE avoids.
Read the full bite: SRE vs traditional ops on a recurring alert?
Question 12 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
Question 13 of 30
What is the main drawback of over-instrumenting an application with telemetry?
Show the answer
Answer: a · It creates excessive data, increasing storage costs and performance overhead.
The card explicitly states that over-instrumentation generates a 'massive volume of data that is expensive to store and process, and can even add performance overhead.' While too much data can make identification harder, the primary risk highlighted is the cost and performance impact.
Read the full bite: Code Instrumentation: Making Your App Observable
Question 14 of 30
What is the primary purpose of a health check endpoint, distinguishing it from merely confirming a service process is running?
Show the answer
Answer: d · To allow external systems to detect if the service can perform its core functions and route traffic accordingly.
The card explicitly states that a health check answers 'Can you do your job?', enabling load balancers and orchestrators to stop routing traffic to sick instances. Options A and D are incorrect because health checks provide a binary signal, not detailed metrics or comprehensive logs. Option A is a distractor because while orchestrators may restart services based on health checks, the health check itself provides the signal of functional impairment, not the direct trigger for a restart based solely on resource thresholds.
Read the full bite: Health Checks: Is Your Service Alive or Just Running?
Question 15 of 30
Which set correctly lists the Four Golden Signals for monitoring a user-facing system?
Show the answer
Answer: b · Latency, traffic, errors, and saturation
The Four Golden Signals are latency, traffic, errors, and saturation, focused on user experience and capacity. CPU and memory are resource metrics; logs and traces are observability pillars, not the golden signals.
Question 16 of 30
Which statement accurately describes a limitation of the Four Golden Signals?
Show the answer
Answer: c · They do not provide sufficient detail for identifying the root cause of an issue.
The card explicitly states that the Golden Signals 'tell you that a problem exists... but not necessarily why,' requiring deeper metrics for root cause analysis. Option B is incorrect because they focus on user experience, and options B and C misrepresent their purpose and applicability.
Read the full bite: The Four Golden Signals of Service Monitoring
Question 17 of 30
Which scenario most strongly favors implementing a push-based metrics collection system?
Show the answer
Answer: a · An application deployed as a serverless function that executes for a very short duration.
The card states that push is ideal for "short-lived or ephemeral workloads like serverless functions or batch jobs, as they might terminate before a pull-based scraper can reach them." Option D describes a risk of push systems (the 'thundering herd' problem), not a reason to favor them.
Read the full bite: Pull vs. Push: How Your Metrics Get to the Collector
Question 18 of 30
Why is black-box monitoring usually the faster first step for a legacy app with no internal instrumentation?
Show the answer
Answer: d · It requires no application code changes and shows user-facing symptoms immediately
Black-box probes the system externally, so it needs no instrumentation and quickly reveals whether users are served. It cannot localize root cause or replace white-box signals, which is why those are added later.
Read the full bite: Black-box vs white-box monitoring for legacy apps
Question 19 of 30
When designing metrics for a time-series monitoring system, what is the most critical concern associated with adding a label that has a very large number of unique values (high cardinality)?
Show the answer
Answer: c · It causes the monitoring system's in-memory index to bloat, leading to increased resource consumption and slower queries.
The card explicitly states that high cardinality "bloats this index, consuming RAM and slowing down queries." The canonical example further illustrates how memory usage skyrockets and queries time out, making the system unusable. High cardinality affects performance and resource usage, not the mathematical accuracy of aggregations.
Read the full bite: Cardinality: The Hidden Cost of Time-Series Metrics
Question 20 of 30
In a high-traffic distributed system, which sampling strategy is most effective for ensuring that traces containing critical errors or high latency are reliably captured, despite increased infrastructure overhead?
Show the answer
Answer: a · Tail-based sampling, as it analyzes the complete trace before deciding to keep it.
Tail-based sampling evaluates the entire trace, including its outcome (errors, latency), before deciding to keep it, thus guaranteeing capture of interesting failures. Head-based sampling decides upfront and might discard traces that later become critical, making it unsuitable for reliably capturing all errors in high-traffic systems.
Read the full bite: Sampling: Tracing Everything Without Storing Everything
Question 21 of 30
Beyond reducing noise, what is the strongest argument for paging on symptoms rather than internal causes?
Show the answer
Answer: d · Symptom alerts catch unanticipated failure modes because any cause that hurts users surfaces as a symptom
Symptom alerts fire for any failure that degrades the user experience, including modes you never predicted, while cause alerts only cover anticipated conditions. Cost is minor, cause signals still belong on dashboards, and symptoms still need diagnosis.
Question 22 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
Question 23 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
Question 24 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.
Question 25 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.
Question 26 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
Question 27 of 30
What is the primary advantage of using SLO burn rate alerting compared to a simple alert when the error rate exceeds the SLO threshold?
Show the answer
Answer: c · It enables early detection of both rapid service failures and gradual performance degradations.
SLO burn rate alerting was developed to provide early, actionable warnings for significant events, addressing the limitations of simple threshold alerts which are often too slow for outages and too noisy for minor issues. Option A is incorrect because burn rate monitors consumption rate, it doesn't primarily calculate the total budget. Options C and D describe unrelated functions; burn rate is an alerting mechanism, not an auto-scaler or an SLO definition tool.
Read the full bite: SLO Burn Rate: Alerting on Budget Consumption
Question 28 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
Question 29 of 30
Which scenario, based on an error budget burndown chart, would most clearly signal that an engineering team should prioritize shipping new features?
Show the answer
Answer: b · More than half of the error budget remains available halfway through the monitoring window.
The card explicitly states, "If you have over 50% of your budget left halfway through the month, it's a green light to ship features." While a slower burn rate (option A) is a positive sign, the card provides the remaining budget condition as the direct trigger for prioritizing new features.
Read the full bite: Error Budget Burndown: Your Service's Reliability Fuel Gauge
Question 30 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
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.