SRE
205 bites tagged SRE — interview questions with model answers, and 60-second explainers.
Incident Timeline
An incident timeline is a chronological, timestamped record of what happened during an incident: detection, key events, actions taken, and resolution. It anchors the postmortem in facts, separates symptoms from causes, and reveals detection and response…
Auto-Instrumentation
Auto-instrumentation automatically adds telemetry to an application without manual code changes, by hooking into libraries, frameworks, or the runtime. It gives broad baseline observability fast, but produces generic spans that often need manual…
Metrics in Observability
Metrics are numeric measurements aggregated over time, like counters, gauges, and histograms. They are cheap to store and fast to query, making them ideal for dashboards and alerting, but their pre-aggregation discards per-event detail needed for deep…
Observability vs Monitoring
Monitoring watches predefined metrics and alerts on known failure modes you anticipated. Observability is the property of being able to ask new questions about a system's internal state from its outputs, letting you debug unknown failures you never predicted…
Monitoring with SLOs and error budgets
Define SLIs from the user's view, set SLO targets, derive an error budget, and alert on burn rate rather than raw thresholds. SRE reliability targets. paging on every CPU blip with no link to user impact.
How would you instrument and query P95 API latency by region?
This tests white-box latency instrumentation and safe cardinality for percentile aggregation. Strong answer: emit histograms by region, query P95 with histogram_quantile or a log percentile, and keep trace IDs in logs only.
What specific metrics define a 'fast' report export?
Propose user-facing latency percentiles and throughput; split SLI from SLO target; pick realistic targets. Turning vague promises into precise SLIs and SLOs. Only infra metrics like CPU, not user latency.
How do you translate a non-technical product vision into SLIs and SLOs?
This tests converting qualitative goals into measurable reliability metrics. A good answer identifies user journeys, picks SLIs like latency or yield, sets thresholds from user pain not hardware limits. Red flag: infra metrics like CPU minus user impact.
SLOs Tied to User Journeys, Not APIs
A user-journey SLO measures the full flow a person experiences, not one microservice's health. If checkout is 99.9% up but payments fail, the metric lied. Teams drown in green per-service dashboards while users are furious.
DevOps Is Culture, SRE Is Engineering
DevOps is a cultural philosophy for fast, safe delivery; SRE is the engineering discipline that implements it with error budgets and SLOs. They are complementary, not rival job titles. The footgun is hiring SREs and declaring DevOps done.
AWS Fault Injection Simulator
AWS Fault Injection Simulator is a controlled chaos button: it breaks resources on purpose to prove your failover works before real disasters. Run it before peak traffic to validate auto-healing.
What statistical methods automate canary-baseline comparison and handle noise?
Tests statistical rigor in automated canary analysis. Strong answers use non-parametric tests, multi-metric aggregation with effect-size gates, MAD-based outlier rejection, and smoothing windows.
How would you use distributed tracing to debug a deployment latency issue?
This tests causal request-path analysis beyond aggregate metrics. A strong answer filters traces by the new version, finds the exact regressed span, and compares it to a pre-deployment baseline.
What are the four Golden Signals for service health monitoring?
Tests whether you can name the four essential metrics—latency, traffic, errors, saturation—and explain why each matters for detecting user-facing regressions after a release, rather than drowning in infrastructure noise.
Blue/green deployment fails during switch-over with partial decommissioning; recovery and process changes?
Tests whether you can recover when a blue/green rollback path is compromised. Strong answers stop the bleed, revive blue if possible, and mandate keeping blue fully warm until green is stable. Red flag: "just roll back" ignoring partial decommissioning.
How would you automate canary deployment and what metrics decide rollback?
This tests progressive delivery maturity. Strong answers cover traffic splitting (10% to 100%), automated 5-10 minute health gates, and rollback triggers like error rate and p99 latency.
What are liveness and readiness probes, and what happens when each fails?
This tests whether you know the distinct kubelet actions for each probe failure. A strong answer: liveness failure restarts the container; readiness failure removes the Pod from Service endpoints and stops traffic.
Infrastructure apply fails midway. What is the state and your immediate steps?
This tests partial-state reasoning and safe recovery. A strong answer halts automation, inspects state for blast radius, then chooses idempotent roll-forward or rollback with canary validation.
How would you measure P95 latency by geographic region?
Tests your ability to translate a business need into a concrete observability implementation. A good answer involves instrumenting the API with a histogram metric, adding a region label via GeoIP, and querying with `histogram_quantile`.
How would you measure P95 latency by geographic region?
Tests your ability to design a practical metrics pipeline, considering instrumentation, data types (metrics vs. logs), and aggregation. Instrument the API with a histogram metric and a `region` label, then query using `histogram_quantile`.
Load Balancing Algorithms: How to Pick a Server
Load balancing algorithms are the rules a client uses to pick one server from a pool of identical backends. They're used by web proxies routing user traffic and by microservices calling each other.
Post-Incident Review: Learning from Failure, Blamelessly
A Post-Incident Review (PIR) is a blameless process to learn from an outage, not to assign blame. Use it after a production incident to identify systemic flaws and create action items to prevent repeats.
Escalation Policy: When to Stop Shipping and Start Fixing
An escalation policy is a pre-agreed plan for when to divert engineers from feature work to fix reliability. When a service's error budget burns too fast, the policy's thresholds trigger specific actions. The footgun is thinking a quick rollback is enough.
Time-Series Compression: Storing More with Less
Time-series compression stores data more efficiently by saving the *difference* between consecutive points, not the full values. It's key for managing terabyte-scale monitoring and IoT data, often saving over 90% on storage.
Get SRE bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.