Site Reliability Engineering Principles Questions

The core SRE practice model: service-level objectives and indicators, error budgets, toil reduction, and reliability as an engineering discipline. Covers the principles and trade-offs behind treating operations as a software problem and balancing reliability against feature velocity. The conceptual foundation questions specific to SRE-style roles.

HardTechnical

87 practiced

Write a PromQL expression to compute a rolling 1-hour burn rate for an SLO based on a 'success_rate' metric, and write an alert that fires if burn rate > 2 for 30 minutes. Explain how burn rate is calculated from SLI time-series and justify the window lengths and threshold chosen.

Sample Answer

(1 - \text{observed success rate}) / (1 - \text{SLO})

MediumSystem Design

83 practiced

You inherited a service with no SLOs and minimal monitoring. The product manager wants measurable reliability improvements in 30 days. Create a plan to define appropriate SLOs, implement minimum viable monitoring and alerting, and deliver concrete reliability improvements within 30 days. Include which metrics, tooling choices, and quick-win actions you'll prioritize.

Sample Answer

HardTechnical

69 practiced

Design SLIs/SLOs for a machine-learning prediction service where ground-truth labels arrive hours or days later. Propose proxy SLIs for near-real-time monitoring (e.g., prediction distribution drift, model confidence), explain how you would backfill true correctness when labels arrive, and how error budgets could be applied to model rollbacks.

Sample Answer

MediumTechnical

119 practiced

Given Prometheus counters: http_requests_total{service="images",code="200"} and http_requests_total{service="images"}, write a PromQL expression that computes the 5-minute availability SLI (successful requests / total requests) for service 'images' and a rule that fires an alert if availability < 99.95% for 15 minutes. Explain your use of functions and evaluation interval.

Sample Answer

A simple availability alert compares a directly-computed success ratio against a fixed threshold and requires that condition to persist for a sustained window, which is the right first alert to build before adding burn-rate sophistication. Structured elaboration The ratio itself comes from two counters (successful requests over total requests for the service), aggregated with sum(rate(...)) over a short window (5 minutes here) so the ratio reflects RECENT behavior rather than an all-time average; a for: clause on the alert then requires the low-availability condition to hold continuously for the stated duration before paging, which filters out single-scrape noise. Worked example (executed; promtool unit test against a real Prometheus binary) yaml- record: job:availability:5m expr: sum(rate(http_requests_total{service="images",code="200"}[5m])) / sum(rate(http_requests_total{service="images"}[5m])) - alert: LowAvailability expr: job:availability:5m < 0.9995 for: 15m labels: severity: page Verified against a synthetic counter pair (994 good : 6 bad requests per interval, i.e. an observed availability of 99.4%): the alert correctly fired after the 15-minute persistence window against a 99.95% threshold. Trade-offs and pitfalls A short 5-minute evaluation window is sensitive to real changes quickly but is also the window most vulnerable to a low-traffic service producing a wildly noisy ratio from just one or two errors; if this service handles only a handful of requests per 5 minutes, widen the window or add a minimum-request-count guard so the alert doesn't fire on statistically meaningless samples. This alert alone also does not distinguish a slow, sustained low-grade degradation from a sudden severe outage, both look identical once the 15-minute persistence has elapsed; that distinction is exactly what a second, burn-rate-based alert (see the companion burn-rate design) is for.

MediumTechnical

95 practiced

You have 30 days of uptime data for a service as an SLI. The daily 'successful_requests' and 'total_requests' are: day successful_requests total_requests 1 9,990,000 10,000,000 2 9,995,000 10,000,000 ... (assume similar) 10,000,000 Assume an SLO of 99.9% availability over 30 days. Explain how to compute the 30-day SLI and the remaining error budget. Show formulas and a short numeric example for a single day with 9,990,000 successes out of 10,000,000 requests.

Sample Answer

\dfrac{\sum_{i=1}^{30} \text{successful}_i}{\sum_{i=1}^{30} \text{total}_i}

Unlock Full Question Bank

Get access to all 24 Site Reliability Engineering Principles interview questions and detailed answers.

Join thousands of developers preparing for their dream job.

day	successful_requests	total_requests
1	9,990,000	10,000,000
2	9,995,000	10,000,000
...	(assume similar)	10,000,000

Site Reliability Engineering Principles Questions

Sample Answer

Structured elaboration

Worked example (executed; promtool unit test against a real Prometheus binary)

Trade-offs and pitfalls

Sample Answer

Structured elaboration

Worked example

Trade-offs and pitfalls

Sample Answer

Structured elaboration

Worked example

Trade-offs and pitfalls

Sample Answer

Structured elaboration

Worked example (executed; promtool unit test against a real Prometheus binary)

Trade-offs and pitfalls

Sample Answer

Structured elaboration

Worked example (computed and verified)

Trade-offs and pitfalls

Unlock Full Question Bank