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?
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'.
Terraform Cloud run tasks can enforce approval workflows for destroy operations on production workspaces, providing a safeguard against accidental deletions while still allowing developers to test in non-production environments. Option A is wrong because storing state locally is insecure and eliminates the benefits of remote state management. Option B is wrong because `prevent_destroy` blocks all destroy operations, including intentional ones, and is not a flexible safeguard. Option D is wrong because removing API access entirely is too restrictive and hinders legitimate operations; instead, proper permissions and approval workflows should be used.
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 428-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 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.