TF-004 Use Terraform outside the core workflow Practice Question
A CI/CD pipeline runs 'terraform plan' and needs to automatically approve only if no resources will be destroyed. Which approach should be used?
⚠ Common exam trap
TF-004 often tests whether candidates know that terraform validate and terraform fmt do NOT inspect planned changes — only the JSON output of a saved plan reveals destroy actions.
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
✓
Run 'terraform plan -out=plan.tfplan', then 'terraform show -json plan.tfplan' and parse the output for destroy actions.
Running terraform plan -out=plan.tfplan saves the plan in a binary format, and terraform show -json plan.tfplan converts it to machine-readable JSON that includes resource_changes with actions like 'delete' or 'delete, create' (replace). The pipeline can then parse this JSON to detect any destroy actions and gate approval accordingly. This is the only option that programmatically inspects the plan for destroy operations before applying.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run 'terraform apply -auto-approve' after a successful plan.
Why it's wrong here
Running 'terraform apply -auto-approve' immediately executes the planned changes without requiring any manual confirmation. While it automates the application process, it does not provide a mechanism to detect or specifically flag resources that will be destroyed as part of the plan. This approach bypasses the critical human review step that would typically identify and prevent unintended infrastructure destruction. Therefore, it is unsuitable for automatically detecting destroy actions before they occur.
- ✗
Run 'terraform plan -destroy' and check the exit code.
Why it's wrong here
The 'terraform plan -destroy' command explicitly generates a plan that aims to destroy all managed resources, regardless of the current configuration. Its purpose is to show what would happen if all infrastructure were to be torn down, not to detect if a standard 'terraform plan' would result in destroy actions due to configuration changes. Checking its exit code would only confirm that a destroy plan was generated, not whether an unintended destroy is present in a normal update plan.
- ✗
Run 'terraform fmt' to check for formatting issues.
Why it's wrong here
'terraform fmt' is a utility designed exclusively to rewrite Terraform configuration files to a canonical format. Its function is purely stylistic, ensuring consistency in code layout and indentation across a project. This command does not interact with the Terraform state, generate execution plans, or analyze any potential infrastructure changes. Consequently, it provides no information whatsoever regarding planned resource creations, updates, or, critically, destructions.
- ✗
Run 'terraform validate' to ensure no destroys are needed.
Why it's wrong here
The 'terraform validate' command performs checks on the configuration files in the current directory to ensure they are syntactically valid and internally consistent. It verifies attribute names, argument types, and module configurations against the provider schemas. However, 'terraform validate' does not interact with the remote state or generate an execution plan, meaning it cannot predict or report on any resource changes, including destructions, that would occur during an 'apply'.
- ✓
Run 'terraform plan -out=plan.tfplan', then 'terraform show -json plan.tfplan' and parse the output for destroy actions.
Why this is correct
This is the correct and recommended approach for programmatically inspecting a Terraform plan for specific actions. First, 'terraform plan -out=plan.tfplan' saves the detailed execution plan to a binary file. Subsequently, 'terraform show -json plan.tfplan' converts this binary plan into a machine-readable JSON format. This JSON output contains a comprehensive breakdown of all proposed changes, including resource creations, updates, and crucially, destructions, which can then be parsed by a CI/CD pipeline to detect and flag any destroy actions.
Go deeper
Related to this question
About these practice questions
One of 434 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official HashiCorp exam blueprint
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.