TF-004 Use Terraform outside the core workflow Practice Question
During a CI/CD pipeline run, terraform apply fails halfway through due to a network error. The state file is locked. The team wants to resume from the last successful apply. What should they do?
⚠ Common exam trap
The trap here is the misconception that a failed apply requires manual cleanup or state manipulation, when in fact Terraform's state-aware design allows safe resumption by simply re-running the apply command after fixing the transient issue.
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
✓
Re-run terraform apply after solving the network issue; Terraform will handle partial state.
Terraform's state file tracks all managed resources and their current status. When `terraform apply` fails mid-run, the state is locked to prevent corruption, but Terraform records any resources that were successfully created before the failure. After resolving the network issue, re-running `terraform apply` will use the existing state to detect already-created resources and continue from where it left off, creating only the remaining resources. This is the correct and intended workflow for handling partial state in Terraform.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Re-run terraform apply after solving the network issue; Terraform will handle partial state.
Why this is correct
When a `terraform apply` operation fails midway due to a transient issue like a network problem, Terraform's state file accurately records all resources that were successfully provisioned before the interruption. Because `terraform apply` is idempotent, re-running it after resolving the network issue will prompt Terraform to compare the desired configuration with the current state. It will then intelligently provision only the missing resources and update any that are out of sync, effectively resuming the deployment from where it left off without needing manual intervention or cleanup.
- ✗
Run terraform destroy and then reapply.
Why it's wrong here
Running `terraform destroy` after a partial failure is counterproductive and potentially harmful. If the `terraform apply` failed halfway, it means some resources were successfully created and are recorded in the state file. Executing `terraform destroy` would attempt to remove these already existing resources, which is unnecessary and could lead to service disruption if those resources are already in use or have dependencies. The objective is to complete the deployment, not to revert it entirely.
- ✗
Force unlock the state and then reapply.
Why it's wrong here
Force unlocking the state is an advanced operation that should only be performed when absolutely certain that no other Terraform process is actively modifying the state. While a failed `apply` might leave a stale lock, the primary issue here was a network failure, not a stuck lock preventing subsequent operations. In most cases, a new `terraform apply` command would either acquire the lock or correctly identify a stale lock and prompt for a safe unlock, making a manual `force-unlock` unnecessary and potentially risky if another process were, in fact, still running.
- ✗
Manually delete the partially created resources in the cloud console and reapply.
Why it's wrong here
Manually deleting partially created resources in the cloud console directly introduces configuration drift, where the actual infrastructure no longer matches Terraform's state file or the defined configuration. This practice undermines the core principle of Infrastructure as Code, making subsequent `terraform apply` operations unpredictable and prone to errors. Terraform is designed to manage the lifecycle of resources declaratively, and manual intervention outside of its control can lead to inconsistencies, requiring complex state reconciliation or even complete re-creation of the environment.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every TF-004 question from scratch — 428 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.