HashiCorp Terraform Associate (004) Question 101
Single answer4c Use variables and outputsA platform team maintains a reusable Terraform module that creates an application load balancer and returns its DNS name. Several application teams consume this module from a separate root configuration and want to avoid hardcoding environment-specific values. The platform team also wants to prevent accidental disclosure of a database password passed into the root module during CLI runs. Which configuration best meets these requirements?
- A
Define input variables in the root module for environment-specific values, pass them into the child module through module arguments, declare the database password variable as sensitive = true, and expose the load balancer DNS name from the child module with an output that the root module can reference.
- B
Store all environment-specific values directly inside the child module, mark the load balancer DNS name output as sensitive, and rely on terraform.tfstate to share the value with application teams instead of defining outputs in the root module.
- C
Use local values instead of input variables for environment-specific settings, because locals can be overridden per workspace, and mark the database password output as sensitive so Terraform will not store it in state.
- D
Pass the database password to the child module through an output from the root module, because outputs are the preferred way to send values into modules, and define the load balancer DNS name as a variable in the root module so downstream consumers can read it.
Show answer and explanation
Correct answer: A
Explanation
This scenario tests the correct use of Terraform variables and outputs in a modular design. Best practice is to define environment-specific values as input variables in the root module, optionally set them via tfvars files, CLI flags, environment variables, or Terraform Cloud workspace variables, and then pass them into child modules through module arguments. Child modules return useful computed values, such as a load balancer DNS name, through output blocks. Sensitive input variables can be marked with sensitive = true to reduce exposure in Terraform CLI output, but candidates should remember that sensitivity does not encrypt or remove values from state. Terraform documentation on input variables, output values, module composition, and managing sensitive data all support this pattern.
- A. Correct.
Correct. In Terraform, input variables are the standard mechanism for supplying environment-specific values to a root module, and module input arguments are how those values are passed to child modules. Child modules expose values back using output blocks. Marking a variable as sensitive = true helps reduce accidental disclosure in CLI output and plan/apply displays. This matches Terraform's intended flow: variables into modules, outputs out of modules.
- B. Incorrect.
Incorrect. Hardcoding environment-specific values inside a reusable child module reduces reusability and makes the module harder to use across environments. Also, outputs are the supported mechanism for exposing values from modules; consumers should not rely on directly reading state files as a sharing strategy. Marking the load balancer DNS name as sensitive is unnecessary unless the value is actually sensitive.
- C. Incorrect.
Incorrect. Local values are derived expressions within a module and are not designed as externally supplied inputs. They cannot be overridden the way input variables can. Also, marking an output as sensitive does not prevent a secret from being stored in state; sensitive values are still recorded in state unless handled through provider-specific mechanisms outside Terraform.
- D. Incorrect.
Incorrect. Outputs are used to expose values from a module, not to pass values into a child module. To send a database password from the root module to a child module, you use a module argument tied to an input variable in the child module. Likewise, the load balancer DNS name should be produced as an output from the child module, not defined as an input variable in the root module.