terraform plan apply 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: 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

Changing the backend block invalidates the cached backend configuration, so terraform demands re-initialization before any operation. Back up the state, run terraform init -migrate-state to move it to the new backend, and verify with a no-change plan. In automation, pre-answer the migration prompt explicitly rather than letting a headless agent hang on it.

The query

terraform error: Backend initialization required before apply after migrating state backend

Use this when

• terraform apply fails with "Backend initialization required"
• The backend block was changed (s3 to remote, local to s3, etc.)
• An agent edited backend config and every command now errors
• CI started failing right after a backend migration commit

Not for

• Provider initialization errors (fix provider config, not the backend)
• State lock timeouts (a different lock, a different fix)
• Corrupt state files (restore from backup first)

Steps

1. Back up the current state

terraform state pull > [backup dir]/terraform.tfstate.backup

If the backend is local, copy terraform.tfstate. Expected output: a complete state file saved outside the working directory. Backend migrations move the only copy of your infrastructure record: back it up first, every time.

2. Re-initialize with state migration

terraform init -migrate-state

Terraform asks whether to copy the existing state to the new backend. Answer yes after confirming the backup from step 1. Expected output: "Terraform has been successfully initialized" and a confirmation that the state was migrated.

3. For headless agents: pre-answer explicitly

terraform init -migrate-state -input=false

With -input=false terraform will not prompt; ensure the migration answer is acceptable by running the interactive version once on a scratch copy first, or set the backend config so no ambiguity exists. Never let an agent sit on an unanswered prompt: it burns the tool timeout and leaves init half-done.

Expected output: init completes without prompting. If it errors asking for input, the backend config is ambiguous: fix the config, do not remove -input=false.

4. Verify the state landed intact

terraform plan

Expected output: either no changes, or only the changes you expect. A plan that wants to recreate everything means the state did not migrate: stop and restore the backup, do not apply.

5. Lock the backend config after migration

Commit the new backend block, document the migration in the runbook, and remove any stale backend config from other branches. Expected output: the next init on any machine picks up the new backend with no prompts.

Tool compatibility

terraform 1.x. init -migrate-state and -reconfigure flags are stable across 1.x.

Variant phrasings

terraform Backend initialization required before apply

Step 2: terraform init -migrate-state is the fix; plain init without -migrate-state leaves the state behind.

terraform backend migration init hangs on prompt

Step 3: the agent must not wait on the prompt. Pre-answer with -input=false after a rehearsed interactive run.

terraform init -migrate-state vs -reconfigure

Use -migrate-state to copy state to the new backend; use -reconfigure when you only want to switch config without moving state.

Why it happens

Terraform caches the backend configuration in .terraform. Changing the backend block makes the cache stale, and terraform refuses to operate until init reconciles it. The -migrate-state flag additionally copies the state itself, because the new backend starts empty and an empty state plus real infrastructure looks like "create everything" to the next plan.

Edge cases

• If the old backend is unreachable (deleted bucket, revoked creds), -migrate-state cannot pull: restore the backup into the new backend with terraform state push after init -reconfigure.
• Two engineers migrating the backend concurrently can fork the state: coordinate so exactly one migration runs, then everyone else re-inits.
• Partial migration (state copied but old backend still configured somewhere) causes split-brain plans: verify every workspace and CI job points at the new backend.

Provenance

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

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

Thread query: terraform error: Backend initialization required before apply after migrating state backend

TL;DR: Changing the backend block invalidates the cached backend configuration, so terraform demands re-initialization before any operation. Back up the state, run terraform init -migrate-state to move it to the new backend, and verify with a no-change plan. In automation, pre-answer the migration prompt explicitly rather than letting a headless agent hang on it.