A Terraform plan fails with "Invalid for_each argument: the for_each value depends on resource attributes that cannot be determined until apply". Why does Terraform refuse, and how do you restructure the configuration instead of reaching for -target?

## What the error is actually saying Terraform's run is ordered: it builds the resource graph, **expands** each resource into instances, then diffs each instance address against state to produce the plan. Expansion has to happen first, because "how many instances and what are they called" determines what the plan is even comparing. That ordering is the entire reason for the constraint: > for `count`, the number must be known at plan time; for `for_each`, the **keys** must be known at plan time. What is *not* required is that the values be known. A map whose keys you wrote down but whose values are attributes computed during apply is perfectly legal — the diff can show `(known after apply)` for those arguments because the instance addresses are already settled. ## The shape that triggers it The classic failure is building a collection out of identifiers that do not exist yet: ```hcl resource "aws_vpc" "main" { for_each = toset(["blue", "green"]) cidr_block = "10.0.0.0/16" } # Invalid for_each argument: the keys are VPC ids, # which the provider only assigns during apply. resource "aws_subnet" "bad" { for_each = toset([for v in aws_vpc.main : v.id]) vpc_id = each.value cidr_block = "10.0.1.0/24" } ``` On a first run the VPC ids are unknown, so Terraform cannot say whether there will be one instance, two, or two with different names, and it refuses rather than guessing. Confusingly, the same configuration *plans fine* once the VPCs exist and their ids are in state — which is how this reaches CI: it works on the developer's already-applied workspace and fails the moment someone builds a fresh environment. ## The fix: key on what you wrote, not on what the cloud returns A resource that itself uses `for_each` is exposed as a map keyed by the same keys. Iterating *that* keeps the keys static while letting the values be unknown: ```hcl resource "aws_subnet" "good" { for_each = aws_vpc.main # keys "blue" / "green" — known now vpc_id = each.value.id # unknown until apply — allowed cidr_block = "10.0.1.0/24" } ``` The general rule generalises well: **the key should come from your inputs, the unknown should live in the body.** If the source data is a list of objects, project it with a `for` expression keyed by a name you control: ```hcl for_each = { for s in var.subnets : s.name => s } ``` Other variants of the same move: - Iterate a variable or local (`var.environments`, `local.services`) and look the id up inside the block. - Where a value must come from elsewhere, read it with a data source that resolves at plan time rather than from a resource created in the same run. - Avoid computing keys with functions over unknown data — `toset`, `keys`, `merge` and friends all propagate unknownness; wrapping an unknown in `toset()` does not make it known. ## Why -target is not the answer The error text suggests applying the dependency first with `-target`, then running a normal apply. It genuinely works, and for a one-off bootstrap it is acceptable. As a design it is not, because: - every fresh environment now needs a documented two-phase apply, which someone will forget; - CI has to encode a partial apply, and a partial apply is exactly the thing pipelines are supposed to avoid; - the failure is silent on already-applied workspaces, so the two-phase requirement is invisible until disaster recovery. If you find yourself writing the `-target` step into a runbook, treat that as a signal to restructure the keys instead. ## count has the same constraint `count = length(something_unknown)` fails for identical reasons, with a matching "Invalid count argument" message. The workaround people reach for there — `length(var.list)` instead of `length(resource_attribute_list)` — is the same principle: derive multiplicity from configuration, never from provider output. ## What to say in an interview Name the ordering (expand, then diff), state the precise rule (keys known at plan, values may be unknown), show the fix of iterating the keyed map or a variable, and finish by explaining why the suggested `-target` is a bootstrap escape hatch rather than an architecture.