Incident Response or Debugging Story Questions
Prepare 1-2 concrete stories about a time you debugged a system problem, diagnosed a root cause, or helped respond to an incident. Include what went wrong, how you approached it, what tools you used, and what you learned.
MediumTechnical
56 practiced
You detect a major outage that started immediately after a deploy. Walk through the incident response steps: mitigation to restore service, establishing incident roles and communication channels, collecting evidence for RCA, and structuring a blameless postmortem.
Sample Answer
Mitigation / restore service (first 0–15 min)- Immediately assess blast radius via dashboards, error rates, traffic, and health checks.- If outage correlates with the deploy: trigger rapid mitigation — roll back or deactivate the release (feature flag, rollback to previous image, or disable new ingress route). Preference: the fastest safe action that restores user-facing service.- Apply temporary mitigations (scale replicas, enable circuit breakers, increase timeouts, route around affected region) while rollback completes.- Verify restoration with SLO/health metrics and synthetic checks before declaring service restored.Establish incident roles & communications (minutes 0–5)- Assign Incident Commander (IC) to own decisions and prioritize actions.- Assign Scribe (timeline/notes), Communications lead (status updates to stakeholders/status page), Triage/Service Owner(s), and On-call Engineers for affected components.- Open a single incident channel (Slack/MS Teams) and a conference bridge. Post initial incident summary: what, impact, suspected cause, immediate actions, next update ETA.- Escalate via PagerDuty if needed and inform product/PM and legal/PR for high-impact outages.Evidence collection for RCA (during and after mitigation)- Preserve deployment artifacts: exact image/hash, deploy manifest, feature flags, CI/CD logs, and git commit diff.- Collect telemetry: metrics (latency, error rates), logs (aggregated by timeframe), distributed traces (e.g., Jaeger/Zipkin), tracing spans around failed requests, and infrastructure events (kube events, autoscaler logs).- Capture timeline: deploy timestamp, rollout windows, canary results, health check failures.- Snapshot current system state (configs, env vars, secrets if relevant) and save copies before further changes. Tag/flag relevant traces/logs for follow-up.Blameless postmortem structure- Title & summary: short outage description, duration, user impact (affected regions, % errors, SLO burn).- Timeline: minute-by-minute chronology from detection to full recovery, including actions and who performed them.- Root cause analysis: factual chain of events (what changed -> why it caused failure). Use techniques like 5 Whys and change analysis (code/config/infra). Distinguish root cause vs contributing factors.- Contributing factors: monitoring gaps, rollout strategy (no canary/too-large batch), insufficient runbooks, unclear rollback path.- Corrective actions: prioritized, owner-assigned, with deadlines. Examples: enforce canary + automated rollback, add deploy-time smoke tests, improve alerts to detect this failure mode, add runbook steps for rollback, CI gate for config validation.- Verification plan: tests or drills to confirm fixes (post-deploy canary success criteria, automated chaos tests).- Communication: share postmortem with stakeholders and schedule follow-up to ensure action completion.Key principles- Act to restore users first, investigate later.- Single source of truth (incident channel, timeline) and clear roles reduce confusion.- Preserve evidence before changing the environment.- Keep postmortem blameless; focus on system/process improvements and measurable follow-through.
MediumTechnical
52 practiced
A single node in a compute cluster shows periodic CPU spikes; other nodes appear healthy. Describe how you would investigate the cause using profiling tools (top, ps, perf, flame graphs), how you'd collect artifacts non-intrusively, and common root causes you would consider.
Sample Answer
Situation: One node shows periodic CPU spikes while peers are healthy. My goal: identify the process/cause with minimal disruption, capture reproducible artifacts, and propose fixes.Investigation approach1. Confirm and correlate- Check monitoring (Prometheus/Grafana) for spike timestamps, load, interrupts, context switches, and thermal/clock changes.- Correlate with cluster scheduler events, cron, deployments, and noisy-neighbor metrics.2. Low-impact live checks (non-intrusive)- Snapshot process list and CPU at spike time: - top in batch mode: top -b -n 1 -o %CPU > /tmp/top.$TS.txt - ps aux --sort=-%cpu | head -20 > /tmp/ps.$TS.txt- Per-process accounting over time: - pidstat -u -h 1 60 > /tmp/pidstat.$TS.txt- System metrics: - vmstat 1 60, sar -u 1 60- I/O and network: iostat, ifstat, netstat/lsof (targeted)3. Lightweight sampling profiling- Use perf with conservative sampling to avoid perturbation: - perf record -F 99 -p <pid> -g -- sleep 60 - perf script > perf.$TS.out- Generate Flame Graphs (use FlameGraph tools offline): - ./stackcollapse-perf.pl perf.$TS.out > out.folded - ./flamegraph.pl out.folded > flame.$TS.svgExplain: 99Hz sampling is low-overhead; -g captures call stacks for hotspots.4. Deeper forensics if needed (off-peak)- strace -tt -p <pid> (short duration) to see syscalls/latency- pmap, /proc/<pid>/status, cgroup info, docker stats for containers- perf top for live hotspot viewArtifact collection best practices (non-intrusive)- Use short-duration, sampled traces (avoid full instrumentation)- Record exact timestamps and host identifiers; collect multiple samples across spikes- Save raw perf.data and generated flame graphs for offline analysis- Bundle /proc/stat, /proc/interrupts, dmesg, syslog, and monitoring snapshots- Hash and store artifacts in central artifact store for reproducibilityCommon root causes to consider- Periodic cron/job, scheduled GC (Java/Python), or batch task triggered by scheduler- Application-level GC or JIT compilation causing CPU bursts- Kernel-level activity: interrupt storms, softirq, network IRQ steering, or driver issues- Container/cgroup throttling or CPU shares causing uneven scheduling- Noisy neighbor on virtualization host, live-migration or backup jobs- Resource leak leading to periodic cleanup (e.g., log rotation, compression)- Hardware/firmware issues: thermal throttling, CPU microcode bugs, defective coreResult and remediation- Identify offending PID and call stack from flame graph; fix via config (reduce GC pause, change scheduling, tune cgroups), patch driver/firmware, reschedule cron, or move workload to different node.- Add targeted alerts (high syscalls, softirq rate, GC pauses) and automated capture (short perf traces) to speed future diagnosis.This approach balances low overhead data collection with enough detail (flame graphs, perf) to pinpoint application vs kernel vs infra causes, then apply targeted fixes.
MediumTechnical
50 practiced
Design an automated runbook that performs a health check and safely restarts degraded Kubernetes pods for a stateful service. Describe how you would detect unsafe restarts, avoid cascading failures, and include rollback or backoff strategies. Optionally include pseudocode for key steps.
Sample Answer
Approach: build an automated runbook (operator/cronjob/automation pipeline) that performs health checks, identifies degraded stateful pods, and issues safe restarts with coordination to avoid data loss or cascading failures. Key principles: leader-aware restarts, quorum preservation, rolling single-pod restarts, exponential backoff, circuit breaker for system-level safety, and rollback hooks.Pseudocode (Python-like):Key concepts:- Detect using both k8s readiness/liveness and app-level health (leader status, replication lag).- Safety: preserve quorum and avoid restarting primaries without graceful leadership transfer.- Avoid cascading failures with single-pod rolling actions, circuit breaker (stop if >N failures), and node cordoning if node-level faults suspected.- Backoff and rollback: exponential backoff on retries; after repeated failures, trigger automated rollback (e.g., previous image/manifest) or scale-up extra replicas, and open pager with diagnostics.- Observability: emit events/metrics for each action; attach runbook logs to incidents.Edge cases:- Network partition where leadership can't transfer — skip restart and escalate.- State corruption after restart — halt automation, require manual recovery.- Rapid flapping — enforce minimum interval between actions per service.Alternatives:- Use Kubernetes PodDisruptionBudgets and StatefulSet partitioned rollingUpdate, or implement operator with leader-aware controllers for tighter control.
python
# assumes kubernetes client configured
def health_check(pod):
# run readiness/liveness checks + app-level probe (e.g., SQL ping, raft status)
return pod.status.ready and app_probe_ok(pod)
def is_safe_to_restart(pod, statefulset):
# preserve quorum: count healthy replicas before action
healthy = count_healthy(statefulset)
replicas = statefulset.spec.replicas
# require at least floor(replicas/2)+1 healthy excluding this pod if possible
required = (replicas // 2) + 1
if healthy - (1 if health_check(pod) else 0) < required:
return False
# avoid restarting leader or primary without transfer
if is_leader(pod):
return transfer_leadership(pod)
return True
def restart_with_backoff(pod, attempt=0):
backoff = min(60, 2**attempt)
sleep(backoff)
cordon_node(pod.spec.nodeName) # optional
evict_or_delete_pod(pod)
wait_for_replacement(pod, timeout=120)
if not health_check(new_pod):
if attempt >= 5:
open_incident(pod, "restart_failed")
return False
return restart_with_backoff(pod, attempt+1)
return True
def runbook(statefulset):
degraded = [p for p in pods(statefulset) if not health_check(p)]
for pod in degraded:
if not is_safe_to_restart(pod, statefulset):
log("unsafe to restart", pod)
continue
if not circuit_breaker_allows():
log("circuit breaker tripped")
break
success = restart_with_backoff(pod)
if not success:
rollback_changes(statefulset) # restore previous config, scale up, alert
breakEasyTechnical
78 practiced
What are the essential elements of an on-call runbook for a critical service? Provide a short structured checklist that a first responder should follow (detection, mitigation, escalation, verification, cleanup).
Sample Answer
Essential elements of an on-call runbook for a critical service:- Quick summary: service purpose, owner, SLOs/SLIs, blackout windows- Contact info: primary/backup on-call, pager, escalation contacts, Slack/IRC channels- Monitoring & alerts: alert names, thresholds, runbook link- Access & tooling: jump hosts, credentials vault, dashboards, command snippets- Safe-to-run checklist: prechecks, risk, approvals- Rollback & mitigation steps: commands, automation playbooks, paging templates- Post-incident: communication templates, RCA owner, follow-up tasksFirst-responder short checklist (detection → mitigation → escalation → verification → cleanup):1. Detection- Acknowledge alert in pager system- Quickly read alert title, severity, affected region/components- Open linked dashboards/logs and incident channel2. Mitigation (first 15 min)- Run pre-approved mitigation script or automation (link in runbook)- If no script: follow minimal-impact steps (disable load, scale replicas, restart specific pod/service)- Record each action and timestamp3. Escalation (if unresolved in X minutes or severity high)- Contact on-call secondary and service owner (use provided contact matrix)- Open incident in tracking tool with concise summary, steps taken, and current impact- If security/PGI involved, notify appropriate teams immediately4. Verification- Confirm metrics/alerts return to normal on dashboards- Run smoke tests or synthetic checks- Validate user-facing functionality (health endpoints, sample transactions)5. Cleanup & Post-incident- Revert temporary mitigations (re-enable traffic, scale back)- Capture logs, timelines, and evidence in incident ticket- Assign RCA, update runbook with lessons learned and missing automation- Close incident after peer review and notify stakeholdersKeep runbook concise, versioned, and automatable where possible (scripts, runbooks-as-code).
EasyTechnical
92 practiced
You receive an alert: 5xx error rate increased threefold for a core API. Outline the immediate steps you would perform in the first 15 minutes to triage and contain the incident. Include how you would collect evidence, mitigate impact, and communicate initial status.
Sample Answer
First 5 minutes — quick assessment & notify:- Acknowledge the alert in the incident channel and set severity (e.g., Sev 2). State: "Investigating 5xx spike on core API; will update in 10 minutes."- Triage dashboards: check error-rate graph, traffic, latency, upstream/downstream services, and deployments in last 30–60 minutes.- Collect initial evidence: links/screenshots of error rates, top error codes, top affected endpoints, service logs tail, and recent deploy IDs.Minutes 5–10 — containment & deeper data collection:- Query logs and APM for error distribution (by endpoint, region, client, host). Example: grep/elk or use trace tool to get top stack traces.- Check infrastructure signals: CPU, memory, disk, queue backpressure, database errors, throttling, circuit-breaker metrics.- If one host/pod group is bad, scale down or cordon instances and shift traffic (remove from LB) to reduce user impact.- If a recent deploy correlates, perform an automated or manual rollback to previous version.Minutes 10–15 — mitigation and communication:- Apply short-term mitigations: increase timeouts/retries conservatively, enable rate-limiting or routing rules, or route traffic to healthy region.- Post an initial incident update to stakeholders: summary, impact (users affected/SLO hit if known), actions taken, next steps, ETA for next update.- Assign owners: who will keep investigating logs/traces, who will handle rollback/infra actions, who will communicate.- Continue monitoring; capture all evidence (logs, traces, metrics) for postmortem.Key principles: act quickly to reduce impact, collect reproducible evidence, prefer safe mitigations (traffic control, rollback), and keep stakeholders informed.
Unlock Full Question Bank
Get access to hundreds of Incident Response or Debugging Story interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.