What does a Terraform for expression produce, and how do you write one that yields a map instead of a list?

## The shape of the expression A `for` expression has four parts: the brackets, the iteration clause, the result expression, and an optional filter. ```hcl [for s in var.names : upper(s)] # tuple ["A", "B"] {for s in var.names : s => upper(s)} # object {a = "A", b = "B"} [for s in var.names : upper(s) if s != ""] # filtered ``` The **brackets choose the result type**, and this is the part interviewers actually probe. `[ ]` produces a *tuple* — an ordered sequence, which converts freely to a list. `{ }` produces an *object* — an unordered key/value structure, which converts freely to a map. Because an object needs a key, the object form requires the `key => value` arrow; leaving it out inside braces is a syntax error. ## Binding symbols to the source collection What the temporary symbols mean depends on what you are iterating: ```hcl [for v in var.list : v] # each element [for i, v in var.list : "${i}-${v}"] # index and element [for k, v in var.map : "${k}=${v}"] # key and value [for v in var.set : upper(v)] # sets allow ONE symbol only ``` A set has no index and no key, so asking for two symbols over a set is an error. This matters because `toset()` shows up constantly in Terraform code, and the collection you are iterating may have quietly become a set. ## Keys must be unique — or you opt into grouping The object form converts every key to a string and refuses duplicates: *"Two different items produced the key ... in this 'for' expression"*. That error is common when you key by a non-unique attribute, for example grouping instances by their type. The fix is **grouping mode**, marked by `...` after the value expression: ```hcl {for inst in var.instances : inst.type => inst.name...} # => { "t3.micro" = ["web-a", "web-b"], "m5.large" = ["db"] } ``` Each key now maps to a *list* of all matching values instead of a single one. ## Ordering and determinism A tuple built from a list keeps the source order. A tuple built from a **map or set** comes out in lexical order of the keys/elements, because Terraform iterates maps and sets in sorted order — that is a deliberate design choice so that repeated plans are deterministic and diffs are stable. If you need a specific order that is not lexical, you have to encode it in the data, for example by sorting on a field with `sort()` or by keying on a zero-padded string. ## Nesting and chaining Result expressions can themselves be `for` expressions, which is how you flatten or pivot nested data: ```hcl # every (subnet, port) pair from a map of subnets and a list of ports locals { rules = flatten([ for name, cidr in var.subnets : [ for port in var.ports : { name = name, cidr = cidr, port = port } ] ]) } ``` `flatten()` collapses the list-of-lists into one list. This flatten-a-nested-comprehension shape is the canonical answer when someone asks how to produce a cross product of two inputs, and it is worth being able to write it from memory. ## for expression vs. the for_each meta-argument These are different things that share a word. A `for` expression is a *value* — it computes a collection anywhere an expression is allowed. It is one of the main ways people *build* the collection they later hand to a resource, but the expression itself creates nothing. Reshaping a list of objects into a map keyed by a stable identifier is a value-level transformation, and the for expression is the tool that does it. ## Type conversion at the edges A tuple is not literally a list and an object is not literally a map — they are the structural types Terraform infers, where each element may have its own type. Terraform converts automatically wherever the target's type constraint demands it, and `tolist()`, `toset()` and `tomap()` force the issue. The conversion can fail when elements have genuinely different types: `tomap()` over an object whose values are a mix of strings and numbers will unify to string if it can, and error if it cannot. When a variable is declared with an exact type constraint, that constraint is what the for expression's output must satisfy. ## Readability A three-level nested comprehension inside a resource argument is technically valid and practically unreadable. Lifting the transformation out into a named intermediate value and giving it a name that says what it produces is the difference between code a reviewer can approve and code they cannot.