TF-004 Use the core Terraform workflow Practice Question
Which TWO scenarios could cause 'terraform plan' to show 'No changes' even though the configuration file was recently modified? (Choose two.)
⚠ Common exam trap
HashiCorp often tests the misconception that manual cloud console changes always cause plan output to show changes, but the trap here is that `ignore_changes` can suppress those diffs, and running `terraform plan` from the wrong directory can cause the command to read unmodified files, both leading to a false 'No changes' result.
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 user ran 'terraform plan' from a different directory that does not contain the modified configuration.
`terraform plan` operates on the configuration files in the current working directory. If the user runs the command from a different directory that does not contain the modified configuration, Terraform will compare the state against the unmodified files in that directory, resulting in 'No changes'. Option B is correct because a `lifecycle` block with `ignore_changes` tells Terraform to disregard changes to specified attributes when planning, so even if the configuration file modifies that attribute, Terraform will not detect a diff and will report 'No changes'.
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 ran 'terraform plan' from a different directory that does not contain the modified configuration.
Why this is correct
terraform plan operates strictly within the current working directory, scanning for .tf configuration files to build its desired state. If a user executes terraform plan from a directory that does not contain the relevant configuration files, or an outdated set, Terraform will not detect any changes made to files in other directories. Consequently, the plan output will reflect no changes, as it's comparing the current state to an unchanged or non-existent desired state from its perspective.
- ✓
A lifecycle block with ignore_changes was applied to the modified attribute.
Why this is correct
When a lifecycle block with ignore_changes is configured for a specific attribute within a resource, Terraform is explicitly instructed to disregard any differences detected for that attribute between the current state and the desired configuration. If the modification made to the configuration affects an attribute listed in ignore_changes, Terraform will not register it as a pending change during terraform plan. This prevents Terraform from attempting to update or re-create the resource based on that particular attribute's divergence.
- ✗
The resource was manually updated in the cloud provider console.
Why it's wrong here
terraform plan inherently includes a refresh phase, where it queries the cloud provider to determine the actual current state of managed resources. If a resource was manually updated in the cloud provider console, this change would be detected as "drift" during the refresh. Terraform would then propose actions to bring the actual state back into alignment with the configuration, meaning the plan would show changes, not no changes, unless the refresh operation itself was explicitly suppressed.
- ✗
A new resource block was added.
Why it's wrong here
Adding a new resource block to the Terraform configuration explicitly declares a desired resource that does not yet exist in the Terraform state file or the cloud provider. When terraform plan is executed, it will identify this new declaration and propose a create action for that resource. Therefore, the plan output would clearly indicate the addition of a new resource, showing a change, rather than displaying no changes.
- ✗
The provider version was changed in the required_providers block.
Why it's wrong here
Changing the provider version in the required_providers block can potentially introduce new resource attributes, modify existing ones, or alter resource behavior due to API changes in the provider. After running terraform init -upgrade, a subsequent terraform plan would compare the existing state against the configuration interpreted by the new provider version. This comparison could lead to proposed updates, replacements, or even no-op changes if the new provider version has no impact on the configured resources, but it would not inherently result in "no changes" if the configuration itself was unchanged and the provider version change had an effect. It's highly unlikely to consistently show "no changes" if the change is significant enough to warrant a version bump.
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.