In Terraform, when are locals evaluated, and what shows up in the plan when a local's expression reads an attribute of a resource that does not exist yet?

## Locals are graph nodes, not statements The mental model people bring from scripting languages — "this line runs, then the next" — is wrong here and produces two predictable surprises. Terraform builds a dependency graph over everything in the configuration: resources, data sources, variables, outputs and locals alike. Each locals entry becomes a node whose edges are the things its expression references. Terraform then evaluates in dependency order. The first consequence is that **declaration order is irrelevant**. This is valid: ```hcl locals { full_name = "${local.name_prefix}-db" name_prefix = "${var.project}-${var.environment}" } ``` Terraform resolves `name_prefix` first because `full_name` depends on it, regardless of the order in the file or across several `locals` blocks in different files. The second consequence is that **a cycle is an error, not a race**. If `local.a` references `local.b` and `local.b` references `local.a`, the graph has no valid order and Terraform refuses to proceed with a cycle error naming the participants. The same applies to a local that references itself. There is no "last definition wins". ## Unknown values During plan, Terraform knows the configuration and the prior state, and it refreshes what already exists — but attributes of resources that do not exist yet, or attributes the provider only fills in at create time, are *unknown*. An unknown value is a first-class concept in Terraform's evaluation, and it is contagious: any expression consuming an unknown produces an unknown. So a local like this: ```hcl locals { bucket_arn = aws_s3_bucket.artifacts.arn } ``` is unknown on the first plan, and everywhere `local.bucket_arn` is used the plan renders `(known after apply)`. That is normal and healthy — it is Terraform being honest that it cannot show you the final value. It becomes a problem only in the places where Terraform *requires* a known value. ## Where unknowns become a hard failure The important case is repetition. `for_each` needs its **keys** known at plan time, because the keys become resource addresses in state, and Terraform cannot plan changes to addresses it cannot name. If a local computes a map whose keys come from a resource attribute — say, keying off `aws_instance.web[*].id` — the plan fails with an error saying the `for_each` value depends on resource attributes that cannot be determined until apply. `count` behaves the same way for its numeric value. Note the asymmetry: for `for_each` the *values* in the map may be unknown; only the keys must be known. The fix is architectural, not syntactic: key repetition off something you control — an input variable, a static list, a map defined in a local from literals — and let the resource attributes flow into the *arguments* of those instances rather than into their identities. ## Locals are module-scoped, not instance-scoped A locals block is evaluated once per module instance. It is not re-evaluated per resource instance, which is why `each.key`, `each.value` and `count.index` are not in scope inside a `locals` block — those symbols only exist inside the resource, data or module block that declares the repetition. Attempting to use them yields an error about a reference to an unavailable symbol. The standard workaround is to build the *structure* in locals and iterate over it in the resource. A nested `for` expression that produces a map of composite keys, consumed by a single `for_each`, is the idiomatic way to express "one thing per subnet per environment" without needing per-instance evaluation inside the local itself. ## Refresh, sensitivity and inspection Because locals sit in the graph, one that depends on a data source is re-evaluated whenever that data source is read during the run — its value is not frozen from a previous apply. Locals are not stored in state at all; there is no recorded prior value to compare, only the expression and its inputs. For debugging, `terraform console` evaluates `local.<name>` interactively against the current state, which is the fastest way to check what a gnarly expression really produces before you wire it into fifty resources. Values that are unknown in the current context simply come back as unknown there too, which is itself informative.