TF-004 Use the core Terraform workflow Practice Question
A team wants to ensure that all Terraform runs are recorded for audit purposes. Which practice should they implement?
⚠ Common exam trap
HashiCorp often tests the distinction between state locking (a concurrency safety feature) and state versioning (an audit/history feature), causing candidates to mistakenly choose state locking as the solution for audit trails.
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
✓
Configure a remote backend that supports state versioning.
Configuring a remote backend that supports state versioning (e.g., Terraform Cloud, S3 with versioning enabled) automatically records every state change, providing a complete audit trail of all Terraform runs. This ensures that previous state snapshots are preserved and can be reviewed or restored if needed, meeting audit requirements without manual intervention.
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 show' after every apply to capture state.
Why it's wrong here
Running 'terraform show' merely outputs the current state to the console, providing an ephemeral snapshot. It does not persist this information or create a historical record of changes over time. Manually capturing and storing this output after every run would be inefficient, prone to human error, and would not constitute a reliable, auditable history of Terraform runs.
- ✗
Add the state file to version control after each run.
Why it's wrong here
Adding the 'terraform.tfstate' file directly to version control is a widely discouraged practice. State files often contain sensitive data and are frequently updated, leading to merge conflicts, unreadable diffs, and potential exposure of secrets. This method lacks the crucial features of state locking, atomicity, and secure storage provided by dedicated remote backends, making it unsuitable for robust team collaboration and historical tracking.
- ✗
Enable state locking in the backend configuration.
Why it's wrong here
Enabling state locking in a backend configuration is designed to prevent concurrent 'terraform apply' operations from corrupting the state file. Its primary function is to ensure atomicity and consistency during active modifications, not to provide a historical record or versioning of the state itself. While vital for team collaboration, locking does not store previous state versions or offer an audit trail of infrastructure changes over time.
- ✓
Configure a remote backend that supports state versioning.
Why this is correct
Configuring a remote backend that supports state versioning is the recommended and most effective solution. Services like Amazon S3 with versioning or Azure Storage blobs automatically store a new, immutable version of the state file every time 'terraform apply' is executed. This creates a comprehensive, auditable history of all infrastructure changes, enabling easy rollback to previous states and ensuring all Terraform runs are reliably recorded for compliance and operational visibility.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
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.