SRE Interview Questions and Answers

What interviewers are testing: Whether you contrast SRE's error-budget and toil metrics with DevOps culture and delivery pipeline ownership.

SRE implements DevOps ideas with quantified reliability and operational ownership.

A strong answer is:

DevOps is the cultural umbrella; SRE is an implementation that uses SLOs and error budgets to make reliability negotiable with product teams.

What interviewers are testing: Whether you choose measurable user-impacting signals—not vanity infrastructure metrics alone.

An SLI is a quantitative measure of service behavior from the user's perspective.

SLIs must be measurable from production telemetry—not aspirational slogans.

A strong answer is:

"An SLI is what we actually measure—like the ratio of successful HTTP requests under 500 ms—that reflects user-perceived health."

What interviewers are testing: Whether you can turn a user journey into a measurable target over an explicit evaluation window.

An SLO is a target range for an SLI over a time window. Express the objective in the same form as the SLI:

• Availability: "99.9% of valid requests succeed over 30 days"
• Latency (good-events ratio): "95% of valid requests complete in under 200 ms over 30 days"
• Latency (percentile): "The p95 request latency remains below 200 ms over the evaluation window"

Good-events ratio and percentile latency are related but not identical ways of stating the objective—pick one and measure it consistently.

Teams often choose an internal SLO that is stricter than a customer-facing SLA so they have operational margin before the contractual threshold is breached.

A strong answer is:

"SLO is our internal reliability target on an SLI—tight enough to protect users, realistic enough that we can still ship features within error budget."

What interviewers are testing: Whether you distinguish engineering objectives from customer-facing commitments and consequences.

An SLA is a customer-facing service-level commitment or agreement. Depending on the business relationship, breaching it may trigger service credits, financial remedies, escalation, or other consequences—not every SLA is itself a legal contract with a financial penalty.

Engineering teams often target SLOs stricter than SLA thresholds so there is buffer before a contractual breach.

A strong answer is:

An SLI is the measurement, an SLO is the reliability target we engineer toward, and an SLA is the customer-facing commitment—often with consequences if we miss it.

What interviewers are testing: Whether you tie error budgets to release velocity and use budget state as a decision framework. Error budget is the amount of unreliability the SLO allows—the allowed bad events relative to the target.

For a time-based 99.9% availability objective over a 30-day month, 0.1% corresponds to about 43.2 minutes of unavailable time. For request-based SLIs, the budget is normally expressed as allowed bad events instead. For a latency SLO, slow requests can consume budget even when there is zero downtime.

Error budgets align product and SRE on when to slow down.

A strong answer is:

Error budget is the amount of unreliability the SLO allows. For 99.9% availability that means 0.1% unsuccessful events; for other SLIs it can represent slow, stale, or otherwise bad events—when budget is gone, we slow risky launches.

What interviewers are testing: Whether you can distinguish repetitive operational burden from valuable engineering/operational work.

Toil is operational work tied to running a service that tends to be manual, repetitive, automatable, tactical, lacks enduring value, and grows as the service grows.

Being on-call itself is not automatically toil—responding repeatedly to avoidable noise is.

Google's SRE organizational goal is to keep operational toil below 50% of time and reserve at least 50% for engineering work—that is guidance, not a universal rule for every team.

A strong answer is:

"Toil is repetitive operational work that scales with the service—if I do it every week without lasting value, I automate or eliminate it with a platform fix."

What interviewers are testing: Whether you define the measurement interval precisely rather than compare ambiguous acronyms. MTTR is commonly used for mean time to restore or recover service, but teams define the acronym differently—Mean Time To Repair, Recover, Restore, or Resolve. Define exactly which interval you measure, for example incident start to user-impact restoration.

Low MTTR matters more for user-facing outages than debating MTBF on replaceable cloud instances—but MTBF can apply to many repairable systems and components, not only hardware.

A strong answer is:

MTTR is ambiguous, so I define it before comparing teams—for example, incident start to user-impact restoration. I separately track detection and acknowledgement so I know which part of response is slow.

What interviewers are testing: Whether you can translate a reliability target into an error budget without confusing request-based and time-based availability. Availability SLO is often expressed as nines. Assuming a time-based availability objective and a 30-day month:

A request-success SLO can have 99.9% good events without corresponding neatly to 43 minutes of complete outage.

Interview tip: know order of magnitude—exact seconds matter less than trade-offs (multi-region cost vs 99.99%).

A strong answer is:

Each nine removes an order of magnitude of allowed downtime—99.9% is about 43 minutes a month; going to four nines needs architecture we may not justify for every tier.

What interviewers are testing: Whether you prioritize impact mitigation, coordination, and communication before exhaustive root-cause work.

When impact is ongoing, prioritize safe mitigation and restoration over exhaustive root-cause analysis. Gather enough evidence to avoid making the incident worse, then continue deeper diagnosis after impact is contained.

A strong answer is:

I stabilize user impact first—rollback, scale, failover—then investigate root cause while comms keeps stakeholders updated.

