A configuration change that broke a production service was applied an hour ago through the normal pipeline. The team wants to restore the previous infrastructure settings safely and keep state consistent with reality. Which rollback approach is appropriate?
Select an answer to reveal the explanation.
Short Explanation
In Terraform, you roll forward to the past. Revert the code, plan, and let Terraform push the old settings back out. Restoring an old state file is like changing the map but not the territory, and that's how you end up with orphaned resources.
Full Explanation
Terraform converges real infrastructure toward configuration, so the reliable way to undo a change is to make configuration describe the previous settings again, typically by reverting the commit, and then run a normal plan and apply. The plan shows exactly which attributes will return to their earlier values, giving reviewers a chance to spot changes that cannot be cleanly reversed, such as replaced resources or deleted data. Restoring a previous state version only changes Terraform's records; it does not alter infrastructure, and it can leave state describing objects that no longer exist or missing objects that do, which HashiCorp warns can result in orphaned or duplicated resources. Refresh-only mode updates state to match the real infrastructure and never pushes configuration values out, regardless of which commit is checked out. Destroying production and reapplying causes a full outage and loses any data held in stateful resources, far beyond what a rollback needs. Exam caveat: some changes, such as deleted databases or rotated keys, cannot be undone by configuration alone and need backups or provider-level recovery. Operational check: after applying the revert, run another plan and confirm it reports no changes, then verify service health.