HashiCorp Terraform Associate (004) Question 105
Single answer4c Use variables and outputsA team maintains a reusable Terraform module that creates a VPC and several subnets. Multiple application teams consume this module from separate root configurations. The networking team wants consumers to be able to override the CIDR block when needed, but use a safe default otherwise. They also want each consuming root module to easily access the VPC ID after apply so it can be passed to other modules. Which configuration best meets these requirements using Terraform variables and outputs?
- A
Define a variable in the child module for the CIDR block with a default value, use that variable in the VPC resource, and define an output in the child module that exposes the VPC ID. In the root module, optionally set the variable when calling the module and reference module.network.vpc_id where needed.
- B
Hardcode the CIDR block inside the child module and define a local value in the root module for the VPC ID so other modules can read it after apply.
- C
Define the CIDR block as an output in the child module and pass the VPC ID into the root module as an input variable after the VPC is created.
- D
Create a terraform.tfvars file inside the child module to store the CIDR block default and use an output in the root module to automatically expose all child module resource attributes.
Show answer and explanation
Correct answer: A
Explanation
Terraform separates configurable inputs and exported values through variables and outputs. In reusable module design, define input variables in the child module for values callers may customize, optionally with default values for sensible behavior when no override is provided. Define outputs in the child module for values the caller needs after resource creation, such as IDs, ARNs, or IPs. The calling root module passes input values in the module block and reads exported values using the syntax module.<module_name>.<output_name>. Best practice is to expose only the values consumers need rather than raw internal implementation details. This matches Terraform documentation for input variables, output values, and module composition.
- A. Correct.
Correct. This is the intended Terraform pattern for reusable modules. Input variables let module authors define configurable inputs, including optional defaults. Outputs let child modules expose selected values, such as a VPC ID, to the calling root module. A consumer can override the default by passing an argument in the module block, and can then reference the exported value as module.
. - B. Incorrect.
Incorrect. Hardcoding the CIDR block removes the flexibility required by the scenario. Also, a root-module local value cannot directly serve as a mechanism to expose a child module's resource ID unless that value is derived from a proper module output. Locals are only internal expressions within a module and are not a substitute for child module outputs.
- C. Incorrect.
Incorrect. Outputs are for values produced by a module and consumed by its caller, not for accepting configuration into the module. Likewise, the VPC ID is created by the child module, so it should be exposed as an output rather than passed back into the root module as an input variable after creation. This reverses Terraform's intended data flow.
- D. Incorrect.
Incorrect. terraform.tfvars files are primarily used by the root module when supplying values to input variables during CLI-driven runs. A child module should define defaults in variable blocks, not rely on a tfvars file packaged inside the module for default behavior. Also, root outputs do not automatically expose all child module resource attributes; only explicitly defined child outputs are accessible.