An engineer must import 30 existing subnets into a resource declared as aws_subnet.this with for_each, keyed by subnet name. The real subnet IDs are already available in a map variable from name to ID. Which import configuration handles all 30 without writing 30 separate blocks?
Select an answer to reveal the explanation.
Short Explanation
Picture a mail merge: one template, thirty letters. The import block's for_each does exactly that, stamping out an import for each key in your map. Just make sure the keys match the ones your resource uses, or you'll import into addresses that don't line up.
Full Explanation
Since Terraform 1.7, the import block accepts the for_each meta-argument with a map or a list of strings. Iterating over the name-to-ID map and setting to = aws_subnet.this[each.key] with id = each.value produces one import per entry, and because the resource itself uses for_each with the same keys, every imported object lands on the instance that configuration expects. The import block does not support count, so an index-based version is not valid; it would also clash with a resource keyed by name rather than by number. The id argument takes a single provider-specific identifier per import, not a list, and Terraform never pairs a list with instances positionally. Dynamic blocks generate nested blocks inside resources and similar blocks; they cannot create import entries, and the import block has no nested import blocks to generate. Exam caveat: the for_each value must be known at plan time, just as for resources, so build it from variables or locals rather than from attributes that are computed during apply. Operational check: run terraform plan and confirm it reports 30 imports against the expected keyed addresses and no creates.