TL;DR: Name the mistake you made, explain how you disclosed and contained it, and show the evidence that a specific corrective action changed the failure path. Keep your responsibility visible without inventing a dramatic consequence or a perfect recovery.
How to approach it
Use an event you can discuss truthfully within confidentiality constraints. Prepare the timeline from discovery through recovery, including who performed each action. If the corrective work remains incomplete, say so and explain its current owner and status.
A strong answer
Begin with an action and its consequence. “I selected the production target while preparing a staging migration” explains your contribution more clearly than “there was a deployment issue.” Identify what the command actually did and how you discovered the error. Avoid claiming revenue or user impact when your evidence only establishes failed requests or a service interruption.
The first decision after discovery matters operationally. Notify the incident owner while preserving the command, target and relevant timestamps. Stop further changes you control. Do not assume killing a database session or reversing the last command is automatically the safest mitigation; an operation may be partially complete, and its cancellation may itself take time or require recovery.
In this fictional practice scenario, you run an index change on the wrong database. Application writes begin waiting. You notice the target mismatch two minutes later, inform the on-call responder and provide the session identifier. The database owner checks the operation and chooses cancellation after assessing its state. You suspend the deployment job so it cannot retry the change while cancellation proceeds.
That account separates discovery from diagnosis and authority. You caused the change, but the database owner made the cancellation decision. Claiming you “fixed the database” would conceal the collaboration and invite technical questions about an action you did not perform.
Recovery needs an observation beyond the command returning. Check that blocked writes clear and fresh application requests complete, then determine whether timeouts left ambiguous operations for reconciliation. Record the last known affected request and the uncertainty in the impact estimate. A green dashboard can coexist with work that still needs repair.
The follow-up should address why the wrong target was available through that path. A fictional corrective plan could remove routine production migration credentials from developer laptops and require a reviewed execution job with a target-specific identity. A visible environment label is helpful feedback, but the identity restriction provides a different control: it can reject an unauthorized operation even when someone overlooks the label.
Test the control deliberately in a safe fixture. Show that the staging identity cannot execute against the production target, that the approved production path still works and that the emergency procedure has an owner. Do not promise the system can never suffer a migration incident; a correctly targeted but defective migration remains a separate risk requiring review and rehearsal.
The Google SRE postmortem guidance supports examining contributing conditions and following through on actions. The scenario here is fictional and its specific access design must match the system being discussed.
What interviewers probe next
“Why did you have that access?” Explain the actual workflow and why it existed, including any convenience you accepted. Then describe the changed boundary. Naming a weak process does not remove your responsibility for the action.
“Did you make recovery worse?” If you did, state the intervention and its effect. Explain what evidence was available at the time and what check you now use before repeating it. Do not add a wrong turn simply because you think the story needs one.
“What remains possible?” Distinguish the closed path from adjacent risks. Restricting who can run a migration does not establish that every authorized migration is safe or reversible.
Common mistakes
Ending with “I double-check now” leaves the prevention claim dependent on memory. Explain the control, its test and its remaining limitations.
Using “we” for the mistake and “I” for the recovery distorts attribution. Rehearse with an action-owner timeline and correct every sentence that assigns someone else's work to you.
If you lack exact duration or impact figures, give the evidence you do have and its limit. Invented precision makes the rest of the account harder to trust.