# Incident Response — Quiz

## Question 1

What is the primary role of the Incident Commander?

A) Fix the bug
B) Coordinate the response, make decisions, delegate—not necessarily fix
C) Update the status page
D) Write the postmortem

<!-- ANSWER: B -->
<!-- EXPLANATION: The IC owns the response and orchestrates. They coordinate responders, decide on approach, and delegate. They may not be the one typing the fix—their job is to ensure the team responds effectively. Fixing is the responders' job. -->

## Question 2

What makes a postmortem "blameless"?

A) No one is mentioned
B) Focus on systems and process, not individuals; we learn, not punish
C) Only positive feedback
D) No root cause is identified

<!-- ANSWER: B -->
<!-- EXPLANATION: Blameless means we analyze what happened in terms of systems, process, and decisions—not "who messed up." The goal is learning and preventing recurrence, not assigning fault. People need to feel safe to contribute honestly. -->

## Question 3

Which severity typically requires immediate (e.g., 5 min) response?

A) SEV4
B) SEV3
C) SEV2
D) SEV1

<!-- ANSWER: D -->
<!-- EXPLANATION: SEV1 is critical—full outage, data loss, security breach. Response time is immediate (e.g., 5 min). SEV2 is major (15–30 min); SEV3/4 are slower. -->

## Question 4

What should the external status update include?

A) Technical details of the failure
B) We're aware of X, impact is Y, ETA is Z (or "investigating")
C) Names of engineers working on it
D) Root cause analysis

<!-- ANSWER: B -->
<!-- EXPLANATION: External updates should be clear and customer-friendly: we're aware, here's the impact, here's our ETA (or that we're investigating). No technical jargon, no blame, no internal details. -->

## Question 5

The "5 whys" in a postmortem are used to:

A) Assign blame
B) Trace from symptom to systemic/root cause
C) List five people involved
D) Count how many things went wrong

<!-- ANSWER: B -->
<!-- EXPLANATION: 5 whys is a technique to dig from the surface symptom to deeper causes. "Why did X happen?" → "Because Y." "Why did Y happen?" → Repeat. You reach contributing factors in process and design, not just the immediate trigger. -->

## Question 6

To prevent incident fatigue, a good practice is:

A) Have one person always on-call
B) Limit consecutive weeks on primary; offer post-incident rest
C) Only page during business hours
D) Skip postmortems to save time

<!-- ANSWER: B -->
<!-- EXPLANATION: Limit consecutive primary weeks, rotate fairly, give IC rest after SEV1/2 (no meetings for a few hours). One person always on-call and skipping rest leads to burnout. -->

## Question 7

<!-- VISUAL: quiz-drag-order -->

Put these incident lifecycle phases in the correct order:

A) Mitigation (contain and fix)
B) Detection and triage
C) Post-incident review
D) Recovery (restore service)
E) Preparation (runbooks, on-call)

<!-- ANSWER: E,B,A,D,C -->
<!-- EXPLANATION: Prepare first (runbooks, on-call). When an incident occurs, detect and triage, then mitigate (contain and fix), recover (restore service), and finally conduct a post-incident review to learn. -->

## Question 8

<!-- VISUAL: quiz-drag-order -->

Put these postmortem sections in a logical order for the document:

A) Timeline of events
B) Root cause analysis
C) Impact and severity
D) Action items
E) Summary

<!-- ANSWER: E,C,A,B,D -->
<!-- EXPLANATION: A postmortem typically opens with a summary, then impact/severity, a chronological timeline, root cause analysis (5 whys, etc.), and closes with action items to prevent recurrence. -->