terraform plan error

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.

Not specified by the original author.

TL;DR: A plan that wants to create every resource from scratch usually means Terraform is looking at an empty or wrong state file. The procedure confirms the backend binding before anyone applies. Diagnosing the wrong-state-file problem: plan wants to create everything Symptom terraform plan proposes creating all resources in a workspace that should already exist. Check the backend directly: does the expected state object exist in the bucket at the expected key?

The error

text
?

## Fix

1. Wrong workspace:

The fix

TL;DR: A plan that wants to create every resource from scratch usually means Terraform is looking at an empty or wrong state file. The procedure confirms the backend binding before anyone applies. Diagnosing the wrong-state-file problem: plan wants to create everything Symptom terraform plan proposes creating all resources in a workspace that should already exist. Check the backend directly: does the expected state object exist in the bucket at the expected key?

The error

?

## Fix

1. Wrong workspace:

Symptom

terraform plan proposes creating all resources in a workspace that should already exist. Everything shows as new.

Cause

Terraform is reading the wrong state: wrong workspace selected, backend rebound to a new key, state file lost, or init pointed at a fresh backend.

Confirmation

1. terraform workspace show (or check the backend key). Is this the workspace you think it is?
2. terraform state list | wc -l and terraform state pull | grep serial. Empty list or serial 1 means fresh/empty state.
3. Check the backend directly: does the expected state object exist in the bucket at the expected key? If yes, Terraform is bound to the wrong key. If no, the state is actually gone.
4. git log on backend config: did the key or bucket change recently without -migrate-state?

Fix

1. Wrong workspace: terraform workspace select [correct]. Then plan again.
2. Wrong backend key - fix the backend config (or -backend-config) and init -reconfigure to rebind to the correct existing state. Back up first.
3. State actually lost: restore from backend versioning (S3 versioning exists for this) or from your own backups, then terraform state push. If no backup exists, the recovery is re-import of every object (see the brownfield import workflow).

Verification

1. After rebinding, terraform plan must show no changes (or only expected ones). A create-everything plan after a "fix" means you bound to a different empty state.
2. terraform state pull serial and lineage should match the known-good values.

STOP: never apply a create-everything plan on existing infrastructure. That is how you get duplicates of everything.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Diagnosing the wrong-state-file problem.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Workspaces namespace state per backend; init -reconfigure rebinds backends; state pull/push backs up and restores. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR: The provider's plan output contradicted itself: it planned a value then changed its mind. Different from the after-apply variant; this one blocks planning and points at config or provider planning logic. Check the provider version. Applying cannot proceed because planning never completes.

The error

. Targeted applies on a broken plan just move the failure.
3.

What you are seeing

Error: Provider produced inconsistent final plan

When expanding the plan for aws_db_instance.main to include new values
learned so far during apply, provider "registry.terraform.io/hashicorp/aws"
changed the planned action for ...

This fires during plan, not apply. The provider first planned one set of changes, then during the plan walk learned new values (from other resources) and produced a contradictory final plan.

First response

1. Look at which resource and attribute flipped. Common trigger: a computed value from resource A feeds resource B, and the provider cannot decide B's plan until A is known. Restructuring to break the feedback loop often fixes it.
2. Simplify: replace complex expressions (nested conditionals, dynamic blocks keyed on computed values) with plainer config and re-plan. If the error disappears, bisect back to the offending expression.
3. Check the provider version. Planning-logic bugs get fixed; upgrading the provider resolves a real share of these.

Rules for agents

1. This is not fixed by applying. Applying cannot proceed because planning never completes.
2. Do not paper over it with -target. Targeted applies on a broken plan just move the failure.
3. depends_on does not fix planning contradictions; it only orders operations. Adding depends_on to an inconsistent plan is superstition.
4. If the inconsistency involves a module output feeding back into the same module's input, that is a design smell. Break the cycle with a data source or a second apply stage.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Terraform.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Inconsistent final plan errors arise from provider planning logic when new values learned during plan contradict earlier planned actions. Verified against live docs 2026-09-26. Verified against live docs 2026-09-26.