Terraform Module for_each with Map — Dynamic Module Instances
Exhibit
Refer to the exhibit.
```
module "networks" {
source = "./modules/network"
for_each = {
dev = "10.0.1.0/24"
prod = "10.0.2.0/24"
}
cidr_block = each.value
name = each.key
}
resource "aws_flow_log" "example" {
for_each = module.networks
vpc_id = each.value.vpc_id
...
}
```In the configuration, what is the likely result of the resource block 'aws_flow_log'?
Quick Answer
The correct answer is that it will create one flow log per network module instance, using the vpc_id output from each. This is because the resource block uses a Terraform module for_each with a map, specifically iterating over module.networks, which is a map of module instances each exposing their own vpc_id output. The for_each meta-argument dynamically creates one instance of the aws_flow_log resource for each key in that map, and each instance accesses its corresponding module’s vpc_id via each.value.vpc_id. On the HashiCorp Terraform Associate TF-003 exam, this tests your understanding of how for_each works with module outputs versus simple lists—a common trap is assuming the module returns a list of VPC IDs, but a map of module instances preserves individual outputs per key. Remember the memory tip: “Map of modules means map of outputs—each key gets its own resource.”
⚠ Common exam trap
The TF-003 exam often tests the distinction between `for_each` and `count` in module contexts, trapping candidates who assume `for_each` cannot consume module outputs or that `count` is the only way to iterate over module instances.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
It will create one flow log per network module instance, using the vpc_id output from each.
`for_each` in Terraform iterates over each element in a map or set, creating one resource instance per element. When `for_each` is used with `module.networks`, it iterates over each module instance, and `each.value.vpc_id` references the `vpc_id` output from that specific module instance. This results in one `aws_flow_log` resource per network module instance, each associated with its respective VPC.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Terraform will error because for_each cannot be used with module outputs.
Why it's wrong here
for_each can iterate over a map of module outputs; it is a valid usage.
- ✗
The resource will be created only for the last module instance due to overwriting.
Why it's wrong here
for_each creates a resource for each distinct key; no overwriting occurs.
- ✓
It will create one flow log per network module instance, using the vpc_id output from each.
Why this is correct
for_each = module.networks iterates over each module instance, allowing access to its outputs via each.value.
- ✗
It will create one flow log for each VPC using a count based on length of module.networks.
Why it's wrong here
count cannot be used directly on a map of modules; for_each is appropriate, and the syntax uses each.value.
Go deeper
Related to this question
About these practice questions
Courseiva writes every TF-004 question from scratch — 428 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on TF-004
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A team has a root module that calls a local module using count to conditionally create an AWS RDS instance based on a boolean variable `rds_enabled`. The root module sets `rds_enabled` to the value of a data source that checks if a tag exists on an S3 bucket. The relevant code is: `count = var.rds_enabled ? 1 : 0`. When they run terraform plan, they receive the error: "Error: Invalid count argument: The count value is not yet known". The S3 bucket already exists. What is the underlying issue?
medium- A.Data sources cannot be used in a count condition.
- B.The count in a module block cannot depend on a data source.
- ✓ C.The count value must be known when Terraform evaluates it during planning, but the data source result is not guaranteed to be known at that point.
- D.The module does not support count.
Why C: Terraform requires `count` to be a known value before it can finalize the resource graph during the plan. `terraform plan` does perform a refresh and can read data sources, but a data source result is not guaranteed to be known at the moment Terraform evaluates `count`—for example, if the data source depends on values that are not yet known. This can happen even when the underlying object, such as the S3 bucket, already exists. Options A, B, and D are incorrect: data sources can be used in count conditions, module blocks support `count`, and the module itself is not the problem.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.