Rolling back application code may not roll back schema or data changes. Recovery planning must include both.
Before you start
You should understand commits, branches, the working tree and the staging area. Draw the commit graph before changing history. Try commands in a disposable repository with a clean working tree so you can observe exactly which references and files each operation changes.
The practical goal is to reason through this situation: A new release writes a new field that the previous binary must tolerate during rollback. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Inventory persistent changes
Schema and data evolve independently of application binaries.
Step 2: Use staged compatibility
Expand contracts before depending on them and defer destructive removal.
Step 3: Define forward recovery
Some data changes cannot safely be reversed by deploying old code.
Worked scenario
A new release writes a new field that the previous binary must tolerate during rollback.
A new release drops a column that the previous binary reads. Rolling back only the image now fails. An expand-and-contract rollout preserves compatibility during the recovery window; irreversible changes need a tested forward-fix or restore plan under explicit data-loss and downtime objectives.
Common mistake
A destructive migration can make binary rollback impossible.
Verify the behavior
Run old and new binaries against each supported schema stage.
Interview exercise
Plan a reversible rollout.
Answer and reasoning
Use compatible staged migrations and define forward recovery when data cannot safely be restored by reverting code.
Continue learning
Compare the scenario with the Git and CI/CD interview questions and test your understanding with the Git and CI/CD MCQs. For terminology and implementation details, consult the reference material.