Interview questions in Monitoring & SRE, page 6
How does chaos engineering differ from other testing?
It experiments on real systems by injecting faults to test a steady-state hypothesis, versus verifying known behaviors like integration or load tests.
What is blast radius and how do you limit it?
Blast radius is the scope of users or systems an experiment can harm; limit it by targeting a small traffic percentage and by having an automated abort.
Design a simple chaos experiment for a cache dependency?
Hypothesis that the service degrades gracefully when Redis is unavailable, monitor error rate, latency, DB load, and cache hit rate.
How do you run your first production chaos experiment?
Pick a low-risk known weakness, define a measurable hypothesis, brief stakeholders and on-call, run small with an abort, then analyze and fix.
Why does 200ms latency drop requests? Diagnose it.
Little's Law shows added latency raises in-flight requests, exhausting the thread or connection pool; check pool saturation, timeouts, and retries.
Resource faults versus network faults: when each matters?
Resource faults probe local saturation and autoscaling; network faults probe distributed-call resilience like timeouts and retries.
Automating chaos in CI/CD for continuous verification?
Run codified experiments against staging or canary with pass/fail on steady-state SLIs; prerequisites are observability, automated abort, and isolation.
Chaos test for gray-failure cascades in shared services?
Inject partial latency into a shared service, hypothesize tenants stay isolated within steady state, and monitor cross-system queue depth, pool saturation, retries, and per-tenant SLIs.
Client-side chaos for an uncontrollable third party?
Inject faults at your client boundary via a proxy or fault-injecting wrapper, simulate timeouts, errors, and latency, then verify timeouts, retries, breakers, and fallbacks.
Defining SLIs and an SLO for an auth service?
Pick user-centric SLIs like login availability and latency, measure good over valid events at the right boundary, then set an achievable SLO with a window.
What is an error budget and how is it used?
The budget is the allowed unreliability (100 percent minus the SLO); track its burn, ship freely when budget remains, and freeze risky changes to focus on reliability when exhausted.
A team keeps blowing its error budget. First steps?
Analyze where the budget is burning via SLIs and postmortems, validate the SLO and SLIs are sound, then partner blamelessly on the top fixes.
Embedded vs consulting SRE engagement models
Embedded SREs sit inside one team for deep impact but limited reach; consulting SREs advise many teams broadly but shallowly.
Conducting a Production Readiness Review
Assess monitoring and alerting, capacity and load testing, failure modes and dependencies, on-call and runbooks, and rollback or release safety.
Keeping a postmortem blameless after an admission
Acknowledge the courage, redirect from who to why the system allowed it, ask what guardrails were missing.
Designing an error budget policy
Define SLO and budget, tiered consequences as burn worsens, a feature freeze on exhaustion, and concrete earn-back criteria.
Calculating downtime for a 99.9% SLO
0.1% of 30 days is roughly 43 minutes of allowed downtime; healthy budget enables faster shipping while depletion slows or freezes deploys.
Writing high-quality postmortem action items
Good action items are specific, assigned to an owner, prioritized, tracked to completion, and ideally prevent recurrence rather than just detect faster.
Rolling update vs blue-green deployment
Rolling replaces instances gradually with minimal extra capacity but mixes versions; blue-green runs two full environments for instant switch and rollback at double the cost.
Designing shallow vs deep health checks
Shallow checks confirm the process is alive; deep checks verify dependencies; use shallow for liveness/load-balancer routing and deep sparingly to avoid…
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles