terraform plan failed

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

For "Error: Failed to get existing workspaces: AccessDenied: Access Denied": check the bucket policy and IAM policy for the four operations state needs: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket on the state bucket and key prefix. If locking uses DynamoDB, the identity also needs dynamodb:GetItem/PutItem/DeleteItem on the lock table. A 403 that only appears during apply (not plan) often means the lock table permissions are missing. The S3 403 that survives an IAM fix is usually KMS.

Error: Failed to get existing workspaces: AccessDenied: Access Denied
  status code: 403 ...

When to use

You are seeing this: ` Error: Failed to get existing workspaces: AccessDenied: Access Denied status code: 403... ` or on the S3 backend, 403s during init, plan, or state operations. Use this skill when you run into "Terraform: 403/AccessDenied on the backend is an IAM problem, not a Terraform problem".

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.

What you are seeing

Error: Failed to get existing workspaces: AccessDenied: Access Denied
  status code: 403 ...

or on the S3 backend, 403s during init, plan, or state operations. Terraform is telling you the credentials it has cannot read or write the state location. The config is almost certainly fine.

First response

1. Confirm which credentials Terraform is using. For AWS: check env vars, shared config, instance profile, in that precedence order. aws sts get-caller-identity tells you who you actually are.
2. Check the bucket policy and IAM policy for the four operations state needs: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket on the state bucket and key prefix. Missing any one of them produces a different confusing failure.
3. If locking uses DynamoDB, the identity also needs dynamodb:GetItem/PutItem/DeleteItem on the lock table. A 403 that only appears during apply (not plan) often means the lock table permissions are missing.
4. KMS-encrypted buckets need kms:Decrypt/kms:GenerateDataKey too. The S3 403 that survives an IAM fix is usually KMS.

Rules for agents

1. Do not "fix" a 403 by making the bucket public or widening the policy to s3:*. Scope the fix to the state prefix.
2. Never paste long-lived keys into backend config to dodge the issue. Fix the identity, not the config.
3. If it worked yesterday and 403s today, check for expired credentials, rotated keys, or a changed bucket policy before anything else.
4. Reproduce outside Terraform first: aws s3 ls on the bucket path. If the CLI 403s, Terraform will too, and you have eliminated Terraform from the suspect list.

S3 backend requires bucket/key/region config plus IAM permissions on the bucket and (for locking) DynamoDB table; KMS-encrypted buckets need key permissions. Verified against live S3 backend docs 2026-09-26. Verified against live docs 2026-09-26.