✅ Incident Resolution Language

Correct: B. The mitigated/resolved distinction is operationally important. Mitigation might mean restarting a service, enabling a feature flag bypass, or redirecting traffic — the customer experience improves but the underlying bug persists. Resolution requires identifying and fixing the root cause. Many incidents remain in a "mitigated" state for days while the permanent fix is engineered, tested, and deployed.

State	Meaning	Example
Mitigated	Customer impact stopped; root cause not yet fixed	Traffic rerouted; broken service still exists
Resolved	Root cause fixed; system stable	Bug patched and deployed; normal operations confirmed

Correct: B. "Standing down" is a deliberate, formal close of the active incident response. Without it, responders remain uncertain whether they are still needed, bridges stay open unnecessarily, and the cognitive burden of the incident lingers. The phrase signals: the emergency is over, the team can return to normal operations. It mirrors military and emergency services language where "stand down" ends an alert or emergency posture.

Action at stand-down	What it closes
Bridge disbanded	Responders released; war room ends
Incident ticket updated	Status set to "Resolved"; post-mortem scheduled

Correct: B. "Monitoring for recurrence" reflects operational realism. A database connection pool exhaustion may deplete again under load. A cache warm-up may expose the same bug within minutes of the apparent fix. Committing to a monitoring window — and communicating it — tells stakeholders the team is being thorough rather than optimistic, and ensures the response team stays alert for recurrence rather than fully context-switching immediately.

Incident type	Recurrence risk
Connection pool exhaustion	High — can re-exhaust under traffic after restart
Cascading failure from downstream dependency	High — dependency may degrade again before fix deployed
One-off memory leak fixed by restart	Medium — leak will return; patch still needed

Correct: B. Vague post-mortem actions ("improve monitoring," "add more tests") reliably sit unactioned. Effective actions are SMART: specific about what to build or change, assigned to one named person (not a team), given a concrete due date, and tracked in whatever system the team uses for work. The post-mortem is only as valuable as the follow-through on its action items.

Ineffective action item	Effective action item
"Team to improve observability"	"Add connection pool utilisation alert at 80 % — Kenji — 2 weeks"
"Better testing needed"	"Add load test for pool exhaustion scenario to CI suite — Aiko — 3 weeks"

Correct: B. The all-clear is the formal, final signal that the incident is completely over. Without it, stakeholders remain uncertain ("is it really fixed?"), responders stay in a state of partial alert, and the psychological burden of the incident lingers. The phrase also serves a human purpose: acknowledging the team's effort. In some frameworks the all-clear also officially starts the post-mortem clock — the window for scheduling the review.

Incident closure step	What it communicates
"Mitigated"	Customer impact stopped; root cause work ongoing
"Resolved"	Root cause fixed; service stable
"All-clear"	Response formally ended; team stands down; post-mortem next