HashiCorp Terraform Associate (004) Question 104
Single answer4c Use variables and outputsA team maintains a reusable Terraform module that creates a virtual network and several subnets. They want the root module to supply a map of subnet definitions, and they want other parts of the configuration to consume the created subnet IDs after apply. The current implementation uses hard-coded subnet values inside the module, which makes it difficult to reuse across environments. Which approach best improves this design while following Terraform best practices for variables and outputs?
- A
Define an input variable in the module for the subnet definitions, pass environment-specific values from the root module, and expose the created subnet IDs with an output value.
- B
Place the subnet definitions directly in a local value inside the child module and use terraform console to read the subnet IDs after apply instead of defining outputs.
- C
Define the subnet map as an output in the root module so child modules can read it automatically, and hard-code the resulting subnet IDs in dependent resources.
- D
Store the subnet definitions in a tfstate file and reference them directly from the module so the module can avoid variables and outputs.
Show answer and explanation
Correct answer: A
Explanation
Terraform modules should define clear interfaces: input variables for values passed into the module and output values for data exposed from the module. In this scenario, the subnet definitions vary by environment, so they should be passed from the root module into the child module using a variable, often with a structured type such as map(object(...)) for validation and clarity. After the subnets are created, the module should return their IDs through outputs so the root module or dependent resources can reference them. This follows Terraform documentation and best practices for module composition, reusability, and dependency handling. Local values are internal-only helpers, not external interfaces. Outputs are the proper mechanism for exporting resource attributes, and child modules cannot automatically read root outputs.
- A. Correct.
Correct. This is the recommended Terraform pattern. Input variables make a module reusable by allowing callers to provide environment-specific values, such as a map of subnet definitions. Output values are the supported way to expose data from a child module, such as created subnet IDs, to the root module or other consuming configurations. This matches Terraform's intended module interface design: variables for input, outputs for exported results.
- B. Incorrect.
Incorrect. Local values are useful for internal transformation or reducing repetition, but they are not a substitute for module inputs when the values need to vary by environment. Using terraform console is also not a mechanism for passing values between resources or modules; it is only an interactive inspection tool. Without outputs, other parts of the configuration cannot reliably consume the subnet IDs.
- C. Incorrect.
Incorrect. Outputs do not flow downward into child modules. Child modules receive values only through input arguments that map to declared variables. Also, hard-coding generated subnet IDs in dependent resources defeats the purpose of Terraform dependency management and breaks portability across environments.
- D. Incorrect.
Incorrect. Terraform state is not intended to be used as a general input source for module configuration. Directly relying on tfstate contents instead of variables and outputs is not a best practice and creates tight coupling and fragility. When sharing data across configurations, Terraform supports explicit mechanisms such as outputs and, in some cases, remote state data sources, but not using state files as a replacement for module interfaces.