Skip to content
tezvyn:

Top 30 Easy Monitoring & SRE Interview Questions and Answers for Freshers

30 easy multiple-choice Monitoring & SRE interview questions, the ones an interviewer opens with: definitions, everyday syntax, and the quick checks that you have really used it. They come from 30 bites in the Monitoring & SRE library, the gentlest 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

    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.

    Read the full bite: What defines toil, with an example?

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

    Read the full bite: SLI vs SLO vs SLA: how do they relate?

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

    Read the full bite: How do SRE and DevOps relate?

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

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

    Read the full bite: What are the Four Golden Signals?

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

    Read the full bite: Relationship between SLI, SLO, and SLA

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

    Read the full bite: What is an error budget?

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

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

    Read the full bite: The three pillars of observability

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

    Read the full bite: Structured vs unstructured logging

  11. Question 11 of 30

    Which label is safe to add to a request latency metric without risking a cardinality explosion?

    Show the answer

    Answer: c · A normalized route template such as /orders/:id

    A normalized route template has a small, bounded set of values, keeping series counts manageable while enabling per-endpoint analysis. user_id, full URLs, and request_id are unbounded and would explode cardinality, so they belong in logs or traces.

    Read the full bite: Essential tags for a request latency metric

  12. Question 12 of 30

    How does a standard Prometheus server normally obtain metrics from a monitored service?

    Show the answer

    Answer: c · Prometheus pulls metrics by scraping the service's HTTP endpoint

    Prometheus uses a pull model, scraping each target's /metrics endpoint on an interval. Pushing is the exception via the Pushgateway, and Alertmanager only handles alerts, not metric ingestion.

    Read the full bite: Core components of Prometheus

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

  14. Question 14 of 30

    Which first check usually gives the highest signal when investigating a sudden p99 latency spike?

    Show the answer

    Answer: b · Whether a recent deploy or config change preceded the spike

    Recent deploys and config changes are the most common cause of sudden latency shifts, so correlating the spike with the change timeline is high-yield. Rewriting code first skips diagnosis entirely.

    Read the full bite: First steps on a p99 latency page

  15. Question 15 of 30

    During the first minutes of a 5xx spike on a critical service, what should usually take priority?

    Show the answer

    Answer: a · Quantifying impact, then mitigating to stop user pain before root-causing

    Triage prioritizes assessing blast radius and stopping user impact, often via rollback, before deep root-cause work. Reading the diff first leaves users failing while no mitigation is in flight.

    Read the full bite: Triaging a 5xx error spike

  16. Question 16 of 30

    What most distinguishes an effective post-mortem document from an ineffective one?

    Show the answer

    Answer: c · It produces prioritized, owned action items that get tracked to completion

    Effective post-mortems drive recurrence prevention through concrete, owned, tracked action items. Naming an individual undermines the blameless culture that surfaces honest information, and length alone does not produce change.

    Read the full bite: Primary goal and sections of a post-mortem

  17. Question 17 of 30

    Why is a factual timeline considered an essential post-mortem section?

    Show the answer

    Answer: a · It anchors root-cause discussion in objective events rather than memory or opinion

    A timeline grounds analysis in what actually happened and when, so debate is fact-based. It complements rather than replaces action items, and it is not for assigning personal blame.

    Read the full bite: Essential sections of a post-mortem

  18. Question 18 of 30

    In the connection pool example, why is 'increase the pool size' considered an inadequate stopping point?

    Show the answer

    Answer: c · It treats a symptom while the systemic cause, an unreviewed missing index, remains

    Raising the pool only delays recurrence because the slow query and missing review gate persist. The 5 Whys aims for the systemic cause; five is a guideline, not a mandatory count.

    Read the full bite: The 5 Whys root cause technique

  19. Question 19 of 30

    What is the main technical risk of a blame-oriented post-incident review?

    Show the answer

    Answer: a · People hide details and underreport, so systemic causes go undiagnosed and recur

    Blame suppresses honest disclosure, starving the review of the information needed to find systemic causes, so failures recur. The harm is degraded signal quality, not document length.

    Read the full bite: Why blameless culture matters for reviews

  20. Question 20 of 30

    What is the best long-term resolution for repeatedly paging to clear a cache after deploys?

    Show the answer

    Answer: a · Automate the clear in the deploy pipeline and address why the deploy invalidates the cache

    Eliminating toil means automating the action and, better still, removing the need via versioned cache keys. A runbook still requires a human, and resizing or rotating on-call does not address the recurring trigger.

    Read the full bite: Automating a recurring manual cache clear

  21. Question 21 of 30

    Which task best fits the SRE definition of toil?

    Show the answer

    Answer: c · Manually running the same restart-and-rotate commands every day, scaling with server count

    Toil is manual, repetitive, automatable, value-less work that scales with the service, exactly the daily restart routine. Capacity planning and novel investigation require judgment and produce lasting value, so they are not toil.

    Read the full bite: Distinguishing toil from necessary ops work

  22. Question 22 of 30

    Which design best preserves least privilege when automating temporary elevated database access for debugging?

    Show the answer

    Answer: c · Issue short-lived, auto-expiring, scoped credentials with approval and audit logging

    Short-lived, scoped, audited grants give access only when and where needed and revoke it automatically. Permanent admin roles violate least privilege and leave standing access that nobody can later reconstruct or revoke promptly.

    Read the full bite: Automate temporary elevated database access securely

  23. Question 23 of 30

    Which set of metrics constitutes the four golden signals used to inform scaling decisions?

    Show the answer

    Answer: a · Latency, traffic, errors, and saturation

    The four golden signals are latency, traffic, errors, and saturation, covering user experience and resource headroom. Raw CPU/memory/disk are just facets of saturation and miss errors and latency, which reveal degradation before resources fully exhaust.

    Read the full bite: Golden signals for capacity planning

  24. Question 24 of 30

    You suspect a slow memory leak that crashes a service after running for days. Which test type best exposes it?

    Show the answer

    Answer: a · Soak (endurance) testing under sustained load for an extended period

    Soak testing runs sustained load over hours or days, the only way slow leaks and gradual resource exhaustion surface. Stress and short load tests end too quickly to reveal problems that accumulate over time.

    Read the full bite: Load vs stress vs soak testing

  25. Question 25 of 30

    A service has dashboards for CPU, memory, and disk but users report intermittent errors with no obvious cause. Which missing signal would most directly localize the fault?

    Show the answer

    Answer: c · Distributed traces correlating the request across downstream services

    Distributed traces show where time and errors occur across service hops, localizing the fault. More host metrics only describe machine load and cannot explain a request-level failure spanning services.

    Read the full bite: What telemetry must a new microservice ship with?

  26. Question 26 of 30

    When defining a request-based availability SLI for a stateless API, how should most 4xx client-error responses typically be treated?

    Show the answer

    Answer: d · As valid requests, since they reflect client errors rather than service failure

    4xx usually signals a client mistake, so they count as valid requests but not as service failures, keeping the SLI focused on the service. Counting them as failures would unfairly penalize the service for client behavior.

    Read the full bite: What is an SLO and how do you define API availability?

  27. Question 27 of 30

    How does chaos engineering fundamentally differ from load testing?

    Show the answer

    Answer: a · Chaos injects faults to test a resilience hypothesis, while load testing verifies performance under expected demand

    Chaos engineering is hypothesis-driven fault injection to discover resilience weaknesses, whereas load testing measures performance against expected demand. They answer different questions and complement rather than replace each other.

    Read the full bite: How does chaos engineering differ from other testing?

  28. Question 28 of 30

    Which pair of techniques best limits the blast radius of a production chaos experiment?

    Show the answer

    Answer: b · Scope the fault to a small traffic slice and wire an automated abort on SLO breach

    Containing exposure to a small cohort and automatically aborting on a guardrail breach are the two strongest controls. Manual aborts are slow, full-traffic runs defeat containment, and disabling monitoring removes the signal you need to react.

    Read the full bite: What is blast radius and how do you limit it?

  29. Question 29 of 30

    When chaos-testing a service by making its Redis cache unavailable, which metric most directly reveals a dangerous cascading-failure risk?

    Show the answer

    Answer: a · The origin database's load and connection-pool utilization during the fault

    Losing the cache redirects all misses to the database, so its load and connection saturation reveal whether a thundering herd will overwhelm it. Redis memory or replica count does not show how the origin copes under the miss storm.

    Read the full bite: Design a simple chaos experiment for a cache dependency?

  30. Question 30 of 30

    Which is the most appropriate SLI for a user authentication service?

    Show the answer

    Answer: b · The ratio of successful (non-5xx) auth requests to total valid requests

    An SLI must reflect user experience, so a ratio of good to valid requests captures whether auth actually works for users. CPU, server count, and log volume are infrastructure signals that do not directly measure the user-facing reliability of authentication.

    Read the full bite: Defining SLIs and an SLO for an auth service?

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