Top 30 SLO Interview Questions and Answers
30 multiple-choice questions on SLO, drawn from 30 bites out of the 37 tagged SLO 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
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.
Question 2 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 3 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 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?
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
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.
Question 7 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 8 of 30
An upstream service breaches its SLO solely because a downstream dependency had an outage. How should a well-designed error budget policy handle the burn?
Show the answer
Answer: c · Attribute the burn to the downstream service that caused the failure
Correct attribution charges the responsible downstream team, creating proper incentives and shielding the upstream victim. Charging the upstream team, splitting blindly, or ignoring it all distort accountability.
Read the full bite: Error budget policy across dependent microservices?
Question 9 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 10 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 11 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 12 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 13 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 14 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 15 of 30
For an auth API availability SLI, why should legitimate 401 responses for wrong passwords be excluded from the failure count?
Show the answer
Answer: a · Because they represent the system working correctly, not an outage, so counting them penalizes correct behavior
A 401 for a wrong password is the auth system doing its job, so treating it as downtime would distort the SLI and punish correct behavior. Server-side 5xx and timeouts are the real availability failures to count.
Read the full bite: Proposing availability and latency SLIs for an auth API
Question 16 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 17 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 18 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 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
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.
Question 21 of 30
A global availability SLI reads 99.95% but users in one region are angry. What design flaw most likely explains this watermelon SLO?
Show the answer
Answer: b · Over-aggregation across regions lets a localized outage disappear into a healthy global number
Averaging across all regions buries a localized outage affecting a small fraction of users, so the global number stays green while real users suffer. Segmenting by region and journey, and measuring client-side, exposes the hidden pain.
Read the full bite: Fixing watermelon SLOs that hide unhappy users
Question 22 of 30
Which metric best serves as the primary SLI for a 'fast' report export from the user's perspective?
Show the answer
Answer: c · End-to-end latency from click to download-ready, measured at the 95th percentile
End-to-end latency at a percentile directly captures user-perceived tail behavior, whereas average API latency hides outliers and database query time is an internal infrastructure metric, not a user-facing measurement.
Read the full bite: What specific metrics define a 'fast' report export?
Question 23 of 30
Why must you wrap the bucket counter in rate() and use sum by (le) before applying histogram_quantile for p95 latency?
Show the answer
Answer: b · To handle counter resets and aggregate buckets correctly across instances
rate() computes per-second increase and survives counter resets, while sum by (le) aggregates bucket counts across instances so the quantile is correct fleet-wide. It neither rescales units nor alters which quantile is requested.
Question 24 of 30
Why does SRE practice favor paging on symptoms rather than on internal causes?
Show the answer
Answer: d · Symptoms reflect actual user impact and catch unknown causes
Symptom alerts map to user-visible impact and SLOs and will fire even for causes you never anticipated, keeping pages meaningful. Cause-based paging is noisy and can never enumerate every possible cause.
Read the full bite: Symptom-based versus cause-based alerting
Question 25 of 30
What advantage does alerting on error-budget burn rate have over a single fixed error-rate threshold?
Show the answer
Answer: c · It ties alert urgency to how fast the budget is being consumed
Burn-rate alerting scales urgency to budget consumption speed, paging on fast burns and ticketing slow ones. A single static threshold cannot distinguish a brief spike from a sustained leak.
Question 26 of 30
When improving API p99 from 500ms to 200ms in a distributed system, which validation strategy best ensures real user benefit without hidden side effects?
Show the answer
Answer: a · Deploy fine-grained edge histograms, propagate trace context across hops, and watch error rates, throughput, and cost
The correct strategy uses histograms to accurately detect true tail shifts, trace context to pinpoint which backend hop inflates latency, and complementary metrics to guard against side effects. Option D is tempting because it artificially lowers the percentile, but it hides latency by converting slow requests into errors, which directly harms user experience.
Read the full bite: Monitor p99 improvement from 500ms to 200ms and side effects
Question 27 of 30
What makes a severity matrix consistent across different responders?
Show the answer
Answer: a · Defining levels by measurable impact thresholds mapped to a response contract
Objective, measurable thresholds tied to required response make classification reproducible. Intuition yields inconsistency, and defaulting everything to SEV1 causes alert fatigue and severity inflation.
Question 28 of 30
Which metric best indicates the post-incident review process is actually working?
Show the answer
Answer: d · A declining rate of incidents recurring from the same root cause
Fewer repeats from the same cause shows reviews drive durable fixes. Counting documents measures activity, and rewarding fewer declared incidents perversely encourages underreporting, hiding the very problems reviews exist to fix.
Read the full bite: Measuring post-incident review effectiveness
Question 29 of 30
Why is daily active users a poor primary success metric for an internal authentication platform team?
Show the answer
Answer: b · The platform's real customers are engineering teams, so adoption and reliability matter more than end-user counts
A platform serves other engineers, so adoption, integration time, and SLO reliability capture its leverage; end-user DAU is the consuming products' concern. The other options misstate what DAU is or wrongly claim platforms cannot be measured.
Read the full bite: Platform team metrics versus product team metrics
Question 30 of 30
What most distinguishes SLO-and-error-budget monitoring from traditional threshold-based alerts?
Show the answer
Answer: d · It alerts on user-facing reliability burn rate and ties release decisions to the budget
SLO-based monitoring pages on how fast you burn an error budget defined by user experience, and uses budget health to gate releases. Threshold alerts fire on raw signals; no approach guarantees 100 percent uptime, which would leave no budget.
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.