HashiCorp Terraform Associate (004) Question 107
Single answer4d Understand and use complex typesA platform team wants a reusable Terraform module to configure multiple application environments. Each environment must include a region, an instance count, and a set of tags. Some environments also include an optional maintenance window string. The team wants Terraform to validate the structure before planning so that malformed input is rejected early.
Which variable definition best enforces this requirement while still allowing the maintenance window to be omitted for some environments?
- A
variable "environments" { type = map(object({ region = string instance_count = number tags = map(string) maintenance_window = optional(string) })) }
- B
variable "environments" { type = list(map(string)) }
- C
variable "environments" { type = map(any) }
- D
variable "environments" { type = object({ region = string instance_count = number tags = list(string) maintenance_window = string }) }
Show answer and explanation
Correct answer: A
Explanation
Terraform's type system supports complex types such as list, map, set, object, and tuple. When building reusable modules, defining exact variable types is a best practice because it improves validation, readability, and error messages. In this scenario, the input is a collection of named environments, so map(object(...)) is the correct shape: the map keys represent environment names, and each value must conform to the declared object schema. The optional(...) type modifier allows an object attribute to be omitted while still validating the rest of the structure.
This approach aligns with Terraform language guidance to use explicit type constraints instead of permissive types like any unless there is a specific reason to accept arbitrary data. It also avoids common modeling errors such as using a list when a keyed map is needed, or using an object for a single structure when the requirement is a collection of repeated structures.
- A. Correct.
Correct. A map of objects is appropriate because the input represents multiple named environments, each with the same expected schema. The object type enforces that each environment includes region as a string, instance_count as a number, and tags as a map of strings. Using optional(string) allows maintenance_window to be omitted for some entries while preserving type validation. This is the most precise and practical use of Terraform complex types for this scenario.
- B. Incorrect.
Incorrect. list(map(string)) is too loose and also mismatches the required data types. It would force all attribute values in each map to be strings, so instance_count could not be validated as a number and tags could not be validated as a nested map(string). It also does not model named environments well, since a list is indexed numerically rather than by environment name.
- C. Incorrect.
Incorrect. map(any) would accept a wide range of values and does not enforce the required structure. While it may appear flexible, it defeats the goal of early validation because malformed entries could pass type checking and fail later in expressions or resource arguments. Using precise complex types is a best practice when the structure is known.
- D. Incorrect.
Incorrect. object({...}) describes a single object with fixed top-level attributes, not multiple environments keyed by name. It also defines tags as list(string), which does not match the requirement for a set of key/value tags, and makes maintenance_window mandatory rather than optional. This option reflects several common mistakes when modeling structured input.