Site Reliability Engineer interview questions

An SLI measures service behavior, an SLO sets its internal target, and an SLA defines an external commitment.

• An SLI needs a precise event definition, data source, and measurement window.
• An SLO states the acceptable result, such as 99.9% successful requests over 28 days.
• An SLA usually has a looser target and defines consequences when the commitment is missed.

I choose an SLI that shows whether the user completed the valuable action successfully and quickly enough.

• Define the boundary from the user entry point to the observable outcome, not around one component.
• Count valid attempts in the denominator and successful outcomes in the numerator.
• Measure latency at the edge so visible network and dependency costs are included.

A request-based availability SLI is the ratio of valid successful requests to all valid requests in the window.

• Specify successful status codes and application outcomes instead of treating every non-5xx response as good.
• Exclude malformed or unsupported requests only when the service contract allows it.
• Measure where the final result is visible because server metrics can miss proxy and routing failures.

Latency percentiles expose slow user experiences that an average can hide.

• A mean may stay stable while a small but important share of requests becomes extremely slow.
• A percentile target names both the threshold and covered share, such as 99% below 400 milliseconds.
• Percentiles are not additive, so end-to-end latency must be measured directly or aggregated from histograms.

Multi-window burn-rate alerts detect budget consumption that is too fast over both short and long periods.

• Burn rate of one spends the budget exactly at the pace allowed by the SLO window.
• A short window catches rapid consumption while a longer confirmation window filters brief noise.
• Thresholds should derive from the SLO and exhaustion horizon rather than arbitrary error percentages.

An error budget creates a shared quantitative limit for trading delivery velocity against reliability.

• Remaining budget supports controlled change while the service meets its objective.
• Rapid consumption signals that reliability work should take priority over riskier changes.
• The budget guides decisions but is not permission to deliberately cause failures.

An effective policy defines objective triggers, proportionate actions, owners, and conditions for normal delivery to resume.

• Triggers should use agreed burn rates or consumed-budget bands instead of subjective health labels.
• Actions may range from reviewing risky changes to pausing selected releases while allowing reliability fixes.
• Ownership covers calculation, exception approval, and verification of recovery criteria.

An end-to-end SLO accounts for dependency reliability but cannot be derived safely by copying vendor targets.

• Serial critical dependencies compound availability, so several strong targets can produce a weaker journey.
• Redundancy, caching, and fallbacks change each dependency contribution.
• Measure the user result directly and use dependency objectives to allocate risk.

I use a rolling window for a continuously current view without a reset at month boundaries.

• Rolling windows suit burn-rate calculations and prevent a bad period from disappearing on the first day of a month.
• Calendar windows are easier for contracts and fixed business reviews.
• The selected window must represent normal traffic variation while remaining useful for decisions.

For low traffic, I combine longer windows with user-relevant synthetic checks instead of trusting sparse ratios alone.

• One failed request can dominate a short window, so statistical uncertainty must be visible.
• Synthetic probes exercise critical paths at a controlled frequency when real events are rare.
• Targets and alert thresholds should reflect sample volume rather than copying a high-traffic API.

RED describes a service through request rate, error rate, and request duration.

• Rate gives workload context for changes in errors or latency.
• Errors should represent user-visible unsuccessful outcomes rather than only process failures.
• Duration belongs in a distribution so tail latency remains visible.

USE examines each resource through utilization, saturation, and errors, complementing the request-oriented RED view.

• Utilization shows the busy share of capacity, such as CPU time or memory occupancy.
• Saturation reveals queued work when demand exceeds immediately available capacity.
• Errors cover resource failures such as disk faults or network drops.

Structured logging needs a stable schema, bounded fields, and data controls so events remain queryable without creating uncontrolled cost or risk.

• Use consistent names and types for service, version, environment, severity, request ID, and trace ID across producers.
• Keep high-cardinality details in logs rather than metric labels, but cap payload size and avoid unbounded nested objects.
• Redact secrets and personal data before ingestion, then apply retention and access rules according to data sensitivity.
• Version schema changes and monitor parse failures, dropped events, ingestion volume, and query performance.

Trace context should cross every supported boundary so spans from one operation share a trace identity.

• HTTP and RPC clients inject standard headers, and receivers extract them before creating child spans.
• Message producers put context in metadata, while consumers create linked spans.
• Long-lived background work may use span links instead of pretending it is a direct child.

I choose sampling from traffic volume, analytical needs, and cost while preserving rare valuable traces.

• Head sampling is cheap but cannot know whether a trace will become slow or unsuccessful.
• Tail sampling retains traces by outcome or latency at the cost of buffering and collector complexity.
• Parent-based decisions keep one distributed trace coherent across services.

High cardinality creates too many time series, increasing memory, storage, query cost, and ingestion pressure.

• Unbounded user IDs, request IDs, and raw URLs must not become metric labels.
• Prefer bounded dimensions such as service, region, status class, and normalized route.
• Detailed identifiers belong in logs or traces designed for event-level data.

Histogram buckets determine the resolution and cost of server-side latency aggregation.

• Place boundaries around meaningful objectives and known latency ranges instead of arbitrary defaults.
• Wide buckets hide changes near an SLO threshold, while too many buckets multiply time series.
• Instances need compatible boundaries before their histograms can be aggregated correctly.

A useful metric label is a bounded dimension that supports a known aggregation or decision.

• Its possible values should be predictable enough to estimate the resulting series count.
• Its meaning must remain stable across versions and services.
• Dimensions needed only occasionally belong in logs or traces.

An SLO alert is actionable when it signals material budget risk, identifies ownership, and points to a defined decision.

• It should represent user impact or an imminent threat to the objective, not a raw resource threshold.
• Severity follows projected budget exhaustion rather than graph-spike size.
• Low-urgency signals belong on dashboards or reports instead of interrupting people.

Synthetic monitoring gives controlled continuous checks, while real user monitoring measures actual client experiences.

• Synthetic probes cover critical paths during low traffic and compare locations consistently.
• Real user data captures device, browser, network, and behavior diversity that scripts miss.
• Using both compares a stable baseline with genuine user experience.