Terraform For_Each Known After Apply Fix

Threat/Impact Level: HIGH | Downtime Risk: HIGH | Time to Fix: 15–30 mins

TL;DR

• What broke: Terraform's for_each requires all map keys to be fully resolved at plan time. You used a computed attribute (e.g., a resource ID, ARN, or dynamic name) as a map key — Terraform can't build its dependency graph and hard-stops.
• How to fix it: Re-key your map using a value known before apply — a static string, an input variable, or a local value derived from non-computed fields.
• Fast path: Use our Client-Side Sandbox above to auto-refactor this — paste your failing .tf block and get corrected HCL without sending your config to any external server.

Error: Invalid for_each argument

  on main.tf line 14, in resource "aws_iam_role_policy_attachment" "this":
  14:   for_each = { for r in aws_iam_role.roles : r.id => r }

The "for_each" map includes keys derived from resource attributes that
cannot be determined until apply, so Terraform cannot determine the full
set of keys that will identify the instances of this resource.

To work around this, use the -target argument to first apply only the
resources that the for_each value depends on, and then apply normally.

The Blast Radius

This isn't just an inconvenience. In a CI/CD pipeline:

• Every downstream resource depending on the for_each resource is also blocked.
• Teams using -target as a workaround silently corrupt state — resources get created outside the full graph, leading to phantom drift that surfaces weeks later as mysterious diffs.
• In multi-environment setups (dev/staging/prod using the same module), the bug is often masked in dev (where resources pre-exist in state) and explodes in prod on first apply against a fresh account.
• If the computed key is an AWS ARN or GCP resource ID, the map key changes every time the upstream resource is recreated — causing cascading replacement of all for_each instances.

How to Fix It

Root Cause Pattern

The canonical mistake: using resource.attribute (computed post-apply) as the key of a for_each map.

# BAD: r.id is unknown at plan time — it's assigned by AWS after creation
- resource "aws_iam_role_policy_attachment" "this" {
-   for_each = { for r in aws_iam_role.roles : r.id => r }
-   role       = each.value.name
-   policy_arn = var.policy_arn
- }

# GOOD: r.name is defined in your Terraform config — known at plan time
+ resource "aws_iam_role_policy_attachment" "this" {
+   for_each = { for r in aws_iam_role.roles : r.name => r }
+   role       = each.value.name
+   policy_arn = var.policy_arn
+ }

Rule: The key in key => value must resolve from your .tf source or var.* — never from a provider-assigned attribute like .id, .arn, .unique_id.

Basic Fix — Re-key on a Static Attribute

If you're iterating over resources you define, always key on the field you wrote, not the field AWS/GCP assigned.

# Pattern: iterating over a map variable to create resources and attach policies

 variable "roles" {
   type = map(object({ policy_arn = string }))
 }

 resource "aws_iam_role" "this" {
   for_each = var.roles
   name     = each.key
 }

 resource "aws_iam_role_policy_attachment" "this" {
-  for_each   = { for k, v in aws_iam_role.this : v.id => v }
+  for_each   = aws_iam_role.this  # keys are already the static map keys from var.roles
   role       = each.value.name
   policy_arn = var.roles[each.key].policy_arn
 }

When you do for_each = aws_iam_role.this directly (a resource map), Terraform uses the same keys as the upstream for_each — which are your static var.roles keys. Problem solved.

Enterprise Best Practice — Locals as the Single Source of Truth

For complex pipelines, define a local that normalizes all keys upfront. Nothing downstream ever touches a computed attribute as a key.

- # Anti-pattern: building maps inline inside resource blocks using computed fields
- resource "aws_route53_record" "this" {
-   for_each = { for ep in aws_lb.app.subnet_mapping : ep.allocation_id => ep }
-   ...
- }

+ # Best practice: local defines the authoritative key set from known values only
+ locals {
+   subnet_records = {
+     for idx, subnet_id in var.subnet_ids :
+     "record-${idx}" => {
+       subnet_id = subnet_id
+       lb_dns    = aws_lb.app.dns_name  # value (not key) can be computed
+     }
+   }
+ }
+
+ resource "aws_route53_record" "this" {
+   for_each = local.subnet_records      # keys are "record-0", "record-1" — static
+   name     = each.value.lb_dns
+   ...
+ }

Key discipline: In local maps used for for_each, the left side of => must never reference a resource.* computed field. The right side (value) can reference anything.

💡 Tired of pasting proprietary infrastructure configs into public LLMs? Generic AI interfaces log your company's ARNs, connection strings, and private keys. StackEngine enforces client-side zero-trust boundaries—the sandbox above executes 100% locally in your browser. Drop your broken manifest above to redact secrets locally and synthesize deterministic patch drafts with your own API key.

(For CI/CD pipeline automation, install via npm i -g stackengine).

# In GitHub Actions / GitLab CI — always run plan and capture exit code
terraform plan -detailed-exitcode -out=tfplan
# Exit code 2 = changes pending (not an error). Exit code 1 = hard error including this one.

tflint --enable-rule=terraform_required_providers
# More importantly, use the tflint-ruleset-aws plugin which flags dynamic key patterns
tflint --plugin-dir ~/.tflint.d/plugins

# policy/no_computed_foreach_keys.rego
package terraform

deny[msg] {
  resource := input.resource_changes[_]
  # Flag any for_each whose key_type is marked unknown_only
  resource.change.before == null
  resource.change.after_unknown.id == true
  msg := sprintf("Resource '%s' uses a computed key in for_each. Re-key on a static attribute.", [resource.address])
}