HashiCorp Terraform Associate (004) Question 87
Single answer4 Terraform configurationA team maintains a Terraform root module that provisions the same application stack in dev, staging, and prod. They want to reduce duplicated configuration by generating security group rules from a variable, but they also want each rule to be tracked as a distinct object in the plan so changes are easy to review. An engineer proposes this configuration:
variable "ingress_rules" { type = list(object({ description = string port = number cidr = string })) }
resource "aws_security_group_rule" "ingress" { dynamic "ingress" { for_each = var.ingress_rules content { description = ingress.value.description from_port = ingress.value.port to_port = ingress.value.port protocol = "tcp" cidr_blocks = [ingress.value.cidr] } } }
During code review, you are asked which change best aligns with Terraform configuration best practices and will produce separately tracked instances for each rule. What should you recommend?
- A
Replace the dynamic block with for_each on the resource itself, using a map keyed by a unique identifier for each rule.
- B
Keep the dynamic block, because dynamic blocks are the preferred way to create multiple resource instances from a list of objects.
- C
Add count = length(var.ingress_rules) to the resource and keep the dynamic block so Terraform can iterate twice and track each rule separately.
- D
Convert the variable to type = set(object(...)) and keep the resource unchanged, because sets make Terraform automatically create one resource instance per object.
Show answer and explanation
Correct answer: A
Explanation
The best recommendation is to use for_each on the resource itself rather than a dynamic block. In Terraform, dynamic blocks are intended for generating nested blocks within a single resource, data source, provider, or provisioner block when the schema supports repeatable nested arguments. They are not a substitute for resource-level repetition. When you need Terraform to manage multiple similar objects as separate instances, use count or, preferably in many real-world cases, for_each.
for_each is especially appropriate here because the team wants each rule to be tracked distinctly and reviewed clearly in plans. With for_each and stable keys, Terraform can preserve object identity more reliably than count, which uses numeric indexes that can shift when list ordering changes. That makes for_each a best practice when instances represent named or uniquely identifiable objects.
A typical improvement would look conceptually like creating a map from the input rules and then using: resource "aws_security_group_rule" "ingress" { for_each = local.ingress_rules_by_name ... }
This aligns with Terraform documentation on meta-arguments like for_each and on dynamic blocks, which clearly distinguishes repeated nested configuration from repeated resource instances.
- A. Correct.
Correct. A dynamic block is used to generate nested blocks inside a resource, not to create multiple instances of the resource itself. For resources like aws_security_group_rule, each separately managed rule should be its own resource instance. Using for_each on the resource creates distinct addresses such as aws_security_group_rule.ingress["ssh"] and aws_security_group_rule.ingress["web"], which makes plans clearer and lifecycle behavior more predictable. In practice, this usually means transforming the input into a map keyed by something stable and unique.
- B. Incorrect.
Incorrect. This is a common misconception. Dynamic blocks only generate repeatable nested configuration blocks that the resource schema supports. They do not create multiple Terraform-managed resource instances. Also, aws_security_group_rule does not use nested ingress blocks in the way aws_security_group does; the proposed configuration is structurally inappropriate for separately tracked rule resources.
- C. Incorrect.
Incorrect. count can create multiple resource instances, but combining count with the shown dynamic block does not solve the core issue. The dynamic block is still the wrong mechanism for creating separate aws_security_group_rule instances, and iterating twice would not map cleanly to one rule per resource. Additionally, count-based indexing is generally less stable than for_each when instances are keyed by meaningful identifiers.
- D. Incorrect.
Incorrect. Changing the collection type to a set does not cause Terraform to create one resource instance per object unless the resource itself uses count or for_each. A set can affect uniqueness and ordering semantics of values, but it does not change how many resource instances Terraform manages. The resource block still defines only one resource unless count or for_each is applied at the resource level.