Top 30 Advanced Monitoring & SRE Interview Questions and Answers
30 advanced multiple-choice Monitoring & SRE interview questions, the deep end: internals, failure modes, and the design calls a senior engineer is expected to defend. They come from 30 bites in the Monitoring & SRE library, the hardest slice of the 131 Monitoring & SRE interview questions in the 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 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 of 30
What is the main thing custom OpenTelemetry instrumentation adds that auto-instrumentation cannot provide?
Show the answer
Answer: a · Business and domain semantics attached to operations
Auto-instrumentation already captures framework boundaries but is blind to business meaning; custom spans and attributes add domain semantics. It does not reduce overhead or prevent cardinality issues by itself.
Read the full bite: When to add custom OpenTelemetry instrumentation
Question 11 of 30
Why are summary metrics problematic for computing a fleet-wide p99 latency across many servers?
Show the answer
Answer: a · Per-instance quantiles cannot be mathematically aggregated into a global quantile
Summary quantiles are computed per instance and are non-aggregatable, so combining them gives an invalid global figure. Histograms store additive bucket counts and compute the quantile at query time, which does aggregate correctly.
Question 12 of 30
When running two identical HA Prometheus replicas behind a global query layer, what must the query layer do?
Show the answer
Answer: c · Deduplicate overlapping series from the replicas
Identical replicas produce overlapping data, so the query layer must deduplicate to avoid double-counting while still surviving one replica failing. Summing would inflate results; permanently ignoring a replica defeats HA.
Question 13 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 14 of 30
Why can a content keyword search be slower in Loki than in Elasticsearch?
Show the answer
Answer: c · Loki indexes only labels and must scan matching chunks for content
Loki indexes labels only and brute-force scans the selected chunks for content matches, so broad keyword queries read more data. Elasticsearch's full-text inverted index makes such searches fast at higher storage cost.
Question 15 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.
Question 16 of 30
Why do existing average-based metric alerts often miss rare intermittent failures, and what helps?
Show the answer
Answer: b · Aggregation smooths out rare events; tracing with tail sampling and high-cardinality context helps
Fleet averages dilute a few bad requests so they never cross a threshold; capturing every failing trace via tail sampling and slicing by high-cardinality context surfaces the pattern. Raising thresholds alone just adds noise.
Question 17 of 30
Why would a team prefer inhibition over a manual silence when a whole cluster goes down?
Show the answer
Answer: a · Inhibition automatically suppresses dependent symptom alerts based on a higher-severity source alert, without manual action
Inhibition is rule-driven and dependency-aware, suppressing downstream symptoms when a source alert fires. A manual silence would require an operator to act and set an expiry, which is slower during a live cascade.
Question 18 of 30
Why is buying better alerting alone usually insufficient to significantly reduce MTTR?
Show the answer
Answer: c · It mainly shortens detection while diagnosis and recovery time remain unchanged
MTTR is a chain of detection, diagnosis, and repair; alerting only addresses detection. Real gains require faster diagnosis (tracing, deploy markers) and faster recovery (automated rollback, flags).
Question 19 of 30
What overlay most often resolves conflicting hypotheses fastest on an incident dashboard?
Show the answer
Answer: d · A change feed of deploys and config edits aligned to the symptom timeline
Most incidents follow a change, so overlaying deploys and config edits on the symptom timeline pinpoints causation quickly. Dumping every metric adds noise rather than clarity under pressure.
Read the full bite: Architecting a single source of truth for incidents
Question 20 of 30
What single safeguard most directly prevents a chaos experiment from becoming a real outage?
Show the answer
Answer: d · A limited blast radius plus an automatic abort when SLOs degrade past a threshold
Containing scope and auto-aborting on SLO breach caps the worst-case impact. Timing and notice help process-wise but do not bound the damage if a fault cascades.
Read the full bite: Designing a safe chaos engineering exercise
Question 21 of 30
What change most directly prevents post-mortem action items from rotting in a backlog?
Show the answer
Answer: a · Giving each item an owner and date and routing it into normal sprint planning
Items ship when they have clear ownership and compete for real capacity in normal planning. A separate untracked list and more volume make orphaning worse, not better.
Read the full bite: Fixing an unmanaged post-mortem action backlog
Question 22 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 23 of 30
How should a review of a multi-team cascading outage differ from a routine incident review?
Show the answer
Answer: d · It needs a neutral facilitator, a reconciled cross-team timeline, and multiple contributing factors mapped
Large cascades require heavier structure: independent facilitation, a unified timeline across teams, and explicit mapping of multiple contributing factors. Forcing one root cause or a lightweight template misses the systemic, cross-team interactions.
Read the full bite: Reviewing a large-scale cascading outage
Question 24 of 30
Which guardrail most directly prevents an auto-remediation platform from amplifying an incident when an alert flaps repeatedly?
Show the answer
Answer: a · A rate limiter or circuit breaker that caps actions and escalates to humans
Rate limiting and circuit breakers stop a flapping alert from triggering a remediation storm and hand off to humans when limits are hit. Audit logging is essential but records actions after the fact; it does not prevent the cascade.
Read the full bite: Design a centralized auto-remediation platform
Question 25 of 30
Which metric set most credibly justifies further automation investment to leadership?
Show the answer
Answer: b · Baseline-to-current toil hours reclaimed converted to engineer cost, plus MTTR trend
Reclaimed hours measured against a baseline and translated to dollars, alongside reliability trends like MTTR, ties effort to business value. Counting scripts is a vanity metric that says nothing about actual time or money saved.
Question 26 of 30
Which design most reliably triggers a safe automatic rollback when a green environment fails after taking partial traffic?
Show the answer
Answer: a · Incremental traffic shift with deep health checks and a warm blue for instant revert
Incremental shifting limits blast radius, deep checks catch application-level failures shallow pings miss, and a warm blue makes revert instant. Tearing down blue or relying on shallow pings removes the safe rollback path or fails to detect the problem.
Read the full bite: Auto-rollback on failed blue-green cutover
Question 27 of 30
When canarying a shared downstream service, why is distributed tracing across the full request path essential?
Show the answer
Answer: d · A regression in a shared dependency often surfaces in its upstream callers, not the canary's own metrics
A shared dependency's problems frequently appear as errors or latency in the services that call it, so end-to-end tracing reveals the true blast radius. Watching only the canary's local dashboard misses this downstream breakage entirely.
Question 28 of 30
In a request that fans out to 50 backends and waits for all, why does a 1% per-backend slow rate cause widespread slowness?
Show the answer
Answer: a · End-to-end latency is gated by the slowest backend, so the chance at least one is slow is high
Waiting for all responses means the slowest dominates, and across 50 backends the probability at least one hits its slow tail is large (about 40% at 1% each). The mean stays low precisely because most individual calls are fast.
Question 29 of 30
Adding more stateless instances fails to improve latency and raises errors. Which underlying problem does this most likely indicate?
Show the answer
Answer: d · A shared resource like a single database or lock is the real bottleneck, and more instances increase contention
When every instance funnels into one shared resource, more instances add connections and lock contention, worsening latency, exactly what the universal scalability law predicts. The fix targets the shared bottleneck, not the stateless tier or CPU speed.
Read the full bite: When horizontal scaling is the wrong fix
Question 30 of 30
An architect promises an active-active multi-region store with strong consistency, the lowest possible write latency, and zero data loss on failover. What is the core problem with this claim?
Show the answer
Answer: b · PACELC says even without a partition you must trade latency against consistency
PACELC and CAP establish that strong cross-region consistency forces higher write latency, and partitions force a consistency-versus-availability choice. No amount of replicas or clock sync removes that fundamental trade-off.
Read the full bite: Replication and consistency for active-active regions?
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.