HashiCorp Terraform Associate TF-003 TF-003 Questions 526–529 | Page 8/8

526

Multi-Selecthard

Which TWO statements about Terraform module structure and best practices are correct? (Choose two.)

Select 2 answers

A.A module should define variables for any values that need to be customized by the calling configuration.

B.A module should assume the calling configuration will provide all necessary provider configurations.

C.A module must have all Terraform code in a single main.tf file.

D.A module can be sourced from the same repository as the root module using a relative path.

E.A module should rely on direct attribute references to resources in the calling configuration.

AnswersA, D

This is a best practice for reusability.

Why this answer

Option A is correct because Terraform modules are designed to be reusable and configurable. By defining input variables for any customizable values (e.g., resource names, sizes, regions), the module abstracts away hardcoded details and allows the calling configuration to pass in specific values via variable assignments. This follows the principle of encapsulation, where the module's internal logic remains unchanged while its behavior adapts to the caller's needs.

Exam trap

HashiCorp often tests the misconception that modules must be stored in separate repositories or that they cannot reference resources from the calling configuration, but the real trap is that candidates confuse 'direct attribute references' (which are forbidden) with 'outputs' (which are the correct way to expose values), leading them to select option E as correct.

Full explanation →

527

MCQmedium

A team uses Terraform to manage multiple environments (dev, staging, prod) with a shared networking module. The module defines a variable 'cidr_block' with no default. In the root module, they have a file dev.tfvars containing 'cidr_block = "10.0.0.0/16"'. When running 'terraform plan' while in the dev workspace, they receive: 'Error: No value for required variable cidr_block'. They have already run 'terraform init' and confirmed the workspace is 'dev'. What is the most likely cause and correct action?

A.They forgot to include the -var-file flag; add -var-file='dev.tfvars' to the plan command.

B.The variable is defined in the child module; they need to reference it with module.cidr_block in the root module.

C.The workspace is not selected; run 'terraform workspace select dev' again.

D.The variable must be passed through the module block; they should add a module input assignment.

AnswerA

Terraform does not automatically load arbitrary .tfvars files; using -var-file explicitly loads it.

Why this answer

The error indicates the variable file is not being loaded. The most common reason is that the -var-file flag was omitted. Option B fixes this by explicitly specifying the variable file.

Option A is incorrect because the variable is in the module, and root module can pass it via module block, but the variable is already defined in the module. Option C is incorrect because passing via module block is the correct way, but the error suggests the variable file is not being read at all. Option D is incorrect because the workspace is already set correctly.

Full explanation →

528

MCQhard

A platform team manages a large Terraform codebase with hundreds of resources across multiple environments (dev, staging, prod). They use terraform workspaces to manage environment-specific state files. Recently, an engineer made changes to the production workspace but forgot to switch from the dev workspace before applying. The apply was successful, but now the production resources are in an inconsistent state. The team wants to recover the production state to match the actual infrastructure. The previous state file for production was backed up in an S3 bucket before the accidental apply. What is the best course of action?

A.Use terraform state mv to correct the state entries by mapping resources from the backup to the current state

B.Use terraform import to manually import each production resource based on the backup state

C.Use terraform workspace select prod then terraform apply with the backup state file

D.Use terraform state push with the backup state file to overwrite the current state

AnswerD

State push restores the previous state from a local file.

Why this answer

Option D is correct because terraform state push allows a local state file to be pushed to the remote backend, effectively replacing the current state. The team can then run terraform plan to verify. Option A is incorrect because terraform state mv is for renaming resources, not restoring full state.

Option B is incorrect because terraform apply with a state file is not a standard operation. Option C is incorrect because manual import would be time-consuming and error-prone.

Full explanation →

529

MCQeasy

A developer wants to use Terraform in a CI pipeline where the pipeline runs on pull requests. They need to preview infrastructure changes without applying them. Which command should be used?

A.terraform plan

B.terraform validate

C.terraform init

D.terraform apply

AnswerA

Plan shows what will be created/changed/destroyed.

Why this answer

Option A is correct because `terraform plan` creates an execution plan that shows what actions Terraform will take to change infrastructure to match the configuration, without actually applying any changes. This is the standard command for previewing infrastructure changes in a CI pipeline triggered by pull requests, enabling developers to review proposed modifications before merging.

Exam trap

HashiCorp often tests the distinction between validation and planning, so the trap here is that candidates confuse `terraform validate` (syntax check) with `terraform plan` (infrastructure preview), assuming validation alone is sufficient to preview changes.

How to eliminate wrong answers

Option B is wrong because `terraform validate` checks only the syntactic correctness and internal consistency of Terraform configuration files, not the actual state or planned changes against real infrastructure. Option C is wrong because `terraform init` initializes the working directory by downloading providers and modules, but does not generate any preview of infrastructure changes. Option D is wrong because `terraform apply` executes the planned changes and modifies real infrastructure, which is the opposite of a preview-only operation and should not be used in a pull request pipeline without prior approval.

Full explanation →

HashiCorp Terraform Associate TF-003 (TF-003) — Questions 526–529