Terraform Variable Precedence: Override Order and Workspace Pitfalls
You are managing a multi-environment Terraform configuration using separate workspaces for 'dev', 'staging', and 'prod'. Each workspace uses the same root module but different variable values stored in terraform.tfvars files per workspace. Your team reports that after a recent change to the root module, running `terraform plan` in the 'dev' workspace shows that it will destroy and recreate a critical RDS database instance, even though no changes were made to the database configuration. The state file for 'dev' is stored in a remote S3 backend with DynamoDB locking. You suspect the issue is related to how Terraform generates and reads configuration. What is the most likely cause?
Quick Answer
The answer is a new variable with a default value that forces recreation of the database was added to the root module, but the 'dev' workspace's tfvars file does not override it, so Terraform uses the default which differs from the current state. This occurs because Terraform variable precedence dictates that a default value in the variable block is the lowest priority, but if no workspace-specific override exists in the terraform.tfvars file, that default becomes the effective value. When that default differs from the value recorded in the state file—such as a database engine version or instance class—Terraform sees a configuration drift and plans a destroy-and-recreate. On the HashiCorp Terraform Associate TF-003 exam, this scenario tests your understanding of variable precedence order and the common pitfall of forgetting to update workspace-specific variable files after adding a new variable to the root module. The trap is that the state file still holds the old value, but the configuration now supplies a different default. Memory tip: "Default is last—if you don't override, the state will be overridden."
⚠ Common exam trap
HashiCorp often tests the misconception that state corruption or backend misconfiguration is the root cause, when the real issue is Terraform's variable default behavior and its interaction with 'ForceNew' attributes in resource schemas.
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
✓
A new variable with a default value that forces recreation of the database was added to the root module, but the 'dev' workspace's tfvars file does not override it, so Terraform uses the default which differs from the current state.
When a new variable with a default value is added to the root module, and the 'dev' workspace's terraform.tfvars does not override it, Terraform uses the default value. If that default differs from the value currently tracked in the state (e.g., a database engine version or instance class), Terraform interprets this as a configuration change and plans to destroy and recreate the resource to match the new default. This is a common pitfall when variables are introduced without updating all workspace-specific variable files.
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 S3 backend is misconfigured, causing the 'dev' workspace to use the 'prod' state file.
Why it's wrong here
Workspaces use separate state paths; misconfiguration would cause different symptoms.
- ✓
A new variable with a default value that forces recreation of the database was added to the root module, but the 'dev' workspace's tfvars file does not override it, so Terraform uses the default which differs from the current state.
Why this is correct
This is a common issue: adding a variable with a default that differs from the existing attribute causes a plan to update in-place or recreate.
- ✗
The root module was changed to use a different Terraform provider version that is incompatible with the existing state.
Why it's wrong here
Provider version changes may cause issues, but typically not force recreation of a resource unless the provider schema changed.
- ✗
The DynamoDB lock is not being released after previous operations, causing state corruption.
Why it's wrong here
State locking prevents corruption, not causes it.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
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 →
Same concept, more angles
2 more ways this is tested on TF-004
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A configuration defines a variable `instance_type` with a default value `t2.micro`. After running `terraform apply`, the operator notices that the instances are being created with type `t2.small`. They check the configuration file and see the default is `t2.micro`. What is the most likely cause?
medium- A.The variable declaration was changed after apply.
- B.The state file stores the variable value and overrides the default.
- ✓ C.A `terraform.tfvars` file in the working directory sets the variable to `t2.small`.
- D.The `instance_type` attribute was changed by a lifecycle rule.
Why C: Terraform automatically loads any file named `terraform.tfvars` or `*.auto.tfvars` in the working directory, and the variable values defined in these files override the default values declared in the configuration. Even though the configuration file shows `instance_type` defaulting to `t2.micro`, the presence of a `terraform.tfvars` file setting `instance_type = "t2.small"` will cause Terraform to use `t2.small` during `apply`, explaining the observed behavior.
Variation 2. A configuration uses variables defined in a 'variables.tf' file. The operator wants to override these variables for a specific run without modifying the file. Which method should they use?
easy- A.Edit the state file directly.
- B.Set environment variables with the same name as the variables.
- C.Create a 'terraform.tfvars' file.
- ✓ D.Use the '-var' flag with 'terraform plan' or 'terraform apply'.
Why D: The `-var` flag on `terraform plan` or `terraform apply` allows operators to override variable values for a single run without modifying any files. This is the correct method because it provides a temporary override that does not persist across runs, unlike file-based or environment variable approaches.
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.