Question 326 of 519

Read, generate and modify configuration →easyMultiple ChoiceObjective-mapped

Quick Answer

The answer is that the engineer mistakenly defined instance_count as a local value instead of passing it as an argument inside the module block. In Terraform, module input variables are overridden by assigning values directly within the module block’s curly braces, not by declaring a separate local or variable in the root module. This is a classic module variable override mistake that trips up many candidates on the HashiCorp Terraform Associate TF-003 exam, as it tests your understanding of how Terraform resolves variable precedence between root and child modules. The exam often presents a scenario where a default value stubbornly persists despite a seemingly correct override, and the trap is that the engineer wrote `instance_count = 3` as a local value or as a standalone variable block rather than nesting it inside the module’s argument list. A reliable memory tip: if you want to override a module input, always place the assignment inside the module block—think “module block, not root block.”

TF-003 Read, generate and modify configuration Practice Question

This TF-003 practice question tests your understanding of read, generate and modify configuration. Examine the command output carefully: the correct answer depends on what the output actually shows, not on general recall alone. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.

A DevOps engineer is managing a multi-cloud infrastructure using Terraform. The team relies on a module sourced from the Terraform Registry to deploy a standard web application. This module defines an input variable called 'instance_count' with a default value of 2. For the production environment, the engineer wants to deploy 3 instances. They create a root module configuration that references the module. In the root module's main.tf, they write a block that sets instance_count = 3. However, when they run terraform plan, the output indicates that the module will still use instance_count = 2. The engineer double-checks the configuration: the root module's main.tf is syntactically correct, the module source points to the correct registry module and version, and they have run terraform init and terraform validate without errors. What is the most likely reason the variable override is not taking effect?

Clue words in this question

Noticing these words before you look at the options changes how you read each choice.

Clue: "most likely"
Why it matters: Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.

Question 1easymultiple choice

Full question →

A
The module version specified does not support variable overrides; the engineer must use a different module.
Why wrong: Module versions do not disable variable overrides; all input variables in a module can be overridden by the calling module.
B
The variable 'instance_count' is not declared as an input variable in the child module's variables.tf.
Why wrong: The module does declare the variable since it has a default value; otherwise, there would be an error on plan.
C
The engineer forgot to run terraform init after modifying the root module's configuration.
Why wrong: Terraform init is required to download modules, but not to apply variable overrides. The engineer already ran init and validate successfully.
D
The root module defines instance_count as a local value rather than passing it as an argument to the module block.
To override a module variable, it must be passed as an argument within the module block (e.g., module "web" { instance_count = 3 }). A local value does not affect the module.

Full breakdown with real-world context →

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 root module defines instance_count as a local value rather than passing it as an argument to the module block.

Option B is correct because the most common mistake is defining the variable as a local value rather than passing it as an argument to the module block. Option A is incorrect because the variable exists in the module (it has a default). Option C is incorrect because terraform init is not required for variable changes; terraform validate passed, so syntax is fine. Option D is incorrect because module version does not affect variable overrides.

Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

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 version specified does not support variable overrides; the engineer must use a different module.
Why it's wrong here
Module versions do not disable variable overrides; all input variables in a module can be overridden by the calling module.
✗
The variable 'instance_count' is not declared as an input variable in the child module's variables.tf.
Why it's wrong here
The module does declare the variable since it has a default value; otherwise, there would be an error on plan.
✗
The engineer forgot to run terraform init after modifying the root module's configuration.
Why it's wrong here
Terraform init is required to download modules, but not to apply variable overrides. The engineer already ran init and validate successfully.
✓
The root module defines instance_count as a local value rather than passing it as an argument to the module block.
Why this is correct
To override a module variable, it must be passed as an argument within the module block (e.g., module "web" { instance_count = 3 }). A local value does not affect the module.
Clue confirmation
The clue word "most likely" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.

Common exam traps

Common exam trap: answer the scenario, not the keyword

Many certification questions include familiar terms but test a specific constraint. Read the exact wording before choosing an answer that is generally true but wrong for this case.

Detailed technical explanation

How to think about this question

This question should be treated as a scenario, not a definition check. Identify the problem, the constraint and the best action. Then compare each option against those facts.

KKey Concepts to Remember

Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
Use explanations to understand the rule behind the answer.

TExam Day Tips

Underline the problem statement mentally.
Watch for words such as best, first, most likely and least administrative effort.
Review why wrong options are wrong, not only why the correct option is correct.

Key takeaway

Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

Real-world example

How this comes up in practice

A practitioner preparing for the TF-003 exam encounters this exact type of scenario on the job. The correct answer here is not the most general option — it is the best answer for the specific constraint described. Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option. Real exam questions reward reading the full scenario before eliminating options, because the constraint defines which answer fits.

What to study next

Got this wrong? Here's your next step.

Identify which TF-003 exam domain this question belongs to, then review the specific concept being tested. Practise related questions in that domain and focus on understanding why each wrong answer is tempting — not just why the correct answer is right.

Related TF-003 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

Understand IaC concepts practice questions

Practise TF-003 questions linked to Understand IaC concepts.

Understand Terraform basics practice questions

Practise TF-003 questions linked to Understand Terraform basics.

Understand Terraform's purpose practice questions

Practise TF-003 questions linked to Understand Terraform's purpose.

Use Terraform outside the core workflow practice questions

Practise TF-003 questions linked to Use Terraform outside the core workflow.

Interact with Terraform modules practice questions

Practise TF-003 questions linked to Interact with Terraform modules.

Use the core Terraform workflow practice questions

Practise TF-003 questions linked to Use the core Terraform workflow.

Implement and maintain state practice questions

Practise TF-003 questions linked to Implement and maintain state.

Read, generate and modify configuration practice questions

Practise TF-003 questions linked to Read, generate and modify configuration.

TF-003 fundamentals practice questions

Practise TF-003 questions linked to TF-003 fundamentals.

TF-003 scenario practice questions

Practise TF-003 questions linked to TF-003 scenario.

TF-003 troubleshooting practice questions

Practise TF-003 questions linked to TF-003 troubleshooting.

Practice this exam

Start a free TF-003 practice session

Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.

10 questions 20 questions 30 questions 50 questions Timed 30

TF-003 practice-test guide →Study guide →Browse all practice tests

FAQ

Questions learners often ask

What does this TF-003 question test?

Read, generate and modify configuration — This question tests Read, generate and modify configuration — Read the scenario before looking for a memorised answer..

What is the correct answer to this question?

The correct answer is: The root module defines instance_count as a local value rather than passing it as an argument to the module block. — Option B is correct because the most common mistake is defining the variable as a local value rather than passing it as an argument to the module block. Option A is incorrect because the variable exists in the module (it has a default). Option C is incorrect because terraform init is not required for variable changes; terraform validate passed, so syntax is fine. Option D is incorrect because module version does not affect variable overrides.

What should I do if I get this TF-003 question wrong?

Are there clue words in this question I should notice?

Yes — watch for: "most likely". Probability qualifier — the question wants the most probable cause or outcome, not a guaranteed one. Eliminate low-probability options.

What is the key concept behind this question?

Read the scenario before looking for a memorised answer.

About these practice questions

Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Last reviewed: Jun 24, 2026

Question Discussion

Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.

Loading comments…

This TF-003 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-003 exam.