SRE Interview Questions and Answers

A DevOps interview tends to test whether you can build and ship a delivery pipeline: containerize an app, write the Terraform, wire up CI/CD, get it running on Kubernetes. An SRE interview assumes you can already do that and instead probes whether you can keep it running at a defined level of reliability under real failure. The center of gravity shifts from 'how do I deploy this' to 'how do I measure that it is healthy, decide when to stop shipping, and recover fast when it breaks.'

Practically, that means three things dominate the loop. First, you must speak in measured reliability: SLIs, SLOs, and error budgets, with actual percentages and the math behind them. Second, you will get an on-call and incident-response round where the interviewer cares about your decision-making under uncertainty, not just your kubectl recall. Third, expect a systems-debugging scenario where they degrade a service and watch how you triage. Treating reliability as a quantity you trade against feature velocity is the single mental shift that separates SRE candidates from strong DevOps candidates.

A useful framing borrowed from Google's SRE practice: reliability is the most important feature, but 100 percent is the wrong target because it is effectively impossible to reach, costs disproportionately more for each added nine, and your users often cannot tell the difference between 100 percent and 99.99 percent through their own flaky networks and devices anyway. Interviewers reward candidates who can say where the right reliability target comes from (the product, the user journey, the cost of an extra nine) rather than reflexively maximizing uptime.

An SLI (Service Level Indicator) is a measured ratio of good events to valid events, expressed as a percentage. A good SLI is defined from the user's perspective at the boundary where they experience the service, for example the fraction of HTTP requests served in under 300ms at the load balancer, or the fraction of requests returning a non-5xx status. An SLO (Service Level Objective) is the target for that SLI over a window, for example 99.9 percent of requests succeed over a rolling 28 days. An SLA (Service Level Agreement) is the contractual version with financial or legal penalties, and it should always be looser than your internal SLO so you breach the SLO and react well before you ever breach the SLA.

The error budget is the most important derived concept: it is simply 100 percent minus the SLO. A 99.9 percent availability SLO leaves a 0.1 percent budget, which over a 30-day month is about 43 minutes of allowable downtime (and therefore roughly 2.2 hours per 90-day quarter). That budget is a currency. When the budget is healthy you can ship aggressively and take risks; when it is exhausted you freeze risky launches and spend the next cycle on reliability work. This turns the classic dev-versus-ops tension into a shared, data-driven policy instead of an argument.

Toil is the other fundamental. Toil is manual, repetitive, automatable, tactical work that scales linearly with service size and carries no enduring value: think hand-editing configs, manually restarting a stuck pod every night, or copy-pasting the same runbook step. SRE practice caps toil (Google's well-known guideline is under 50 percent of an SRE's time) so the rest goes to engineering that reduces future toil. In interviews, name a concrete piece of toil you eliminated and quantify the time it gave back.

Observability is your ability to ask new questions about a system's internal state from its external outputs without shipping new code to answer them. The three common pillars are metrics (cheap, aggregatable numeric time series, great for dashboards and alerting), logs (discrete, often high-cardinality events, great for forensic detail), and traces (the path of a single request across services, great for finding which hop is slow). A strong answer explains the trade-off: metrics scale cheaply but lose per-request detail; logs and traces keep detail but cost far more to store and query at volume, which is why teams sample traces and cap log retention.

Prometheus is the de facto open-source metrics backbone. It pulls (scrapes) metrics over HTTP from instrumented targets, stores them as time series identified by a metric name plus labels, and is queried with PromQL. Know the four core metric types: counters (monotonic, only go up between resets, like total requests, which you read via rate()), gauges (go up and down, like current memory), histograms (bucketed observations for latency, which let you compute quantiles server-side with histogram_quantile over aggregated buckets), and summaries (client-side quantiles). A common gotcha: you cannot meaningfully average pre-computed percentiles such as a p99 across instances, so you store latency as a histogram and compute the quantile over the aggregated buckets. Grafana then visualizes those series and is where you build SLO burn-rate dashboards.

Alerting maturity is a frequent differentiator. Naive alerting fires on causes (CPU is high, disk is 80 percent full) and produces noise. Mature SRE alerting fires on symptoms tied to the SLO, typically using multi-window multi-burn-rate alerts: a fast-burn alert (the canonical Google example: burning roughly 14.4x faster than the SLO allows over a 1-hour window, which would consume 2 percent of a monthly budget in an hour) pages immediately for an acute outage, while a slower-burn alert (for example 6x over a 6-hour window, or 1x over 3 days) opens a ticket for a steady degradation. The principle is that every page should be actionable, novel, and urgent; if it does not require a human to act now, it is a ticket, not a page.

