TF-004 Implement and maintain state Practice Question
You are a DevOps engineer at a company that uses Terraform to manage infrastructure in AWS. The team recently adopted Terraform Cloud for remote state management and collaboration. They have a single workspace named 'production' that manages all production resources. Currently, the state file is stored in Terraform Cloud's default backend. The team wants to implement a disaster recovery strategy where they can restore the state file if Terraform Cloud experiences an outage. They also want to ensure that state file backups are taken automatically before every apply. Which approach should they recommend?
⚠ Common exam trap
A common mix-up: candidates assume Terraform Cloud's internal state storage is configurable or that switching to an S3 backend is compatible with Terraform Cloud's remote execution model, but Terraform Cloud requires its own backend for state management and does not expose underlying storage for replication.
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
✓
Use Terraform Cloud's API to download the state file before each apply and store it in a secure S3 bucket with versioning enabled
It leverages the Terraform Cloud API to programmatically download the state file before each apply, storing it in a customer-managed S3 bucket with versioning enabled. This creates automatic, auditable backups independent of Terraform Cloud's availability, satisfying the disaster recovery requirement without changing the remote execution model. Options A and C are either manual or incompatible with Terraform Cloud's remote state management, and option B is not possible as Terraform Cloud does not expose its internal storage for replication.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Manually download the state file from Terraform Cloud UI after each apply
Why it's wrong here
Manually downloading state files from the Terraform Cloud UI after each apply is highly inefficient and prone to human error. This process lacks automation, making it difficult to scale and ensure consistent backups, especially in a busy CI/CD pipeline. It fails to provide a reliable, automated disaster recovery mechanism, as a missed download could lead to data loss and inconsistencies.
- ✗
Enable S3 replication on Terraform Cloud's internal state storage
Why it's wrong here
Terraform Cloud's internal state storage is a managed service, meaning users do not have direct access or configuration control over its underlying infrastructure, including S3 buckets. Therefore, attempting to enable S3 replication on Terraform Cloud's internal storage is not possible. This option misunderstands the operational boundaries and shared responsibility model of a SaaS platform.
- ✗
Switch to an S3 backend with DynamoDB locking and configure Terraform Cloud to run remotely but store state locally
Why it's wrong here
Configuring Terraform Cloud to run remotely while simultaneously attempting to store state locally defeats the core purpose of remote state management and collaboration. Terraform Cloud relies on managing the state file centrally to ensure consistency, apply locking, and facilitate team collaboration across remote operations. Storing state locally would introduce significant state drift, concurrency issues, and prevent Terraform Cloud from effectively managing the infrastructure.
- ✓
Use Terraform Cloud's API to download the state file before each apply and store it in a secure S3 bucket with versioning enabled
Why this is correct
Utilizing Terraform Cloud's API to programmatically download the state file before each apply provides a robust, automated backup solution. Storing these downloaded state files in a separate, secure S3 bucket with versioning enabled creates an immutable audit trail and a reliable recovery point. This strategy ensures that a consistent backup exists prior to any potential infrastructure changes, offering a critical layer of disaster recovery and compliance.
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.