HashiCorp Terraform Associate (004) Question 106
Single answer4d Understand and use complex typesA platform team wants a reusable Terraform module to create network security rules for multiple applications. Each application can have a different list of ingress ports, and every application also needs a single owner and an environment value. To make input validation strict and self-documenting, the team wants one variable that can represent all application settings in a single value.
Which variable type constraint is the most appropriate for this requirement?
- A
type = map(object({ owner = string, environment = string, ingress_ports = list(number) }))
- B
type = object({ owner = string, environment = string, ingress_ports = list(number) })
- C
type = list(object({ owner = string, environment = string, ingress_ports = number }))
- D
type = map(string)
Show answer and explanation
Correct answer: A
Explanation
Terraform complex types are designed for exactly this kind of module input. Use object(...) when you need a fixed schema with named attributes, and combine it with collection types like map(...) or list(...) when you need multiple instances of that schema. In this scenario, map(object(...)) is the best choice because it provides a keyed collection of application definitions with strict typing for owner, environment, and ingress_ports. This improves validation, readability, and module usability.
This aligns with Terraform language documentation on type constraints, especially collection types and structural types. A common best practice is to prefer explicit object-based schemas over loosely typed maps when module inputs need to be validated and understood by other teams.
- A. Correct.
Correct. A map of objects is the best fit when each application is identified by a key such as app name, and each value must contain structured attributes. This lets callers pass values like { api = { owner = "team-a", environment = "prod", ingress_ports = [80, 443] }, worker = { ... } }. The object enforces the required fields and types, while the map allows multiple applications to be represented in a single variable.
- B. Incorrect.
Incorrect. This defines a single object, not multiple applications. It would work only if the module accepted settings for exactly one application. The scenario requires one variable that can hold settings for many applications, each potentially with a different list of ports.
- C. Incorrect.
Incorrect. A list of objects could represent multiple applications, but it is less appropriate here because the scenario implies managing settings per application in a keyed structure. Also, this option incorrectly defines ingress_ports as a single number instead of a list of numbers, so it does not match the requirement that each application can have multiple ingress ports.
- D. Incorrect.
Incorrect. A map of strings is too simple for this scenario. It cannot model nested structured data such as an owner, environment, and a list of ports for each application. Choosing this often reflects the misconception that maps are sufficient for any grouped input, even when complex nested attributes are required.