Site Reliability Engineer interview questions

Site Reliability Engineering applies software engineering methods to keeping services dependable and scalable.

• SRE treats operations problems as engineering problems that can often be measured and automated.
• Its goal is to provide the reliability users need without stopping useful product development.
• SRE work commonly includes service objectives, observability, automation, capacity, and safe operations.
• The discipline creates shared reliability ownership between development and operations.

Availability is one part of reliability, while reliability covers the complete quality of service users experience over time.

• Availability asks whether the service can successfully handle a request when needed.
• Reliability can also include latency, correctness, durability, and consistency.
• A service may be available but unreliable if it returns incorrect data or responds too slowly.

Automation turns repeatable operational work into consistent, reviewable processes.

• Python or Bash scripts can remove small recurring manual steps.
• Terraform and Ansible express infrastructure or configuration as version-controlled code.
• Automated work scales better and reduces variation and human error.
• Safe automation still needs tests, idempotence, access controls, and a recovery path.

An SLI is a quantitative measurement of a service behavior that matters to its users.

• Common SLIs measure successful request ratio, request latency, throughput, or data freshness.
• An SLI needs a precise event, success condition, data source, and aggregation method.
• Good SLIs describe user-visible outcomes rather than internal resource usage alone.

An SLO is a target value or range for an SLI over a defined measurement window.

• An example is at least 99.9% successful requests during a rolling 30-day window.
• The target states the reliability level the team intends to provide.
• The window defines how much data contributes to the evaluation.
• SLOs support decisions about reliability work and acceptable release risk.

An SLA is a formal commitment to a customer about service levels and the consequences of missing them.

• It may promise a minimum availability or response time over a billing period.
• Consequences can include service credits, refunds, or other contractual remedies.
• An SLA is usually less strict than the internal SLO so the team has a safety margin.

An SLI supplies the measurement, an SLO sets its target, and an SLA turns a service promise into a formal agreement.

• The SLI defines what is measured, such as the proportion of successful requests.
• The SLO might require that proportion to remain at or above 99.9% for 30 days.
• The SLA may use a related customer-facing threshold and specify remedies if it is missed.
• Clear definitions must align so each target is based on the same understood service behavior.

An availability SLI measures the proportion of valid service interactions that complete successfully.

• A request-based form is successful valid requests divided by all valid requests.
• A time-based form measures the proportion of time the service is usable.
• The success criteria should reflect the full user operation, not only whether a process is running.

A latency SLI measures how long a valid service operation takes from the user's perspective.

• It can be expressed as a distribution or as the proportion of requests below a threshold.
• Separate operations often need separate latency SLIs because their expected durations differ.
• Failed requests should be classified consistently so fast failures do not make latency appear healthy.
• End-to-end timing usually represents user experience better than timing one internal component.

A throughput indicator measures the amount of useful work a service processes per unit of time.

• Examples include requests per second, messages per minute, or bytes transferred per second.
• Throughput provides load context for latency and error indicators.
• A higher value is not automatically better if errors increase or work queues grow.

An error indicator tracks explicitly failed operations, while a correctness indicator checks whether results are actually valid.

• Error rate is commonly failed valid requests divided by all valid requests.
• HTTP 5xx responses and failed jobs are examples of explicit errors.
• A response with HTTP 200 can still be incorrect if its data is missing, stale, or wrong.
• Correctness checks therefore need domain rules such as expected fields, values, or invariants.

P99 latency is the value at or below which 99% of measured requests complete.

• If p99 is 800 ms, 99% of requests took 800 ms or less and 1% took longer.
• Percentiles reveal slow tail behavior that an average can hide.
• P50 represents a typical request, while p95 and p99 describe increasingly slower portions of traffic.

A measurement window defines the period of events used to decide whether an SLO is met.

• A rolling window always evaluates the most recent duration, such as the last 30 days.
• A calendar window resets on fixed boundaries, such as the first day of each month.
• Short windows react quickly but can vary sharply with small event counts.
• Long windows smooth brief changes but reveal sustained deterioration more slowly.

A user-centric SLI measures whether users can complete a meaningful service interaction with acceptable quality.

• It is observed near the user boundary, such as at an API edge or client, when feasible.
• It covers the complete operation rather than one server, container, or dependency.
• CPU usage may explain behavior, but it does not directly state whether users succeeded.

An error budget is the amount of unreliability an SLO permits during its measurement window.

• It equals the difference between perfect reliability and the SLO target.
• A 99.9% SLO permits 0.1% of measured events to be unsuccessful.
• The remaining budget shows how much reliability risk is still acceptable.
• Teams use it to balance product changes with work that protects reliability.

The budget is calculated by applying one minus the SLO target to the relevant event count or time window.

• For 1,000,000 valid requests and a 99.9% SLO, the budget is 0.1%, or 1,000 unsuccessful requests.
• For a 30-day time-based 99.9% SLO, the allowed unavailable time is about 43.2 minutes.
• The calculation must use the same eligibility and success definitions as the underlying SLI.

Burn rate describes how quickly a service consumes its error budget relative to the sustainable rate.

• A burn rate of 1 would use the whole budget exactly across the full SLO window.
• A burn rate of 2 consumes budget twice as fast as the SLO allows.
• Burn rate connects a current error level to the amount of budget and time remaining.
• Multiple observation windows can distinguish brief spikes from sustained budget consumption.

A 100% reliability target is usually impractical and can cost more than the additional user value it provides.

• Networks, hardware, dependencies, and software can all fail, so eliminating every failure is unrealistic.
• Approaching 100% requires increasingly expensive controls and can greatly slow product change.
• Users may not notice reliability beyond a certain level because their own devices and networks also fail.
• A suitable SLO sets the lowest reliability level that still meets user and business needs.

MTTR describes average restoration time after a failure, while MTBF describes average operating time between failures.

• MTTR should be defined consistently because the final R can mean repair, recovery, or restore in different organizations.
• Lower MTTR means service is restored more quickly on average.
• Higher MTBF means failures occur less frequently on average.
• For a repairable system, availability is approximately MTBF divided by MTBF plus MTTR.

RTO limits acceptable recovery time, while RPO limits acceptable data loss measured in time.

• RTO answers how long a service may remain unavailable after a major disruption.
• RPO answers how far back restored data may be compared with the disruption time.
• An RTO of one hour requires restoration within one hour.
• An RPO of five minutes permits losing at most about five minutes of recent data.