TF-004 Use the core Terraform workflow Practice Question
After modifying a Terraform configuration file, a user runs 'terraform plan' and sees 'No changes. Infrastructure is up-to-date.' What is the most likely reason?
⚠ Common exam trap
Many candidates assume 'No changes' always means the infrastructure is truly up-to-date, overlooking the possibility that Terraform is simply evaluating the wrong set of configuration files due to directory 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 configuration changes were made in a different directory.
Terraform operates on the configuration files in the current working directory. If the user modified a Terraform configuration file in a different directory and then ran 'terraform plan' from the original directory, Terraform would compare the state against the unchanged configuration in the current directory, resulting in 'No changes. Infrastructure is up-to-date.'
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 user forgot to run terraform init.
Why it's wrong here
Running `terraform init` is primarily necessary to initialize a working directory, download provider plugins, and configure backend state. If only resource attributes or arguments within existing configurations are modified, `terraform plan` does not require a re-initialization. If `init` were truly needed (e.g., for a new provider or module), `terraform plan` would typically fail with an error indicating uninitialized components, rather than simply showing no changes.
- ✗
The configuration changes were not committed to version control.
Why it's wrong here
Terraform operates directly on the `.tf` configuration files present in the local filesystem of the current working directory. It does not inherently interact with or depend on version control systems like Git to detect configuration changes. Whether changes are committed, staged, or merely saved locally is irrelevant to `terraform plan`'s ability to identify differences between the current configuration and the remote state.
- ✗
The state is stored remotely and the user does not have access.
Why it's wrong here
If Terraform were unable to access the remote state backend, `terraform plan` would not simply report "no changes." Instead, it would terminate with a distinct error message indicating a failure to read or lock the state file, preventing it from comparing the current configuration against the infrastructure's actual state. A successful `plan` that shows no changes implies successful state access.
- ✓
The configuration changes were made in a different directory.
Why this is correct
Terraform commands, including `terraform plan`, operate strictly within the current working directory where the command is executed, unless explicitly specified otherwise with the `-chdir` option. If configuration files were modified in a separate directory, `terraform plan` run in the original directory would not detect those changes, as it only evaluates the `.tf` files present in its execution context, comparing them against the associated state file.
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.