An engineer runs a routine capacity-removal command with a typo. It removes far more than intended and a core service is down for hours. What does the postmortem conclude?

What the interviewer is testing

Whether you produce systemic findings rather than stopping at human error, which is where weak postmortems end.

What the postmortem must not conclude

"An engineer made a mistake; we will remind everyone to be careful." That finding is unactionable, it will not prevent recurrence, and it teaches the organisation that reporting mistakes is dangerous — which reduces the information available for every future incident.

Typing errors are a constant. The system's tolerance of them is the variable.

The systemic findings

Tooling with unbounded blast radius. A single command could remove an arbitrarily large fraction of a critical subsystem's capacity. The fix is a limit enforced by the tool: it cannot take capacity below a safe minimum, it removes capacity gradually rather than instantly, and it requires confirmation proportional to the scale of the action.

No preview. The command did not show what it was about to affect before acting. A dry-run showing "this will remove 47 servers, including 12 in the index subsystem" would have stopped it.

Untested cold start. Recovery required restarting subsystems that had not been fully restarted in years, so the restart path and its duration were unknown. Recovery time was not a measured property, which means any recovery objective referencing it was fiction.

Insufficient blast-radius partitioning, so one region's subsystem was a single unit rather than cells that fail and restart independently.

Status communication depended on the affected system, so customers could not be informed. This is the one organisations most often share and most often have themselves.

The general questions to take away

What is the maximum damage a single operator command can do, and is the limit enforced by the tool rather than by the operator's care?

When did this system last cold start, and how long did it take?

Does your incident communication path depend on what it reports on — status page, alerting, chat, runbooks, authentication?

What a strong answer adds

That the engineer following an established playbook correctly is evidence the playbook and its tools were the defect. Blameless is not a courtesy; it is what makes the real causes visible.

Common weak answers

Additional training or a second pair of eyes for command execution. A rule requiring commands to be typed carefully.