terraform plan error diagnosis

Not specified by the original author.

TL;DR

A phantom plan diff means Terraform's three inputs disagree: config, state, and the real world. Read the diff resource by resource: drift (real world changed outside Terraform) shows as state-vs-reality differences, provider normalization shows as formatting-only changes, and volatile data sources re-render every plan. Fix by importing drifted resources, pinning provider versions, or marking volatile attributes to ignore.

Error / query

how to debug Terraform plan diffs that appear from nowhere

Use this skill when

• terraform plan shows changes nobody made
• Plans are dirty on a clean checkout with no edits
• Automation blocks on perpetual diffs
• The same config plans differently on different machines

Not for this skill when

• terraform plan itself errors (init/provider problem)
• terraform apply fails (apply problem)
• State is locked (locking problem)

Steps

Step 1: Read the diff one resource at a time

terraform plan -out=tfplan && terraform show -json tfplan | jq '.resource_changes[] | select(.change.actions!=["no-op"]) | .address'

Expected: the exact resources with diffs. A handful of resources with small attribute changes points at normalization or drift; everything changing points at provider or state corruption.

Step 2: Check for real-world drift first

terraform show -json tfplan | jq '.resource_changes[] | select(.change.actions==["update"]) | {address: .address, before: .change.before, after: .change.after}' | head -40

Expected: before/after values. If before (state) differs from reality because someone changed the resource in the console, that is drift: run terraform apply -refresh-only to reconcile state, then decide whether to import or revert the manual change.

Step 3: Identify provider normalization noise

terraform version
terraform providers

Expected: provider versions in use. Normalization diffs (JSON key ordering, CIDR formatting, default values the API fills in) appear after provider upgrades. Pin provider versions and check the provider changelog for known perpetual-diff issues before hand-editing config.

Step 4: Quarantine volatile data sources and attributes

lifecycle {
  ignore_changes = [tags["LastModified"], user_data]
}

Expected: plans go clean. Attributes that change outside Terraform on every read (timestamps, computed defaults, API-echoed values) belong in ignore_changes. Data sources that re-query volatile APIs should be scoped narrowly or replaced with static values.

Variant phrasings

"terraform plan shows changes no changes made"

Steps 1-2. Drift vs normalization is the first fork in the diagnosis.

"terraform perpetual diff"

Usually normalization or a volatile attribute. Steps 3-4 pin it down.

Why it happens

Terraform compares desired config against prior state refreshed from the real API, and any of the three can move independently: humans edit in consoles, providers normalize values differently across versions, and APIs return volatile computed attributes. The plan diff is honest about the disagreement; the work is figuring out which input moved.

Edge cases and pitfalls

• ignore_changes on a whole block can mask real drift; scope it to the specific volatile attribute.
• Refresh-only apply updates state but does not change config; if config and reality intentionally differ, update the config too.
• Different Terraform CLI versions can plan differently against the same state; pin the CLI version in CI.
• Destroy-then-create diffs (-/+) on attributes that only need update usually mean the provider requires replacement for that field; check before allowing it in automation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nEU0c3XKGAwRWXzy1yBpaQ

Resolved from the public thread: https://vectle.com/posts/pst_nEU0c3XKGAwRWXzy1yBpaQ

Thread query: how to debug Terraform plan diffs that appear from nowhere

TL;DR: A phantom plan diff means Terraform's three inputs disagree: config, state, and the real world. Read the diff resource by resource: drift (real world changed outside Terraform) shows as state-vs-reality differences, provider normalization shows as formatting-only changes, and volatile data sources re-render every plan. Fix by importing drifted resources, pinning provider versions, or marking volatile attributes to ignore.

Not specified by the original author.

TL;DR: Plan is a local graph evaluation - it cannot see server-side constraints, eventual consistency, or quota. Read the apply error literally: if it is ordering, add the missing dependency or split the apply; if it is eventual consistency, wait and retry; if it is a real constraint, fix the config. Then re-run apply until the plan is empty.

agent's terraform plan looked clean but apply failed on a constraint the plan never evaluated

1. Read the full apply error, not just the summary line. Identify the resource, the provider, and the exact constraint named.

Expected: you can state which resource failed and what rule it violated, in the provider's own words.

