Intermediate interview questions in Monitoring & SRE, page 2
Anatomy of an effective runbook
Alert meaning and impact, diagnostic steps with dashboard and query links, concrete remediation with rollback, and escalation contacts.
Designing an escalation policy
Define timeout-based escalation tiers, multiple notification channels, secondary and management layers, coverage across time zones, and severity-based routing.
Designing a SEV1-SEV4 severity matrix
Tie levels to user impact, scope, and SLO burn with concrete thresholds; map each to response and escalation.
Fast rollback versus targeted fix in an incident
Weigh time-to-recovery and blast radius against rollback side effects; prefer restoring service fast, gated by data like deploy diff and migration risk.
Conducting a blameless post-mortem in practice
Focus on systems not individuals, assume good intent, use neutral language and facilitation, end with owned action items.
Why 'human error' is not a root cause
Human error is a starting symptom; ask why the system allowed it, find missing guardrails.
Resolving post-mortem disagreement with data
Anchor the debate in the timeline, deploy events, traces, and metrics; correlate cause and onset; allow multiple contributing factors.
Proximate cause versus root cause
Proximate cause is the immediate trigger, root cause is the systemic condition that allowed it; fix the root to prevent recurrence.
Idempotency in infrastructure provisioning scripts
Idempotency means repeated runs converge to one end state; achieve it via desired-state reconciliation or idempotency keys with read-before-write.
Systematically reduce noisy alert toil
Inventory alerts, measure frequency, actionability, and time cost, then prioritize by volume times effort.
Design automated microservice provisioning workflow
Template scaffolding plus a pipeline that creates repo, CI/CD, and infra as code, with idempotent steps and rollback.
Blue-green deploys with schema migrations
The shared database means both versions hit one schema, so breaking changes must be split into backward-compatible steps via expand-and-contract.
Diagnose a degraded canary release
Check statistical significance versus baseline, confirm apples-to-apples comparison, isolate the cause via traces and logs, then weigh the regression against SLO budget.
Design automated canary analysis scoring
Track the golden-signal SLIs, compare canary to baseline statistically, weight and combine into a score with promote/rollback thresholds.
Client-side vs server-side feature flags
Client-side is fast and offline-capable but exposes flag logic and risks stale or leaked values; server-side keeps logic secret and consistent but adds latency.
Diagnose database CPU saturation under load
Find the expensive queries via the database's stats, check for missing indexes and full scans, then fix with indexing, query rewrites, caching, or read replicas.
Capacity planning for annual traffic spikes
Forecast peak from history, load-test to find per-unit capacity, use autoscaling with pre-warming and headroom, and protect with caching and graceful degradation.
Little's Law for capacity planning
L equals lambda times W, concurrency equals arrival rate times time in system; rearrange to size threads or concurrency for a target throughput and latency.
Front-end performance budgets
A performance budget is an enforced limit on metrics like Core Web Vitals and bundle size, checked in CI to fail builds that regress.
Reliability patterns for queue-based job processing?
Retries with backoff and jitter for transient faults, dead-letter queues plus a poison-message limit, idempotent handlers and visibility timeouts.
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