What interviewers are testing: Whether severity is assigned from user/business impact and urgency, not technical drama. Severity definitions are organization-specific; this is an illustrative model.

Severity drives pager urgency, not ego.

A strong answer is:

Severity is user impact—SEV1 means widespread outage with immediate incident commander and communication according to our incident policy.

What interviewers are testing: Whether you identify causal and contributing conditions plus owned preventive actions, not a person to blame.

Blameless means fix systems, not punish humans—for honest learning.

A strong answer is:

Postmortems are blameless timelines with measurable action items—automation, tests, or architecture changes so the same failure mode is harder next time.

What interviewers are testing: Whether a page represents urgent user impact requiring human action.

Good alerts are symptom-based, actionable, and owned:

Reduce alert fatigue—if on-call cannot act, it is a log, not a page.

For services with well-defined SLOs, mature alerting often pages on error-budget burn rate rather than a fixed infrastructure threshold. A high burn rate means the service is consuming allowed unreliability much faster than planned. Multi-window burn-rate alerts catch both fast outages and slower sustained degradation without paging on every raw error spike.

A strong answer is:

"I page on user-visible symptoms with a runbook—if the engineer cannot do something useful at 3 a.m., it should not wake anyone."

What interviewers are testing: Whether you treat poor on-call health as a system-design/operational-quality problem, not an endurance test.

On-call is a product of system design—bad systems burn people out.

A strong answer is:

Sustainable on-call means actionable pages, runbooks, and we fix top noise sources every sprint—not heroic humans absorbing bad alerts forever.

What interviewers are testing: Whether you can correlate telemetry to form and test hypotheses during an incident.

Metrics, logs, and traces are commonly called the "three pillars," but observability is the capability to investigate system behavior using sufficiently rich telemetry—not merely collecting three data types. OpenTelemetry also supports Baggage for propagating contextual information, while the Profiles signal entered Alpha in 2026. These do not invalidate the useful "metrics, logs, traces" interview shorthand.

A strong answer is:

Metrics show trends, logs explain individual failures, traces show cross-service latency—I correlate telemetry during incidents rather than treating three data types as the whole story.

What interviewers are testing: Whether you know the minimal signals that expose demand, failures, latency, and resource pressure.

From Google SRE practice:

Dashboard every critical service with these before exotic metrics.

A strong answer is:

"I dashboard latency, traffic, errors, and saturation—the four golden signals—before adding niche JVM gauges."

What interviewers are testing: Whether you choose service-level vs resource-level telemetry based on where you are diagnosing the problem.

RED for request-driven services; USE for CPU, memory, disk, network nodes.

A strong answer is:

"RED on the API layer, USE on the nodes underneath—together they narrow whether the bug is in the app or the infrastructure."

What interviewers are testing: Whether capacity is derived from forecast demand, scaling latency, failure domains, and SLOs.

Headroom depends on growth forecast, autoscaling latency, failure-domain requirements, workload burstiness, SLO, recovery time, and cost. This might mean N+1 capacity, enough capacity for one node/AZ loss, or another empirically tested margin.

Plan for peak + failure—if the service's availability design requires surviving that failure domain, one AZ or node loss should not breach SLO.

A strong answer is:

I forecast traffic, load-test before big launches, and size headroom against our SLO and failure domains—not a universal spare-percent rule—capacity is an SLO enabler, not guesswork.

What interviewers are testing: Whether you understand how retries, timeouts, isolation, and degradation change failure propagation.

A strong answer is:

I design for failure—timeouts, bulkheads, and flags—so one bad dependency or deploy cannot take down the entire product.

What interviewers are testing: Whether you reduce deployment risk through progressive delivery and fast, safe mitigation. Recent change is one of the first things SREs check during an incident because deployments, configuration changes, feature flags, dependency updates, and infrastructure modifications are common triggers.

A strong answer is:

I correlate incidents with recent change first—then tie rollouts to canaries and rollback when canary health or correlated budget signals cross our safety thresholds.

What interviewers are testing: Whether you split latency spikes into deploy regression, dependency, saturation, and traffic-shift causes before tuning.

1. Confirm user impact — dashboards, support tickets, synthetic probes
2. Check recent deploys — correlate timestamp; consider rollback
3. Golden signals — traffic spike? error rate up? saturation?
4. Dependency map — database, cache, downstream API latency
5. Traces — sample slow requests; find hot span
6. Mitigate — scale, rollback, throttle, failover read replica

A strong answer is:

"I correlate the spike with deploys and traffic, check RED metrics and traces for the slow dependency, and mitigate with rollback or scale before deep profiling."

What interviewers are testing: Whether you use the organization's error-budget policy as a decision framework rather than an automatic punishment.

Error budget is a decision tool, not punishment—the exact response comes from the team's agreed error-budget policy, not a universal automatic freeze.

A strong answer is:

"If our error-budget policy defines 80% consumption at mid-window as a trigger, I would restrict high-risk changes, increase rollout scrutiny, and prioritize the reliability work causing the burn—while aligning with product on what can wait until budget recovers."

What interviewers are testing: Whether you degrade gracefully, avoid retry storms, and respect idempotency for external dependencies.

1. Communicate — status page, support macros, internal channel
2. Queue or degrade — accept orders async if business allows; show clear UX message
3. Do not retry blindly — exponential backoff; avoid retry storm
4. Only queue/retry payment operations when the business flow and provider API support safe idempotency; never blindly replay a charge that may already have succeeded
5. Monitor vendor status — switch to backup provider if architected
6. Post-incident — Was multi-vendor failover missing? Document gap

A strong answer is:

I communicate clearly to users, stop hammering the vendor with retries, enable graceful degradation or failover if we built it, and capture gaps for the postmortem.

What interviewers are testing: Whether you restore safe headroom without blindly deleting production data and determine why capacity was exhausted. Host-level steps (see Linux troubleshooting for depth):

1. Which mount? — df -h and df -i; inode exhaustion can prevent new files even when byte capacity looks different
2. Restore headroom safely — expand storage or identify known disposable/rotatable data; do not blindly delete files from database/application directories
3. Open deleted files? — lsof if space not freed after delete
4. Service impact — read-only DB? crashed pods?
5. Prevent — alerts on disk trend, log shipping, retention policy

A strong answer is:

I identify the full filesystem, free space safely—log rotation or volume expand—check for deleted-but-open files, then add trending alerts so we never hit 100% silently.

What interviewers are testing: Whether you can identify failure amplification mechanisms, not just the first failed component. Likely cascade failure:

• Retries from callers amplified load on unhealthy service
• Thread pools exhausted waiting on timeouts
• Circuit breakers missing or too slow to open
• Shared database saturation, connection pool exhaustion, synchronized timeouts, dependency fan-out, or overloaded queues

Mitigation: shed load (rate limit), open circuits, scale healthy tiers, rollback bad deploy. Long-term: timeouts, bulkheads, queue-based async.

A strong answer is:

I look for the amplification mechanism—retry storms, blocked pools, shared dependency saturation, or cascading timeouts—then shed load and restore the constrained dependency before fixing the missing isolation or backoff.

What interviewers are testing: Whether you derive redundancy from an explicit SLO and failure model, rather than sprinkle HA products into a diagram. First define the SLI/SLO boundary and failure assumptions; "three nines" alone does not dictate a specific architecture. Clarify what requests count, what constitutes success, the evaluation window, dependencies included/excluded, RTO/RPO, and traffic/geographic requirements.

Cover in spoken design:

Acknowledge cost vs nines—three nines may not need multi-region.

A strong answer is:

Multi-AZ app tier with autoscaling, a managed HA data tier, canary deploys with rollback on correlated canary/SLO health signals, and symptom-based alerting. I define RTO/RPO and test recovery before claiming three nines.

What interviewers are testing: Whether you understand rate of budget consumption and why fast/slow burns need different responses.

Burn rate is how fast the service is consuming its error budget relative to the SLO window.

For a 99.9% availability SLO, a constant 0.1% error rate corresponds to a burn rate of 1×.

A strong answer is:

"Burn rate tells me how fast we're spending reliability budget relative to the SLO. I page on fast burns and create lower-urgency tickets for slow sustained burns rather than paging on every raw error spike."

What interviewers are testing: Whether you distinguish recovery time from acceptable data loss in disaster planning.

Example: RTO = 30 minutes and RPO = 5 minutes means restore service within 30 minutes while the recovery point should be no more than about five minutes behind the failure—meaning at most roughly five minutes of recoverable data may be lost.

A strong answer is:

RTO is how fast we must be back; RPO is how much data we can afford to lose. I document both and test restore—not just backup existence.

What interviewers are testing: Whether you separate in-region redundancy for HA from cross-region DR with defined RTO and RPO.

A strong answer is:

"HA minimizes interruption during routine component failures; DR restores service after a larger failure. I define RTO/RPO and test failover or restoration instead of treating backups as a DR plan."

What interviewers are testing: Whether you treat runbooks as step-by-step incident procedures and playbooks as broader response workflows spanning teams.

Terminology varies by company, but a useful distinction:

A strong answer is:

"A runbook gives concrete steps for a known operational action; a playbook coordinates response to a broader scenario. I keep both executable where possible and test them during game days."

What interviewers are testing: Whether experiments have hypotheses, bounded blast radius, observability, and abort criteria. Game days and chaos engineering deliberately test failure assumptions in a controlled, bounded way:

• Define steady-state expectations, blast-radius limits, monitoring, and explicit abort conditions before injecting the failure
• Verify alerts, failover, and runbooks under realistic stress
• Start with a low-blast-radius experiment such as one replica; progress to larger failure domains only after safeguards and recovery paths are proven

Chaos engineering is not randomly breaking production without safeguards.

A strong answer is:

Chaos engineering validates known assumptions under controlled failure. I start with a hypothesis, abort criteria, and a low blast radius—then confirm the system and responders behave as designed before larger experiments.