Restoring an earlier application artifact does not necessarily restore a changed database, infrastructure resource or access policy. A deployment rollback is one possible recovery action; a recovery plan explains which action is appropriate for the state the system is actually in.
Start by identifying the objects that the release can change and the assumptions that connect them. A previous artifact can still exist while its configuration or data assumptions are no longer valid.
Separate the states you need to understand
An application version, infrastructure configuration, infrastructure state record and live data describe different things. Include their relevant references in the review, rather than using one release label as a substitute for all of them.
For infrastructure managed with Terraform, state records information used to manage resources. It should not be treated as a backup of the application or the resources' data. Protect state according to its sensitivity and the backend's operating requirements.
A saved plan can help a reviewer inspect the intended infrastructure change. That does not remove the need to understand dependencies, authorization or changes made after the plan was produced. Keep the evidence associated with the exact change being considered.
Classify actions for this change
During planning, distinguish actions that are understood to be reversible, actions whose reversal depends on compatibility or preserved data, and actions that require a different recovery approach. These are assessments of the particular system, not permanent guarantees.
Ask what an earlier application version expects from its dependencies. Check whether data formats, permissions and infrastructure identities would remain compatible. Identify any step that could remove information needed for a later decision.
