terraform plan error fix

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.

Fix terraform "Error: Invalid index"

TL;DR: You indexed a list or looked up a map key that does not exist: an empty collection, or an index past the end. Print length() of the collection to confirm, then guard the access with a length check or try(), or fix whatever upstream data source returned the empty collection.

The error

Error: Invalid index

  on main.tf line 95, in locals:
  95:   subnet_id = tolist(data.aws_subnets.default.ids)[0]
      |----------------
      | data.aws_subnets.default.ids is empty list of string

The given key does not identify an element in this collection value: the collection has no elements.

Steps

1. Confirm the collection is empty: add output "debug_len" { value = length(data.aws_subnets.default.ids) } and plan. Expected: it prints 0.

2. Guard the access so an empty collection is legal:

   subnet_id = length(data.aws_subnets.default.ids) > 0 ? tolist(data.aws_subnets.default.ids)[0] : null

   or try(tolist(data.aws_subnets.default.ids)[0], null). Expected: plan proceeds with null instead of erroring.

3. Fix the upstream cause if the collection should not be empty. In the classic case the default VPC had no subnets (someone deleted them); recreate them with aws ec2 create-default-subnet --availability-zone YOUR_AZ --region YOUR_REGION. Expected: the data source returns subnets again.
4. Remove the debug output and re-plan. Expected: a clean plan.

When this applies

• Any Error: Invalid index where the diagnostic shows an empty tuple/list or a key the map does not have.
• [0] on a data source result that can legitimately come back empty.

When it does NOT apply

• Invalid count argument. That is about expansion with unknown values, not indexing a known-but-empty collection.
• Invalid function argument. That is a function receiving a wrong-typed value.

Tool and version compatibility

• Terraform CLI 0.12+ through 1.x. try() exists since 0.13 and is the cleanest guard.

Why it happens

Terraform indexing is strict: list[0] on an empty list is an error, not null. Data sources that filter aggressively (or infrastructure that drifted, like deleted default subnets) hand you an empty collection, and the index that worked last month blows up today.

Edge cases and pitfalls

• During destroy, data sources can empty out mid-run as dependencies are torn down. Code that indexes [0] on a data source should be wrapped in try() if destroy must work.
• element(list, index) wraps around instead of erroring, which hides bugs. Prefer an explicit length check or try() so emptiness is visible.

A foundations guide hit Error: Invalid index on tolist(data.aws_subnets.default.ids)[0] because the default VPC had no subnets left. The verified fix was checking the subnets with the AWS CLI and recreating the default subnets, after which the index worked. Source: sarowar-alam/terraform-iac-foundations-to-3tier 06-ec2-deployment README, https://github.com/sarowar-alam/terraform-iac-foundations-to-3tier/blob/HEAD/06-ec2-deployment/README.md