Incident response is where SRE judgment is most visible. A well-run incident has clear roles: an Incident Commander who owns decisions and coordination (and is explicitly not the person elbow-deep in the fix), an Operations/subject-matter lead doing the hands-on remediation, and a Communications lead handling stakeholder and status-page updates. The first job in almost every incident is to mitigate, not to root-cause. Rolling back the last deploy, failing over to a healthy region, or shedding load restores users faster than diagnosing why the new code is broken; you can do the forensics after the bleeding stops.

Runbooks are the codified, step-by-step responses to known alert conditions, and every alert that can page should link to one. A good runbook states the symptom, the likely causes, the exact diagnostic commands, the mitigation steps, and an escalation path. Runbooks reduce mean time to recovery precisely because they let a tired on-call engineer at 3am act without reconstructing tribal knowledge. Note the key metrics: MTTD (detect), MTTA (acknowledge), MTTR (mean time to recovery or to repair, depending on the team's definition), and MTBF (between failures). SRE work usually drives MTTR down faster than it pushes MTBF up, because fast, safe recovery is more tractable than preventing every failure.

Blameless postmortems are the cultural backbone. The premise is that humans operating a complex system act reasonably given the information and tooling they had, so a postmortem targets the system and process, never the individual. Naming a person as the root cause is a red flag in interviews; the right output is concrete action items with owners (better guardrails, an added automated check, a clearer runbook, a removed footgun) plus an honest timeline. The test of a blameless culture is whether the engineer who triggered the incident feels safe writing the postmortem themselves.

Capacity planning asks: given expected demand plus headroom for spikes and failures, how much resource do you provision, and when do you scale? An SRE answer distinguishes organic growth (model from historical trend) from inorganic events (a launch, a marketing push, Black Friday) that need explicit forecasting. You provision to a target utilization (commonly 60 to 70 percent steady-state) so a node or zone failure does not immediately saturate the survivors, and you load-test to find the real breaking point rather than trusting CPU as a proxy. On Kubernetes you connect this to the Horizontal Pod Autoscaler scaling pods on a metric, the Cluster Autoscaler (or Karpenter) adding nodes, and requests/limits sized so the scheduler can actually bin-pack and so you avoid CPU throttling and OOMKills.

Now a scenario interviewers love: 'p99 latency on the checkout service jumped from 200ms to 3s ten minutes ago, error rate is still near zero. Walk me through it.' A structured response beats raw command recall. First, confirm scope from the SLO dashboard: is it all requests or one endpoint, one region, one version, one pod? Errors near zero plus a latency spike suggests requests still succeed but are waiting on something, so I am thinking saturation or a slow dependency, not a crash. Check the RED metrics and the deploy timeline: did anything ship at minute zero? If a deploy correlates, the fastest mitigation is to roll it back and confirm latency recovers, then investigate offline.

If no deploy correlates, follow the request with a trace to find which hop owns the new latency: is it the database (a missing index, lock contention, connection-pool exhaustion), a downstream API, or the pod itself? On the pod, check whether CPU is being throttled (container_cpu_cfs_throttled_seconds_total rising against a tight limit), whether it is GC-thrashing or near its memory limit, and whether the node is saturated. A classic culprit here is connection-pool or thread-pool exhaustion: a slow dependency causes requests to queue, latency climbs while error rate stays low until timeouts finally trip. Throughout, I narrate hypotheses and how each metric confirms or rejects them. The interviewer is scoring the systematic narrowing far more than whether you remember an exact flag.

Reading SRE theory creates the dangerous illusion of competence. You can recite the error-budget formula and still freeze when an interviewer says 'pods are in CrashLoopBackOff, the dashboard is red, go.' The fix is deliberate, hands-on reps against realistic failures: deliberately break a Kubernetes deployment and recover it, instrument a service with Prometheus and write the PromQL for a latency SLI, then drive a mock incident end to end including the postmortem write-up. Aim to be able to talk while you type, because that running commentary is exactly what the interview round rewards.

Tailor your prep to the actual job. A platform-SRE role at a Kubernetes-heavy shop weights cluster internals and on-call differently than an SRE role at a database-centric company. Pull the specific stack from the job description, drill the failure modes of that stack, and research the company's reliability posture and recent engineering signals before you walk in. This is exactly the loop prepme.io is built for: paste a real SRE job description and it generates a free briefing surfacing three practice surfaces. Its flagship is hands-on Kubernetes and Terraform labs you debug in a real in-browser container; alongside that are auto-graded ABCD multiple-choice exams across easy, medium, and hard, and architecture and design whiteboard interviews (currently in beta). It also adds a free, on-demand Company Coverage card that web-researches the employer's news, layoffs, funding, culture, and interview intel, with cited sources. Generating and viewing the briefing is free; doing the practice (labs, exams, and design) is $20 a month, cancel anytime, and every lab, exam, and design task is graded 0 to 100 with specific feedback, so you find your weak spots before the interviewer does.