The business wants the same web tier in three availability zones with different instance counts per zone, and expects to add or remove zones later without disturbing the zones that remain. Which input design should the module use?
Select an answer to reveal the explanation.
Short Explanation
Picture a seating chart with names on the chairs instead of numbers: if someone leaves, nobody else has to move. A map keyed by zone does exactly that for your instances. The trap is the parallel-list idea, which looks tidy until you delete a zone and everything after it shifts.
Full Explanation
The requirement has two parts: per-zone differences, and the ability to add or remove a zone without touching the others. A variable typed map(object({...})) keyed by zone name captures each zone's settings as data, and a single resource or module block with for_each over that map creates one instance per key. Because for_each identifies instances by key, such as module.web["zone-a"], adding or removing a key only plans changes for that key. Copying the block three times does work today, but every new zone means editing code rather than data, and the copies drift apart over time, which fails the scaling requirement. Parallel lists consumed with count identify instances by position, so removing a zone from the middle of the list shifts every later index and Terraform plans changes or replacements for zones that did not change. One workspace per zone is a misuse of workspaces, and terraform.tfvars is a single file shared by every workspace in the same working directory, so it cannot hold per-workspace values at all. Exam caveat: for_each keys must be known at plan time, so keep zone names as static input rather than deriving them from a computed attribute. Operational check: delete one key from the map and confirm the plan touches only the instances under that key.