TF-004 Understand Terraform basics Practice Question
A Terraform configuration uses `count` to create multiple EC2 instances. After adding a new variable for instance type, the user runs `terraform plan` and sees that all instances are marked for recreation. What is the most likely cause?
⚠ Common exam trap
A common mix-up: candidates confuse `count` re-indexing (which happens when the count value itself changes) with the effect of changing a variable that is used inside the resource block, leading them to incorrectly select Option A.
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 variable change triggers a new value for each resource, causing Terraform to see differences
When you change a variable that is referenced within a resource's configuration (such as `instance_type`), Terraform sees a diff between the current state and the new configuration for every resource created by `count`. Since `count` resources are identified by their index in the state, and the new variable value changes the desired configuration for each instance, Terraform plans to recreate all of them to apply the new instance type.
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 `count` index changed, causing all resources to be re-indexed
Why it's wrong here
Terraform assigns stable addresses to resources created with `count` (e.g., `resource.name[0]`). While changing the `count` value itself can lead to additions or removals, merely 're-indexing' existing resources due to an internal change in a list or map (without an explicit change to the resource's configuration or address) does not inherently force recreation. The primary driver for planned changes is when the computed attributes of an *existing* resource instance differ from its state, not a generic re-indexing.
- ✗
The user forgot to run `terraform refresh` after changing the variable
Why it's wrong here
The `terraform refresh` command is specifically designed to reconcile the Terraform state file with the actual infrastructure's current attributes in the cloud provider. It updates the state to reflect any out-of-band changes made manually. However, `refresh` does not evaluate or interpret changes made to the Terraform configuration files, such as altering a variable's value. Therefore, it would not cause Terraform to 'see differences' in the configuration itself; `terraform plan` or `apply` are necessary for that.
- ✗
The state file is corrupt and needs to be refreshed
Why it's wrong here
A corrupt Terraform state file would typically manifest as explicit errors during any Terraform operation, preventing successful execution of commands like `plan` or `apply`. These errors might indicate unparseable data or inconsistencies that halt processing. It would not silently lead to a plan showing resource changes based on a variable update; instead, it would produce a critical error requiring manual state recovery or repair.
- ✓
The variable change triggers a new value for each resource, causing Terraform to see differences
Why this is correct
When an input variable's value changes, and that variable is referenced within the configuration of resources created using `count`, Terraform re-evaluates the entire configuration. For each resource instance managed by `count`, the new variable value is used to compute its attributes. If these newly computed attributes for an existing resource instance differ from what is currently recorded in the state file, Terraform identifies these as 'differences' and proposes actions (e.g., update, replace, or destroy/create) in the execution plan to reconcile the desired state with the actual state.
- ✗
The provider version is incompatible with the new variable type
Why it's wrong here
An incompatibility between the provider version and a new variable type (e.g., passing an unsupported type to a provider argument or using a feature not available in the current provider version) would result in a clear validation error during `terraform plan` or `terraform validate`. Terraform would explicitly report that the argument type is incorrect or that the provider does not support the given configuration, preventing a plan from being generated or applied. It would not silently proceed to show resource changes.
Go deeper
Related to this question
About these practice questions
One of 428 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.