A configuration creates three instances with count = length(var.names). The team refactors it to for_each = toset(var.names) so removing one name no longer shifts the others. The plan now wants to destroy and recreate all three. What should the team add?
Select an answer to reveal the explanation.
![To Create an exciting colorful infographic that explains the concepts in the question: Question: A configuration creates three instances with count = length(var.names). The team refactors it to foreach = toset(var.names) so removing one name no longer shifts the others. The plan now wants to destroy and recreate all three. What should the team add? Correct Answer: One moved block per instance, mapping each index such as awsinstance.app[0] to its key such as awsinstance.app["web"] Put EVERY visible label in double quotes. No people. No A/B/C/D letters. In one of the four corners put a little "Navy Duck".](/media/hashicorp/terraform-pro-002/TERRAFORM-PRO-002-e1-q220.webp)
Short Explanation
Terraform knows instance zero and instance "web" are different addresses, and it won't guess they're the same machine. You tell it, one moved block per instance, and the destroy-recreate turns into a quiet rename.
Full Explanation
Instances created with count are addressed by integer index, and instances created with for_each are addressed by key, so switching from count to for_each changes every instance address. Terraform does not guess how indexes correspond to keys, so it plans to destroy the indexed objects and create keyed ones. One moved block per instance, each mapping a specific index to a specific key, re-addresses the existing objects so the plan shows moves with nothing created or destroyed. A moved block naming the same whole-resource address on both sides expresses no change at all and gives Terraform no index-to-key correspondence. Terraform automatically handles only the narrow cases of adding or removing count or for_each on a resource that previously had a single instance; running the plan again does not change its answer for an index-to-key switch. Import blocks bring unmanaged objects under management, but these objects are already managed at the indexed addresses, so importing them again would leave two addresses claiming the same object while the old ones are still planned for destruction. Exam caveat: the mapping must match reality, so confirm which index holds which name before writing the blocks. Operational check: run terraform state list to read the current indexes, write the moved blocks, and confirm the plan reports three moves and zero to destroy.