If terraform plan proposes changes or replacements even though the Terraform code has not changed, investigate whether live cloud resources have drifted from the recorded state. A plan is an opportunity for review before execution, not an automatic approval signal.
Distinguish creation, modification, and deletion in a plan
In this example, the code requests two nodes but the live resources have three. State tracks the managed resources, and a plan proposes changes, but you still need to review why the extra node exists and what applying the plan would affect.
Do not approve a plan based on resource names alone. Check which attributes change and whether replacement is required. Destroying and recreating a resource can affect IP addresses, data, and downstream connections. If many unexpected changes appear, stop before apply and check the workspace, variables, and provider context.
terraform planFor example, if the code manages two nodes but someone changes the live count to three in a console, the next plan may propose returning to two. Before applying it, check whether that console change was an emergency measure. Plan output and saved plan files can contain identifiers or sensitive values; do not share them publicly without review.
State is operational data shared by the team
State files may contain resource identifiers, so use secure remote storage, access controls, and locking. If teammates overwrite local copies of state, concurrent changes can conflict. Follow Terraform's management and backup procedures rather than editing or deleting state directly.
Decide what to do about drift instead of hiding it
After an emergency console change, decide whether to update code to reflect it or restore the live resource to the code's intended state. Before using ignore rules to make a plan quiet, review whether the difference is intentional and how it affects security and cost.
In the two-node-code versus three-node-reality example, an emergency change may call for updating and validating the code. Alternatively, you may return to two nodes after the incident. If you choose the latter, also check the impact of reduced service capacity.
Apply the same saved plan that was reviewed
Regenerating a plan after review can produce different changes if code, variables, or live state have changed. For a change requiring approval, consider saving the plan, reviewing its readable output, and applying the approved file.
terraform plan -out=review.tfplan
terraform show review.tfplan
terraform state listThe first command saves a plan for the current configuration, the second displays its proposed changes, and the third lists resources tracked in state. Review every planned deletion or replacement. Do not apply a large unexpected change. Saved plans and state can contain identifiers and sensitive values, so restrict their storage and access rather than pasting them into public posts or chats.
Key takeaways
terraform plan is a review step for differences between code and infrastructure. Distinguish creation, modification, deletion, and replacement. Treat state as shared operational data protected by locking and least-privilege access. Decide explicitly whether code or the live environment should become the source of truth after drift.
