HashiCorp Terraform Associate (004) Question 89
Single answer4 Terraform configurationA platform team maintains a Terraform configuration that creates the same monitoring resources in several AWS regions. They currently duplicate nearly identical resource blocks, which makes the configuration difficult to maintain. A team member proposes the following refactor:
- Define a local value containing a map of region names to configuration settings.
- Use
for_eachso Terraform creates one resource instance per map element. - Refer to each instance by key when wiring dependent resources together.
The team wants a solution that reduces duplication while keeping resource instance addresses stable when one region is added or removed later. Which approach best meets this requirement?
- A
Use
countwith a list of regions, and reference resources by numeric index such asaws_cloudwatch_log_group.monitor[0]. - B
Use
for_eachwith a map in a local value, and reference resources by key such asaws_cloudwatch_log_group.monitor["us-east-1"]. - C
Create separate
.tffiles for each region, because Terraform tracks resources by file name and this keeps addresses stable. - D
Use input variables for each individual region and duplicate the resource blocks, because explicit blocks are the only way to preserve state addresses.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use for_each with a map stored in a local value. In Terraform configuration, locals are commonly used to centralize derived values or repeated configuration data, and for_each is appropriate when each resource instance should be identified by a stable key. This makes the configuration easier to maintain and helps avoid the index-shifting behavior associated with count.
Terraform resource instance addressing differs between count and for_each:
countinstances are addressed by numeric index.for_eachinstances are addressed by key.
When the collection represents distinct named objects, HashiCorp documentation and common best practice favor for_each because keys remain meaningful and stable across changes. Also, Terraform loads all .tf files in a module together, so file boundaries are organizational only and do not affect state addressing.
- A. Incorrect.
Incorrect.
countcan reduce duplication, but its instances are indexed numerically. If the underlying list changes order or an element is removed from the middle, Terraform may shift indexes and propose unintended changes or replacements. This is a common misconception:countis useful for similar resources, butfor_eachis usually preferred when instances have meaningful unique identifiers. - B. Correct.
Correct.
for_eachwith a map or set lets Terraform track instances by key instead of by position. Using a local value to define the map improves maintainability, and referencing instances by keys such asresource.name["key"]keeps addresses more stable when adding or removing other elements. This is the recommended pattern when managing multiple distinct instances of similar resources in Terraform configuration. - C. Incorrect.
Incorrect. Terraform does not track resources by the file name where they are declared. All
.tffiles in a module are merged into a single configuration. Splitting resources into multiple files may help organization, but it does not provide stable instance addressing or solve duplication by itself. - D. Incorrect.
Incorrect. Duplicating resource blocks with separate variables increases maintenance overhead and does not scale well. While explicit blocks can preserve addresses for those exact resources, they do not meet the stated goal of reducing duplication. Terraform supports iteration constructs specifically to handle this more cleanly.