You deploy at 4pm and errors spike at 4:05. Walk me through exactly what you do.

Question

Accepted Answer

Roll back first, diagnose second. The deploy is the obvious suspect and reverting is the fastest path to a known-good state, so if it is behind a feature flag I turn the flag off, which takes seconds, otherwise I redeploy the previous artifact. I say what I am doing in the incident channel as I do it, so nobody else makes a conflicting change. Then I confirm with the error rate actually returning to baseline rather than assuming, because if errors persist after rollback my assumption was wrong and it may be a dependency, not my change. Before cleaning anything up I capture logs, traces and the failing image tag, since that evidence disappears. Only then do I investigate properly, and the output is a blameless write-up plus one concrete change, usually a test or an alert, that would have caught it before 4pm.

Answer

The rollback does not fix it. What does that tell you?

The deploy probably was not the cause, or it did something irreversible like a schema migration or corrupted cache. Widen the search to dependencies, infrastructure changes and traffic patterns.

Answer

What if the release included a database migration?

Rollback is no longer simple, which is why migrations should be backward compatible and shipped separately from the code that uses them. You may have to fix forward instead.

You deploy at 4pm and errors spike at 4:05. Walk me through exactly what you do.

You deploy at 4pm and errors spike at 4:05. Walk me through exactly what you do.

The follow-ups they ask next

What the interviewer is listening for

What sinks the answer

If you genuinely do not know

Keep going with deployment

Knowing the answer is not the same as recalling it under pressure