TF-004 Implement and maintain state Practice Question
Which TWO of the following are required when configuring a Terraform backend for remote state storage?
⚠ Common exam trap
A common misconception is that state locking is mandatory for all Terraform backends, but it is an optional feature. For example, the S3 backend requires explicit configuration of locking via DynamoDB; not all backends support locking by default.
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
✓
A backend type (e.g., s3, azurerm, gcs)
Every Terraform backend configuration must specify a backend type (e.g., s3, azurerm, gcs) to define where state is stored. Option E is correct because authentication credentials are required to access the remote backend; without valid credentials, Terraform cannot read or write state to the configured storage location.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Encryption at rest configuration
Why it's wrong here
While highly recommended for security, explicitly configuring encryption at rest for the state file is typically a feature managed by the chosen backend service itself (e.g., S3 bucket policies, Azure Storage encryption settings) rather than a direct, mandatory configuration within Terraform's `backend` block. Terraform primarily needs to know *where* to store the state, not necessarily *how* that storage is encrypted. Therefore, it is not a *required* configuration element within the Terraform code.
- ✗
State locking support
Why it's wrong here
State locking is a crucial feature for preventing concurrent operations from corrupting the state file, especially in collaborative environments. However, not all Terraform backends inherently support state locking, or it might be an optional feature that can be disabled. Terraform can still be configured and operate without state locking enabled, though this is strongly discouraged for production use cases involving multiple operators. Thus, it is not a *mandatory* requirement for backend configuration.
- ✓
A backend type (e.g., s3, azurerm, gcs)
Why this is correct
Specifying a backend type is absolutely fundamental because Terraform needs to know which remote storage service it should interact with to store and retrieve the state file. The `backend` block requires a named type, such as `s3`, `azurerm`, `gcs`, or `remote` (for Terraform Cloud/Enterprise), to correctly initialize the provider responsible for managing the state's persistence. Without this explicit declaration, Terraform cannot establish a connection to any remote location.
- ✗
Workspace configuration
Why it's wrong here
Workspaces provide a mechanism for managing multiple distinct states for a single Terraform configuration, often used for different environments like `dev`, `staging`, or `prod`. While useful for organizational purposes, configuring specific workspaces is entirely optional and not a prerequisite for setting up a backend. Terraform defaults to the `default` workspace if none are explicitly created or selected, meaning the backend can function without any explicit workspace configuration.
- ✓
Authentication credentials to access the backend
Why this is correct
To successfully interact with any remote backend, Terraform requires appropriate authentication credentials to authorize read and write operations on the state file. Whether these are explicit access keys, IAM roles, service principal credentials, or API tokens, Terraform must be able to authenticate with the chosen backend service to manage the state. Without valid credentials, Terraform cannot access or modify the remote state, rendering the backend configuration non-functional.
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
One of 428 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.