Skip to content
tezvyn:

Top 30 Intermediate Monitoring & SRE Interview Questions and Answers

30 intermediate multiple-choice Monitoring & SRE interview questions, past the definitions: how the pieces fit together, what breaks in practice, and the trade-off behind a choice. They come from 30 bites in the Monitoring & SRE library, the middle 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.

  1. Question 1 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?

  2. Question 2 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?

  3. Question 3 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?

  4. Question 4 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?

  5. Question 5 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?

  6. Question 6 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

  7. Question 7 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.

    Read the full bite: How does distributed tracing work?

  8. Question 8 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

  9. Question 9 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

  10. Question 10 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

  11. Question 11 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

  12. Question 12 of 30

    In OpenTelemetry, why is the API kept separate from the SDK?

    Show the answer

    Answer: d · So instrumentation libraries can depend on a vendor-neutral, no-op interface while the application chooses the implementation

    Splitting the API from the SDK lets libraries instrument against a stable, no-op interface without forcing an implementation, and the app supplies the SDK to actually process and export. The API delegates export to the SDK and does nothing on its own.

    Read the full bite: OpenTelemetry API, SDK, and Collector

  13. Question 13 of 30

    What does the W3C traceparent header primarily carry to enable cross-service correlation?

    Show the answer

    Answer: c · The trace ID, parent span ID, and trace flags such as the sampled bit

    The traceparent header carries the shared trace ID, the caller's span ID as parent, and flags like the sampled bit, so the receiver can create a correctly linked child span. Generating a new trace ID per hop would break correlation, and logs or cookies are not its role.

    Read the full bite: Trace context and propagation across services

  14. Question 14 of 30

    What is the single most important change to make http_requests_total{user_id, path} sustainable in Prometheus?

    Show the answer

    Answer: a · Drop the unbounded user_id label and normalize path to a bounded route template

    user_id and raw path are unbounded, so removing user_id and templating the path collapses the unique label combinations and thus the series count. Changing scrape interval affects samples not series, gauges do not reduce cardinality, and adding labels only increases it.

    Read the full bite: Redesigning a high-cardinality request metric

  15. Question 15 of 30

    Which label choice is most likely to cause a damaging cardinality explosion in a metrics system?

    Show the answer

    Answer: c · Per-request unique request_id

    A unique request_id is unbounded, creating a new series per request and exploding cardinality. The other labels have small bounded value sets, so they stay cheap.

    Read the full bite: High cardinality in time-series databases

  16. Question 16 of 30

    For measuring p99 latency aggregated across a 30-server fleet, why are Prometheus histograms preferred over summaries?

    Show the answer

    Answer: b · Histogram buckets are additive so quantiles can be computed fleet-wide

    Histogram bucket counts sum across instances, so a correct fleet-wide quantile is computed at query time. Summary quantiles are per-instance and non-aggregatable; histograms are approximate, not exact.

    Read the full bite: Prometheus histogram versus summary

  17. Question 17 of 30

    What is the essential element that lets you tie a single request's logs, metrics, and traces together reliably?

    Show the answer

    Answer: b · A trace ID propagated through request context

    A propagated trace ID uniquely identifies one request across signals, enabling precise pivots. Timestamps and service names are ambiguous under concurrency and cannot isolate one request.

    Read the full bite: Correlating logs, metrics, and traces

  18. Question 18 of 30

    On a cache dashboard, which metric most directly warns that the cache is becoming ineffective for callers?

    Show the answer

    Answer: b · Falling cache hit ratio over time

    A declining hit ratio means more requests miss the cache and fall through to the backend, directly degrading effectiveness. Cumulative command totals and uptime do not indicate cache health on their own.

    Read the full bite: Designing a cache health dashboard

  19. Question 19 of 30

    What is the most important thing to measure before changing a noisy alert?

    Show the answer

    Answer: d · How often it fired versus how often action was actually required

    The actionability rate, fires versus required actions, tells you whether to retune, downgrade, or delete the alert. Blindly muting or raising thresholds without that data risks hiding real incidents.

    Read the full bite: Fixing a noisy non-actionable alert

  20. Question 20 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.

    Read the full bite: SLO-based alerting and error budgets

  21. Question 21 of 30

    What most distinguishes an effective runbook from an ineffective one for a new on-call engineer?

    Show the answer

    Answer: a · It gives specific linked diagnostics and concrete remediation with rollback

    Specific, linked diagnostic steps and concrete, risk-aware remediation let an unfamiliar engineer act quickly and safely. Vague prose or assumed tribal knowledge defeats the runbook's purpose.

    Read the full bite: Anatomy of an effective runbook

  22. Question 22 of 30

    Why is an acknowledgement timeout that escalates to a secondary responder critical in an escalation policy?

    Show the answer

    Answer: d · It prevents a single missed page from becoming an unhandled incident

    If the primary does not acknowledge in time, automatic escalation ensures someone else is paged, so no critical alert is silently dropped. It neither reduces alert volume nor fixes the issue itself.

    Read the full bite: Designing an escalation policy

  23. Question 23 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.

    Read the full bite: Designing a SEV1-SEV4 severity matrix

  24. Question 24 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

  25. Question 25 of 30

    What is the practical purpose of insisting on blameless language in a post-mortem?

    Show the answer

    Answer: a · To create safety so people share honest detail, surfacing the real systemic causes

    Blamelessness exists so people disclose what really happened without fear, which exposes systemic gaps. It is not about comfort over truth, and it still assigns owned action items, just not personal blame.

    Read the full bite: Conducting a blameless post-mortem in practice

  26. Question 26 of 30

    Why should a facilitator reject 'human error' as the final root cause?

    Show the answer

    Answer: d · Because it ends inquiry without revealing the systemic gap that let a normal mistake cause harm

    Human error is a symptom; the productive question is why the system allowed it, which surfaces fixable guardrails. People do err, so the fix targets the system, not blaming or removing humans.

    Read the full bite: Why 'human error' is not a root cause

  27. Question 27 of 30

    What is the most objective way to decide between two candidate contributing factors?

    Show the answer

    Answer: d · Correlate each candidate's timestamp against the exact onset of the symptoms

    Matching candidate events to the precise symptom onset on a shared timeline is empirical and decisive. Seniority and convenience are not evidence, and incidents frequently have multiple real contributing factors.

    Read the full bite: Resolving post-mortem disagreement with data

  28. Question 28 of 30

    Why is fixing only the proximate cause risky for long-term reliability?

    Show the answer

    Answer: c · The systemic gap remains, so the same class of failure can recur via a new trigger

    Patching the immediate trigger leaves the underlying condition intact, so a different trigger reproduces the failure. The root fix neutralizes the whole class, which is what durable reliability requires.

    Read the full bite: Proximate cause versus root cause

  29. Question 29 of 30

    An infrastructure script times out after sending a create-VM request, so it retries. What property prevents a duplicate VM?

    Show the answer

    Answer: d · Idempotency, via desired-state reconciliation or an idempotency key

    Idempotency ensures repeated operations converge to one end state, so a retry is a no-op. Atomicity concerns all-or-nothing execution of one operation and does not by itself dedup a second create request after a timeout.

    Read the full bite: Idempotency in infrastructure provisioning scripts

  30. Question 30 of 30

    When prioritizing which noisy alerts to fix first, which combination of data is most useful?

    Show the answer

    Answer: d · Firing frequency multiplied by per-incident effort, plus actionability rate

    Volume times effort estimates total toil, and a low actionability rate flags alerts that page humans for nothing. Severity labels are subjective and static, so they poorly reflect the real ongoing burden an alert imposes.

    Read the full bite: Systematically reduce noisy alert toil

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