TF-004 Implement and maintain state Practice Question
An organization stores state files in an S3 backend with encryption. However, some resource attributes (e.g., database passwords) are stored in plaintext within the state. What is the recommended approach to avoid storing sensitive values in state?
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 a secrets backend like Vault to retrieve secrets at runtime and store only references in state
Terraform can mark outputs as sensitive to hide them from display, but they may still be stored in state. Option A is a common practice to avoid storing secrets directly.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use a secrets backend like Vault to retrieve secrets at runtime and store only references in state
Why this is correct
Integrating Terraform with a dedicated secrets backend, such as HashiCorp Vault, allows sensitive values to be retrieved dynamically at runtime using data sources. This approach ensures that the actual secret values are never directly written into the Terraform state file. Instead, the state only contains non-sensitive references or identifiers, significantly reducing the risk of exposure if the state file is ever compromised, even if encrypted. This method adheres to the principle of least privilege by keeping secrets out of persistent storage.
- ✗
Set the `sensitive` parameter on all resources
Why it's wrong here
The `sensitive` parameter in Terraform is specifically designed to prevent certain output values from being displayed in the console during `terraform plan` and `terraform apply` operations, and from being stored in the remote state's output section. However, this flag does not prevent the sensitive data from being written into the main Terraform state file as part of the resource's attributes. Consequently, the sensitive information would still be stored in plaintext within the state, making it vulnerable if the state file is accessed directly.
- ✗
Enable state encryption with a stronger algorithm
Why it's wrong here
While enabling state encryption with a stronger algorithm is an essential security measure for protecting data at rest, it does not fundamentally prevent sensitive values from being stored within the state file itself. Encryption merely obfuscates the data, requiring a key for decryption. If an attacker gains access to both the encrypted state file and the corresponding decryption key, the sensitive values become exposed. The core problem of sensitive data *residing* in the state file is not solved by encryption alone, only mitigated against passive observation.
- ✗
Use the `terraform state rm` command after apply to remove sensitive attributes
Why it's wrong here
Using the `terraform state rm` command to remove sensitive attributes from the state file after an apply operation is an inappropriate and highly problematic solution. The Terraform state file is the authoritative source of truth for managing infrastructure, mapping real-world resources to your configuration. Removing attributes from the state would cause Terraform to lose track of those specific settings, leading to resource drift, unexpected re-creation, or errors during subsequent `plan` or `apply` operations, as Terraform would no longer know how to manage or update the affected resource's configuration.
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
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.