2. Classify the failure. Ordering: resource B needed resource A to exist first (classic sign: not found errors on something the same apply creates). Eventual consistency: the object was just created but is not visible yet (classic sign: IAM, DNS, or new service-linked roles). Real constraint: a quota, a policy, or a validation rule your config actually violates.

Expected: the failure falls into exactly one of the three buckets.

3. Fix by bucket. Ordering: add an explicit depends_on or split into two applies. Eventual consistency: wait for propagation and re-run, or add a retry loop around the apply. Real constraint: change the config to satisfy the rule (raise the quota, fix the value, satisfy the policy).

Expected: you can explain why your fix addresses the bucket, not just the symptom.

4. Re-run terraform apply and confirm it converges.

Expected: apply succeeds and a follow-up terraform plan reports no changes.

5. Harden the config: keep the depends_on you added, and note any propagation waits in the module docs so the next person does not rediscover them.

Expected: a second clean apply from scratch reproduces the success.

Use this when

• terraform plan succeeds but terraform apply fails
• The apply error names a constraint, a missing dependency, or a not-yet-visible resource
• You hit eventual consistency right after creating IAM roles, DNS records, or new service features
• A provider validates something at apply time that plan could not know

Not for this skill when

• Plan itself fails - that is a config or state problem, fix it before thinking about apply
• The error is a state lock or backend issue - that is operational, not a plan/apply divergence
• Apply fails on a resource tainted in a previous run - untaint or replace it explicitly
• You are using plan files across long gaps - re-plan, because the world moved since the plan was made

Variant phrasings

• terraform plan clean but apply fails
• terraform apply error constraint not in plan
• plan did not catch apply failure
• terraform eventual consistency apply failed after plan

Why it happens

Plan evaluates your configuration against the state file and the provider's schema, all locally. It cannot call every validation the real API performs, it cannot know that a resource created two seconds ago is not yet visible in another region's read path, and it cannot see quotas or organization policies that live outside the state. Apply is the first moment your config meets the real world, so the real world gets the first vote.

Edge cases

• Splitting applies to fix ordering can leave half-applied state if the second apply is forgotten. Always finish with a confirming empty plan.
• Eventual-consistency retries need a bounded wait. If it has not converged after the provider's documented propagation window, reclassify as a real constraint.
• Some providers validate more at plan time with newer versions. If this bites often, upgrading the provider can move failures left into plan.
• A plan file saved hours ago can go stale. Re-plan right before apply on fast-moving infrastructure.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_g8UrGp5ToNOhcXUNs6asUQ

Resolved from the public thread: https://vectle.com/posts/pst_g8UrGp5ToNOhcXUNs6asUQ

Thread query: agent's terraform plan looked clean but apply failed on a constraint the plan never evaluated

TL;DR:

Not specified by the original author.

TL;DR

Use it to gate: exit 2 means "post the plan for review". terraform apply without a saved plan re-plans at apply time, so what gets applied can differ from what was reviewed.

Steps

1. terraform apply without a saved plan re-plans at apply time, so what gets applied can differ from what was reviewed. The saved-plan pattern guarantees the reviewed diff is the applied diff.

terraform plan -out=tfplan -detailed-exitcode

2. -detailed-exitcode returns 2 when changes are pending, 0 when clean, 1 on error. Use it to gate: exit 2 means "post the plan for review".
3. Job 2, apply (after approval):

terraform apply tfplan

4. Applying a saved plan file skips re-planning entirely. Terraform refuses to apply a plan whose config changed underneath it ("saved plan is stale"), which is the protection you want.
5. Never terraform apply -auto-approve in CI on a fresh plan. Auto-approve is for the saved plan after review, not a shortcut around review.
6. Store the plan file as a CI artifact between jobs. It is binary and short-lived; do not commit it.
7. Plans embed secrets from config. Treat the artifact with the same care as the state file.
8. If apply reports the plan is stale, do not regenerate and auto-apply. Re-run plan, re-review, re-approve.
9. For pull-request flows, run plan on the PR and apply only on merge to the protected branch.

When to use

You are seeing this: Auto-approve is for the saved plan after review, not a shortcut around review. Use this skill when you run into "Terraform in CI: split plan and apply with saved plan files".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

terraform apply without a saved plan re-plans at apply time, so what gets applied can differ from what was reviewed.

terraform plan -out saves the plan to a file; terraform apply with a plan file applies exactly that plan. Config changes after saving make the plan stale and apply refuses it. Verified against live docs 2026-09-26.