HashiCorp Terraform Associate (004) Question 103
Single answer4c Use variables and outputsA team maintains a reusable Terraform module that creates an AWS application stack. The module already defines an input variable instance_count and creates an Application Load Balancer. Another team wants to consume this module from a root configuration, set instance_count differently for dev and prod, and expose the ALB DNS name after terraform apply so it can be used by a deployment script. Which approach best meets these requirements while following Terraform best practices for variables and outputs?
- A
Define
instance_countas an input variable in the module, pass environment-specific values from the root module using.tfvarsfiles or-var-file, and add anoutputblock in the module for the ALB DNS name that the root module can expose if needed. - B
Hardcode
instance_countinside the child module for each environment and read the ALB DNS name directly from the Terraform state file in the deployment script instead of defining outputs. - C
Set
instance_countby editing.terraform/terraform.tfstatebefore each run, and useterraform consolein the deployment script to look up the ALB DNS name after apply. - D
Use an environment variable only for the ALB DNS name, but keep
instance_countas a local value inside the child module so consumers cannot override it.
Show answer and explanation
Correct answer: A
Explanation
Terraform distinguishes between input variables, which parameterize configurations and modules, and outputs, which expose values after planning/applying. In this scenario, instance_count should remain an input variable so the root module can provide different values for dev and prod through variable assignment methods such as terraform.tfvars, *.auto.tfvars, CLI -var or -var-file, or environment variables using the TF_VAR_name convention. The ALB DNS name is a computed value from managed resources, so it should be exposed with an output block in the child module and optionally re-exposed by the root module for external consumption. This matches Terraform best practices and the documented module interface model: variables define what goes into a module, and outputs define what comes out of it. Using outputs is also preferable to parsing state directly, since outputs provide a stable, intentional interface for users and automation.
- A. Correct.
Correct. This is the recommended Terraform pattern. Input variables let module consumers provide environment-specific values without modifying module code. In practice, the root module can pass values through variable definitions,
terraform.tfvars,*.auto.tfvars, or-var-file. Outputs are the supported way to expose useful values, such as an ALB DNS name, from a child module to the root module and then to external tooling. This keeps the module reusable and avoids coupling automation to the raw state format. - B. Incorrect.
Incorrect. Hardcoding environment-specific values inside the child module makes the module less reusable and forces code changes for each environment. Reading values directly from the state file is also not a best practice for normal consumption because outputs are the intended interface for exposing values. State structure is an implementation detail and may include sensitive or internal data not meant for external scripts.
- C. Incorrect.
Incorrect. Terraform state should not be manually edited to set variable values. Variable values are supplied through Terraform's input variable mechanisms, not by changing state. Using
terraform consoleas part of a deployment script to extract values is also not the normal interface for automation. Outputs, especially viaterraform output, are the proper way to retrieve post-apply values. - D. Incorrect.
Incorrect. Environment variables can be used to set input variables with the
TF_VAR_prefix, but an ALB DNS name created by resources is not an input that should be provided externally. It should be exposed as an output. Keepinginstance_countas an unchangeable local value in the child module prevents consumers from configuring the module per environment, which conflicts with the scenario's requirement.