HashiCorpAssociate levelPage 2 of 3

HashiCorp Terraform Associate (004) exam dumps: questions 101 to 200 of 223

Page 2 of the free HashiCorp Terraform Associate (004) question bank for the Terraform Associate 004 exam. Questions 101 to 200 are listed below, the first 5 in full with answers and explanations. Back to page 1 for the exam overview and FAQ.

Question bank last updated June 2026

Start timed practice exam Questions 101 to 200

Free HashiCorp Terraform Associate (004) practice questions

Questions 101 to 105 of 223

Pick an answer before you open the explanation. Each question also has its own page with a permalink.

HashiCorp Terraform Associate (004) Question 101

Single answer4c Use variables and outputs

A 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.

HashiCorp Terraform Associate (004) Question 102

Single answer4c Use variables and outputs

Your team maintains a reusable Terraform module that provisions an application load balancer and returns its DNS name. Another team calls this module from a root module and wants to control the environment-specific naming convention while also displaying the final DNS name after apply. They want a solution that keeps the module reusable across dev, staging, and prod without hardcoding values inside the module. Which approach best meets these requirements?

A
Define an input variable in the child module for the environment name, use that variable in resource naming, and define an output in the child module for the load balancer DNS name. In the root module, pass the environment value into the module block and reference the child module output.
B
Reference a root module local value directly from inside the child module for the environment name, and print the load balancer DNS name using terraform console after apply instead of defining an output.
C
Create the environment name as an output in the root module so the child module can read it automatically, and define the load balancer DNS name only as a local value inside the child module.
D
Hardcode the environment name inside the child module for consistency, and expose the load balancer DNS name by reading the state file manually from the root module.

Show answer and explanation

Correct answer: A

Explanation

Terraform modules are designed to have clear interfaces: input variables accept values into a module, and outputs return selected values to the caller. In this scenario, the child module should declare a variable such as environment and use it in naming logic, while also declaring an output for the load balancer DNS name. The root module passes the environment-specific value in the module block and can reference the result with module.<module_name>.<output_name>. This is consistent with Terraform documentation and best practices for reusable modules. A key exam concept is understanding that variables flow into modules, outputs flow out of modules, and values are not shared implicitly across module boundaries.

A. Correct.
Correct. This is the standard Terraform pattern for reusable modules: pass configurable values into a child module using input variables and expose values from the child module using outputs. The root module can set different values for different environments in the module block, and then reference the returned value as module... This keeps the module portable and avoids coupling it to a specific environment.
B. Incorrect.
Incorrect. Child modules cannot directly access local values, variables, or resources from the root module unless those values are explicitly passed in as input arguments. Also, using terraform console is not a substitute for a module output when a value should be intentionally exposed for downstream use or visibility after apply.
C. Incorrect.
Incorrect. Outputs do not flow automatically from the root module into child modules. Outputs expose values outward from a module to its caller; they are not an input mechanism. Likewise, if the DNS name needs to be exposed to the calling module, defining it only as a local value in the child module will not make it available outside that module.
D. Incorrect.
Incorrect. Hardcoding the environment name inside the child module reduces reusability and violates the requirement to support multiple environments without changing module code. Reading the state file manually is not the intended mechanism for consuming module values; outputs are the supported and safer interface for exposing data from a module.

HashiCorp Terraform Associate (004) Question 103

Single answer4c Use variables and outputs

A 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_count as an input variable in the module, pass environment-specific values from the root module using .tfvars files or -var-file, and add an output block in the module for the ALB DNS name that the root module can expose if needed.
B
Hardcode instance_count inside 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_count by editing .terraform/terraform.tfstate before each run, and use terraform console in 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_count as 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 console as part of a deployment script to extract values is also not the normal interface for automation. Outputs, especially via terraform 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. Keeping instance_count as an unchangeable local value in the child module prevents consumers from configuring the module per environment, which conflicts with the scenario's requirement.

HashiCorp Terraform Associate (004) Question 104

Single answer4c Use variables and outputs

A 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.

HashiCorp Terraform Associate (004) Question 105

Single answer4c Use variables and outputs

A 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.

Timed practice exam

Take a HashiCorp Terraform Associate (004) practice test under exam conditions

70 questions in 60 minutes, drawn from this bank, with a score report and a per-question review when you finish.

Start timed exam

HashiCorp Terraform Associate (004) practice questions 101 to 200 of 223

Every question has a page with the answer and explanation. Numbers are stable, so you can bookmark or share them. The bank is split into 3 pages of up to 100 questions.

More HashiCorp exam dumps

All HashiCorp exams

243 questions

HashiCorp Vault Associate (003) exam dumps

Vault Associate (003)