Terraform "Resource depends on values that cannot be determined until apply"

By Daniel Zoghalchali·Latchkey

A construct that Terraform must resolve at plan time - a count, a for_each key set, or a provider configuration - depends on a value that is only known after another resource is applied.

What this error means

plan fails because count, a for_each key, or a provider argument is derived from a not-yet-created resource’s attribute. Terraform cannot expand the plan because the value is unknown until apply.

terraform output

Error: Invalid count argument

  on main.tf line 12, in resource "aws_eip" "nat":
  12:   count = length(aws_subnet.public)

The "count" value depends on resource attributes that cannot be determined until
apply, so Terraform cannot predict how many instances will be created.

Diagnose it: init, state, or credentials?

Terraform failures in CI are dominated by backend and credential problems rather than configuration errors. Confirm the runner can initialise, authenticate, and lock state before reading the plan.

Terminal

terraform init -backend=true -input=false
terraform validate
terraform providers
terraform plan -input=false -no-color -detailed-exitcode
#   0 = no changes, 2 = changes, 1 = error

Common causes

count/keys derived from a computed attribute

Using another resource’s id/length/attribute (created during apply) to size a count or build for_each keys makes the value unknown at plan time.

Provider config depends on an apply-time value

Configuring a provider (e.g. an endpoint or token) from a resource attribute that does not exist until apply cannot be resolved during planning.

How to fix it

Drive count/keys from plan-time-known values

Size counts and for_each from variables/locals known at plan time, not from computed attributes.

main.tf

resource "aws_eip" "nat" {
  count = length(var.public_subnet_cidrs)   # known at plan time
}

Stage the apply when a real dependency exists

If the value genuinely must come from a created resource, apply in stages (-target the prerequisite first, then the dependent).
Refactor so the dependency uses a known input instead of a computed attribute where possible.
Avoid configuring providers from apply-time values.

How to prevent it

Base count/for_each on inputs known at plan time.
Avoid provider configuration that depends on apply-time attributes.
When unavoidable, split the apply into ordered stages.

Frequently asked questions

What causes Terraform "Resource depends on values that cannot be determined until apply"?

There are 2 common causes: count/keys derived from a computed attribute and provider config depends on an apply-time value. Using another resource’s id/length/attribute (created during apply) to size a count or build for_each keys makes the value unknown at plan time.

How do I fix Terraform "Resource depends on values that cannot be determined until apply"?

There are 2 fixes depending on which cause you have: drive count/keys from plan-time-known values and stage the apply when a real dependency exists. Work through them in order, since the first is the most common.

What does Terraform "Resource depends on values that cannot be determined until apply" actually mean?

plan fails because count, a for_each key, or a provider argument is derived from a not-yet-created resource’s attribute.

How do I stop Terraform "Resource depends on values that cannot be determined until apply" happening again?

Base count/for_each on inputs known at plan time. The prevention section lists 3 changes that keep it from recurring.