TF-004 Understand Terraform basics Practice Question
You are a DevOps engineer managing a multi-environment Terraform setup using workspaces. Your team has three workspaces: dev, staging, and prod. All infrastructure is defined in a single root module with environment-specific variable values stored in separate .tfvars files. Recently, a colleague accidentally ran terraform destroy in the prod workspace, which deleted critical production resources. You need to implement a safety mechanism to prevent accidental destruction of production resources in the future. The solution should not require changes to the Terraform provider or backend configuration. Which approach should you take?
⚠ Common exam trap
HashiCorp often tests the distinction between native Terraform features (like `lifecycle` preconditions) and external tools (like wrapper scripts or Sentinel) that require additional infrastructure or configuration changes, leading candidates to choose a non-native solution that is not self-contained within the root module.
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
✓
Add a lifecycle precondition block in a null_resource that checks if the current workspace is 'prod' and fails if terraform destroy is attempted.
A `lifecycle` precondition block in a `null_resource` can evaluate the current workspace at plan time using `terraform.workspace`. When `terraform destroy` is run, the precondition fails if the workspace is `prod`, preventing the destroy operation without altering the provider or backend configuration. This approach is native to Terraform, requires no external tools, and directly enforces the safety check within the configuration itself.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a wrapper script that checks the workspace before running terraform destroy and requires a manual confirmation for prod.
Why it's wrong here
While a wrapper script can add an external layer of protection, it operates outside of Terraform's core execution lifecycle and control plane. This approach relies entirely on the user consistently invoking the script and does not leverage Terraform's built-in validation or policy enforcement capabilities. It is a procedural control rather than an infrastructure-as-code enforcement, making it prone to bypass if the user directly invokes `terraform destroy`.
- ✗
Use Terraform Sentinel policies with a mandatory policy that denies destroy on the prod workspace.
Why it's wrong here
Terraform Sentinel policies offer robust, granular control over infrastructure changes, including the ability to prevent `terraform destroy` operations on specific workspaces like 'prod'. However, Sentinel is an advanced feature exclusively available with Terraform Cloud and Terraform Enterprise editions. It is not a native capability of Terraform Open Source, making this solution inapplicable for environments using only the OSS version.
- ✗
Configure a remote backend with state locking and force unlock only for non-prod workspaces.
Why it's wrong here
Configuring a remote backend with state locking is crucial for collaborative environments, as it prevents concurrent `terraform apply` or `destroy` operations from corrupting the state file. However, state locking's primary function is concurrency control, not conditional prevention of resource destruction. It does not offer a mechanism to specifically deny `terraform destroy` based on the active workspace, nor does "force unlock" provide such a capability.
- ✓
Add a lifecycle precondition block in a null_resource that checks if the current workspace is 'prod' and fails if terraform destroy is attempted.
Why this is correct
A `lifecycle` precondition block allows for custom validation checks that are evaluated during the plan and apply phases, including `terraform destroy`. By placing a precondition within a `null_resource` that checks `terraform.workspace == "prod"` and setting an `error_message` if true, Terraform will explicitly fail the `destroy` operation before any resources are touched. This provides a declarative, Terraform-native safety mechanism directly within the configuration.
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.