Terraform wants to change something nobody changed

Before you start

• A terminal in the same working directory and workspace as the surprising plan, with terraform init done and the same Terraform and provider versions as your pipeline, so you read the same state.
• Provider credentials that can read every resource in that state. A refresh reads each one, and HashiCorp warns that with misconfigured credentials Terraform may conclude that managed objects were deleted.
• Read access to your cloud provider's audit log for the time since the last apply, to see who changed what and when.
• The log or plan of the last successful apply, so you know what the infrastructure was meant to look like.
• Agreement from the resource's owner before you either revert a manual change or copy it into configuration.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Check it with a tool

• Why Terraform needs state at all→
• CI/CD security: logging and visibility→

Or diagnose it manually

In this order. The first command usually contains the whole answer.

1. Step 1

   terraform plan -refresh-only

   Separates "reality changed" from "Terraform wants to change something", which is the fork this whole investigation turns on.

   Look for Changes here are genuine drift. An empty refresh-only plan alongside a non-empty normal plan means the difference is in configuration or normalisation, not in reality.

2. Step 2

   terraform plan -no-color | grep -E 'be replaced|be destroyed|^Plan:'

   Checks for destruction before anything else, because that is the only outcome on this page that can be unrecoverable.

   Look for A must be replaced, will be replaced or will be destroyed heading on a resource holding data, or a Plan: line with anything but 0 to destroy. Stop there and confirm.

3. Step 3

   terraform plan -out=tfplan   # read it: no -/+ or destroy
   terraform apply tfplan        # this changes real infrastructure
   terraform plan                # empty = fixed; the same change again = normalisation

   The decisive test for normalisation: a change that survives its own apply was never drift.

   Look for An empty second plan means it was drift and is fixed. A repeat means normalisation.

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

terraform plan -refresh-only

terraform plan -refresh-only   # see the drift without acting on it

# For attributes that legitimately change elsewhere:
lifecycle {
  ignore_changes = [tags["LastScanned"], desired_count]
}

terraform plan -out=tfplan && terraform apply tfplan && terraform plan   # applies real changes: read the first plan before approving

terraform state show <address>

terraform state rm <address>        # or: terraform apply -refresh-only, which drops the deleted object
terraform import <address> <provider-id>

terraform version && grep -rn 'required_providers' -A5 . | head -20

terraform plan -no-color | grep -E 'be replaced|be destroyed|^Plan:'

lifecycle {
  prevent_destroy = true
}

How to know it is actually fixed

• ✓terraform plan is empty, and stays empty on a second run — the second run is what distinguishes a fix from a temporary suppression.
• ✓If the manual change was adopted, it is visible in configuration rather than only in state.
• ✓For a forced replacement that was intended, the dependent resources still work — a replaced resource usually gets a new identifier.

Stopping it happening again

• Run a scheduled refresh-only plan and alert on non-empty output. Drift found the day it happens is a tidy-up; drift found during an unrelated urgent change is an incident.
• Remove or restrict console write access for resources Terraform manages. It is the only prevention that addresses the cause rather than the symptom.
• Use ignore_changes deliberately for attributes that legitimately change elsewhere, so a noisy plan does not train the team to skim.
• Put prevent_destroy on anything holding data, so an accidental replacement fails rather than proceeding.

Security considerations

• Check the audit log before adopting drift into configuration. A change made outside Terraform may be an unauthorised one, such as an opened port, and copying it into code makes it permanent.
• Read a refresh-only plan before applying it, and do not use terraform refresh, which is terraform apply -refresh-only -auto-approve. HashiCorp warns that with misconfigured credentials Terraform may think every managed object was deleted and remove them all from state without a prompt.
• Keep ignore_changes off security settings such as firewall rules and access policies. Terraform ignores the listed attributes when planning updates, so later tampering with them stops showing up in any plan.
• prevent_destroy blocks replacements but not removal of the resource block. Reproduced on Terraform 1.14.0: with the block deleted, the plan destroyed the object with no error, as HashiCorp's lifecycle page says. Keep backups and the provider's own deletion protection on data stores as well.
• Plan output shows attribute values, and HashiCorp says a saved plan file stores sensitive values in cleartext. Redact IDs and values before sharing drift output, and keep plan files as private as state.