Top 30 Monitoring & SRE Interview Questions and Answers
30 multiple-choice questions on Monitoring & SRE, of the kind that come up in a technical interview, drawn from 30 bites in the Monitoring & SRE library. 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.
Observability, incident response, reliability, SLOs
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
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 3 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 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
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 6 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 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?
Question 8 of 30
Which approach best lets a risky feature launch despite a nearly exhausted error budget while upholding reliability?
Show the answer
Answer: d · Roll out behind a flag to a small canary, gate progression on live burn, and get explicit risk sign-off
Canary plus flag plus burn-gated rollout and documented risk acceptance contains blast radius while enabling the business. A flat refusal, a full rollout, or hiding errors all abandon reliability discipline.
Read the full bite: Risky launch with a near-empty error budget?
Question 9 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 10 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 11 of 30
In a distributed web service, which telemetry type is best for pinpointing which downstream service is adding latency to a single slow request?
Show the answer
Answer: d · Distributed traces, because they follow one request's spans across services
Traces follow a single request across services and attribute time to each span, localizing the slow hop. Metrics show aggregate trends and logs give per-event detail, but neither maps one request's cross-service path like a trace.
Read the full bite: Explain the three pillars of observability
Question 12 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 13 of 30
When is alerting on p99 latency rather than p95 most justified?
Show the answer
Answer: c · When requests fan out to many backends so the slow tail dominates user-perceived latency
High fan-out makes a backend's tail the common case for users, so p99 matters most there. p99 is not universally better, the median describes typical experience, and a healthy average can still hide a bad tail.
Read the full bite: Why use latency percentiles over the average?
Question 14 of 30
Why is structured logging considered foundational for observability at large scale?
Show the answer
Answer: a · Its consistent named fields enable reliable querying, aggregation, and correlation across services
Structured logs put data in named fields, so you can query, aggregate, and join on trace IDs reliably at volume, which free text cannot. It does not replace metrics or traces, and it favors machine-parseability over raw readability.
Read the full bite: Structured vs unstructured logging: why it matters
Question 15 of 30
Across three microservices handling one request, what value is identical on every span, and what value distinguishes each operation within that request?
Show the answer
Answer: a · Trace ID is shared; span ID distinguishes each operation
The trace ID is generated once and carried by every span to group them, while each operation gets its own span ID. Sharing span IDs or minting new trace IDs per hop would break correlation entirely.
Question 16 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 17 of 30
An engineer adds a user_id label to a request counter and Prometheus memory usage explodes. What is the underlying cause?
Show the answer
Answer: b · Each unique label combination becomes a separate stored time series
An unbounded label like user_id multiplies the number of unique label combinations, and Prometheus stores one series per combination, so series count and memory explode. Scrape interval changes sample volume per series, not the series count.
Read the full bite: What is high-cardinality data in Prometheus?
Question 18 of 30
Why can tail-based sampling guarantee retention of all error traces while head-based sampling cannot?
Show the answer
Answer: b · Head-based decides before the trace outcome is known; tail-based decides after the trace completes
The sampling timing is the key difference: head-based commits at trace start with no knowledge of the result, so it cannot prefer errors, whereas tail-based waits for completion and can apply outcome-based policies. Hardware and compression are irrelevant to this distinction.
Question 19 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 20 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 21 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 22 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 23 of 30
Why can a breaching p99 with a healthy p50 cause outsized user pain in a microservice architecture?
Show the answer
Answer: c · Because fan-out means one user action hits many backends, raising the chance at least one lands in the slow tail
With fan-out, a single action triggers many backend calls, so the odds that at least one hits the slow one percent grow quickly, inflating the latency users actually feel. The median being fine does not protect against this multiplicative tail effect.
Read the full bite: Diagnosing a healthy p50 but breaching p99
Question 24 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 25 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 26 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 27 of 30
The error budget is exhausted but the burn came from a single, now-resolved incident. What is the most constructive response to the launch request?
Show the answer
Answer: b · Present burn data and propose mitigations like a flagged canary with fast rollback to enable a controlled launch
A data-driven response distinguishes a resolved one-off from ongoing instability and offers risk-reducing mitigations so a controlled launch can proceed. A flat freeze ignores context, a full launch ignores the spent budget, and lowering the SLO games the policy.
Read the full bite: Launching a risky feature with no error budget left
Question 28 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 29 of 30
During an incident, which telemetry type best localizes which service in a request path is responsible for added latency?
Show the answer
Answer: a · Distributed traces, because they decompose one request into timed spans across services
A trace breaks a single request into spans across services, directly revealing which hop consumed the time. Metrics show that latency rose but not where, and logs explain a specific event only once you know which service to inspect.
Question 30 of 30
Why does structured logging scale better than unstructured logging for large-system analysis?
Show the answer
Answer: b · Named machine-readable fields can be indexed, filtered, and aggregated reliably instead of parsed with brittle regex
Structured logs expose explicit fields that backends index and query precisely, enabling reliable filtering, aggregation, and correlation at scale. Free-text logs force fragile regex parsing that breaks as messages change, which does not scale.
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.