TF-004 Understand IaC concepts Practice Question
A company manages multiple AWS accounts using Terraform. They have a central repository where all Terraform configurations are stored. Recently, a developer accidentally ran terraform destroy on a production workspace and deleted critical resources. The team wants to implement safeguards to prevent such incidents while still allowing developers to test changes in non-production environments. They currently use Terraform Cloud for remote state management and runs. Which course of action should the team take to minimize risk?
⚠ Common exam trap
The trap here is assuming that code-level safeguards like prevent_destroy are sufficient, when in fact they can be bypassed, and overlooking Terraform Cloud's native run tasks that provide centralized approval for destructive operations.
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
✓
Implement run tasks in Terraform Cloud that require approval for any destroy operation on workspaces tagged as 'production'.
Implementing run tasks in Terraform Cloud that require approval for any destroy operation on workspaces tagged as 'production' adds a safeguard that prevents accidental destruction while still allowing developers to test changes in non-production environments. This approach uses Terraform Cloud's native capabilities to enforce manual approval for destructive actions on production workspaces, minimizing risk without hindering development workflows.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store the production Terraform state file locally and restrict access to it.
Why it's wrong here
Storing the production Terraform state file locally is highly problematic for a company managing multiple AWS accounts. Local state lacks crucial features like remote locking, versioning, and centralized access control, making collaborative development prone to conflicts and data corruption. It also presents significant security risks, as the state file contains sensitive resource information and is not easily backed up or audited in a distributed team environment.
- ✗
Use Terraform's built-in lifecycle prevent_destroy on all production resources.
Why it's wrong here
Using Terraform's built-in `lifecycle prevent_destroy` on all production resources is an inflexible and impractical solution. This setting statically blocks *any* destruction operation, even those that are intentionally planned and approved, requiring manual removal of the flag from the configuration before any resource can be destroyed. It does not provide an approval workflow or differentiate between accidental and legitimate destruction, making it cumbersome and unscalable for dynamic production environments.
- ✓
Implement run tasks in Terraform Cloud that require approval for any destroy operation on workspaces tagged as 'production'.
Why this is correct
Implementing run tasks in Terraform Cloud that require approval for any destroy operation on workspaces tagged as 'production' is an effective and scalable solution. Terraform Cloud run tasks allow for custom policy enforcement and integration with external systems, enabling a mandatory manual approval step specifically for destructive actions on critical resources. This provides a robust governance mechanism, ensuring that production infrastructure changes are reviewed and authorized before execution, thereby preventing accidental destruction.
- ✗
Remove all developers' access to the Terraform Cloud API and only allow operations via pull requests.
Why it's wrong here
Removing all developers' access to the Terraform Cloud API and only allowing operations via pull requests severely limits developer productivity and the platform's capabilities. While VCS-driven workflows are beneficial, restricting API access prevents legitimate programmatic interactions, automation, and integration with CI/CD pipelines or other management tools. This approach creates unnecessary bottlenecks and does not leverage Terraform Cloud's robust access control and policy features designed for secure, automated operations.
Go deeper
Related to this question
About these practice questions
This TF-004 question is part of Courseiva's 434-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.