In Terraform, what is the practical difference between the count and for_each meta-arguments, and why can removing one element from the middle of a list used with count destroy resources you never meant to touch?

## Two meta-arguments for the same job A Terraform `resource` block normally declares one real object. `count` and `for_each` are *meta-arguments* — arguments Terraform interprets itself rather than passing to the provider — that expand a single block into multiple **instances**. A block may use one or the other, never both; combining them is a configuration error. ```hcl resource "aws_iam_user" "team" { count = 3 name = "user-${count.index}" } ``` `count` takes a whole number. Inside the block, `count.index` is the zero-based position of the instance being built. ```hcl resource "aws_iam_user" "team" { for_each = toset(["ana", "ben", "cara"]) name = each.value } ``` `for_each` takes a **map** or a **set of strings** — a list is rejected, which is why `toset(...)` appears so often. Inside the block, `each.key` is the map key (or, for a set, the element itself) and `each.value` is the map value (again the element itself for a set). ## Addressing is the whole story The difference that matters is not syntax, it is the **resource address** Terraform records in state for each instance: - `count` → `aws_iam_user.team[0]`, `aws_iam_user.team[1]`, `aws_iam_user.team[2]` - `for_each` → `aws_iam_user.team["ana"]`, `aws_iam_user.team["ben"]`, `aws_iam_user.team["cara"]` State is a mapping from address to a real remote object. On every plan Terraform compares the set of addresses your configuration *would* produce against the set of addresses already in state. Addresses that appear only in configuration are creations; addresses only in state are destroys; addresses in both are compared attribute by attribute. Nothing in that algorithm knows that index `1` "means" Ben. The index is derived from position in the input list, and position is not identity. ## The re-indexing accident Start with `var.names = ["ana", "ben", "cara"]` and `count = length(var.names)`, `name = var.names[count.index]`. State holds three addresses. Now someone removes `"ben"` in a pull request that looks like a one-line deletion. The list becomes `["ana", "cara"]`, so: - `[0]` still wants `name = "ana"` → no change. - `[1]` previously held Ben, now wants `name = "cara"`. Terraform does not rename it; `name` on `aws_iam_user` forces a new resource, so this is **destroy and recreate**. - `[2]` exists in state but is no longer produced by the configuration → **destroy**. The reviewer expected one destroy. The plan does two destroys and one create, and the object that survives untouched is not the one anyone predicted. Substitute EC2 instances, disks, or DNS records for IAM users and this is an outage. The same happens on an **insertion** anywhere but the end, and on a **reorder** — sorting the list alphabetically can churn the entire set. With `for_each = toset(var.names)`, removing `"ben"` removes exactly the address `["ben"]`. `["ana"]` and `["cara"]` are still produced by the configuration, still match state, and generate no diff at all. ## What each one requires Both values must be **known at plan time** — Terraform has to compute how many instances exist before it can render a diff. For `for_each` the requirement is specifically on the *keys*; the values in the map may be unknown until apply. `for_each` also demands that keys be strings, and that they be unique — that is precisely what buys stability. When your source data is a list of objects, project it into a map with a `for` expression keyed by a stable field: ```hcl for_each = { for u in var.users : u.name => u } ``` Pick the key from something that will not change when unrelated data changes. Keying by an ordinal (`index`) recreates the count problem with extra steps. ## When count is still the right answer `count` is not deprecated and has two honest uses: 1. **Conditional creation** — `count = var.enabled ? 1 : 0`, the standard idiom for "this resource exists only sometimes". 2. **Genuinely interchangeable copies** — N identical workers where nothing distinguishes instance 3 from instance 4 and the number only ever changes at the end. Even here, scaling down still removes the highest indices, which may not be the ones you want gone. Everything else — one resource per environment, per subnet, per team, per region — has identity, and identity wants `for_each`. ## Fixing an existing repository Switching a live `count` resource to `for_each` naively produces a plan that destroys every instance and creates them again under new addresses, because every address changed. Terraform's `moved` block (available since Terraform 1.1) lets you declare the old address and the new one so the plan becomes a no-op state rename instead of a rebuild. That migration is worth doing before the list is edited under pressure, not after. ## The interview summary `count` indexes by position, `for_each` keys by identity; positions shift and identities do not. Reach for `for_each` by default, keep `count` for on/off and for anonymous replicas, and read any plan touching a counted resource for destroys you did not ask for.