TF-004 Interact with Terraform modules Practice Question
You are a DevOps engineer at a company that manages infrastructure for multiple environments (dev, staging, prod) using Terraform. The team has created a reusable module for deploying an AWS ECS Fargate service. The module accepts variables for environment name, container image tag, and desired count. The module is stored in a private Git repository. The root configurations for each environment are stored in separate directories, each with its own backend configuration. Recently, a developer added a new feature to the module that requires a new variable 'enable_xray' (boolean, default false). After updating the module source to point to the new commit, the developer runs 'terraform init' and 'terraform plan' in the dev environment. The plan shows that the ECS service will be updated, but the output does not show any changes related to X-Ray. The developer expected that setting 'enable_xray = true' in the dev root module would enable X-Ray tracing. However, the plan shows no changes to the task definition. What is the most likely cause?
⚠ Common exam trap
Test-takers frequently assume declaring a variable and setting its value automatically triggers infrastructure changes, but Terraform only applies changes when the variable is actually consumed by a resource argument.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The module does not reference the 'enable_xray' variable in any resource, so setting it has no effect.
The `enable_xray` variable, even when set to `true` in the root module, will not cause any changes in the plan unless the module's resources actually reference that variable. In Terraform, a variable declared in a module has no effect on infrastructure unless it is used in a resource argument. The developer saw no changes to the task definition because the module's code likely does not include a condition or argument that uses `enable_xray` to enable X-Ray tracing on the ECS task definition.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The module source was not updated correctly; it still points to the old commit.
Why it's wrong here
If the module source were indeed pointing to an old commit where the 'enable_xray' variable had not yet been introduced, Terraform would typically raise an "Unsupported argument" or "Unsupported attribute" error during the 'terraform plan' phase. This error would occur because the root module would attempt to pass a value for a variable that the child module's schema does not recognize. The fact that 'terraform plan' executed successfully and reported "no changes" indicates that the variable was recognized and accepted by the module, implying the module source was correctly updated.
- ✗
The developer forgot to run 'terraform init' after changing the module source.
Why it's wrong here
Forgetting to run 'terraform init' after changing a module source, such as updating a Git commit reference, would prevent Terraform from correctly downloading or updating the module's local copy. This would typically result in an error during 'terraform plan' indicating that the module could not be found or loaded, or that its configuration was invalid. Since 'terraform plan' completed without such errors and merely showed "no changes," it confirms that 'terraform init' was successfully executed, and the module was properly sourced and initialized.
- ✗
The variable 'enable_xray' is not declared in the module's variables.tf file.
Why it's wrong here
Terraform enforces a strict schema for module inputs, meaning all variables passed to a module must be explicitly declared within that module's 'variables.tf' file (or another '.tf' file in its root). If 'enable_xray' were not declared in the module, Terraform would immediately produce an "Unsupported argument" error during the 'terraform plan' command when the parent module attempts to assign a value to it. The absence of such a validation error, coupled with the "no changes" output, confirms that the variable was indeed declared within the module's configuration.
- ✓
The module does not reference the 'enable_xray' variable in any resource, so setting it has no effect.
Why this is correct
For a variable to influence the infrastructure managed by Terraform, it must be actively referenced within the module's resource configurations, data sources, or outputs. In this scenario, while 'enable_xray' was declared and passed a value, no resource block or data source within the module's implementation actually uses 'var.enable_xray' to conditionally create, modify, or configure any infrastructure component. Consequently, changing the variable's value has no effect on the desired state of any managed object, leading 'terraform plan' to correctly report "no changes to infrastructure."
Go deeper
Related to this question
About these practice questions
Courseiva writes every TF-004 question from scratch — 428 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.