TF-004 Understand Terraform's purpose Practice Question
An organization has a multi-cloud strategy using Terraform. They need to ensure that secrets such as API keys are not stored in plaintext in the configuration files. Which Terraform feature should they use to securely manage sensitive data?
⚠ Common exam trap
A common trap in Terraform certification is thinking that marking outputs as sensitive or using environment variables is sufficient for secure secret management, but those methods do not prevent secrets from being stored in plaintext in the state file or configuration files. Only integration with a secrets management tool like Vault ensures secrets are never exposed in plaintext.
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
✓
Integration with a secrets management tool like Vault
Integrating Terraform with a dedicated secrets management tool like HashiCorp Vault allows sensitive data (e.g., API keys, passwords) to be stored securely and retrieved at runtime via data sources, rather than being hardcoded in plaintext in configuration files. This approach ensures secrets are never written to disk in plaintext, are encrypted in transit and at rest, and can be dynamically rotated without modifying Terraform code.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Terraform variable definitions with environment variables
Why it's wrong here
While environment variables (e.g., TF_VAR_my_secret) can pass values to Terraform, they are not a secure secrets management solution. They can easily be exposed in shell history, process lists, CI/CD logs, or debugging output, making them unsuitable for sensitive data in a multi-cloud strategy where auditing and security are paramount. This method does not provide dynamic secret generation, rotation, or fine-grained access control, leaving secrets vulnerable.
- ✗
Terraform workspaces
Why it's wrong here
Terraform workspaces are designed to manage multiple distinct instances of the same configuration within a single backend, primarily by isolating state files. They do not, however, offer any mechanism for securing sensitive data embedded within the configuration files themselves or passed as variables. Secrets would still reside in plaintext or easily accessible forms within the configuration or variable definitions, regardless of the workspace in use.
- ✓
Integration with a secrets management tool like Vault
Why this is correct
Integrating with a dedicated secrets management tool like HashiCorp Vault is the most robust solution for securing sensitive data in a multi-cloud Terraform strategy. Vault provides centralized, secure storage for static secrets and can dynamically generate temporary credentials for various services, ensuring secrets are never hardcoded in configuration. This approach allows secrets to be retrieved at runtime, benefiting from strong encryption, auditing, and fine-grained access control policies.
- ✗
Terraform state file encryption
Why it's wrong here
Encrypting the Terraform state file primarily protects the *state* of your infrastructure at rest, preventing unauthorized access to resource attributes and outputs stored within it. While important for overall security, it does not address the fundamental problem of secrets being present in the Terraform configuration files, variable definitions, or command-line arguments *before* they are ever written to the state. Secrets would still be exposed during the plan or apply phases.
- ✗
Terraform's sensitive parameter in output blocks
Why it's wrong here
The `sensitive` parameter in Terraform output blocks prevents the value from being displayed in the console output or stored in plaintext in the state file when `terraform output` is run. However, this only applies to *outputs* and does not secure the original source of the sensitive data, such as variables or hardcoded values within the configuration. The secret still exists in an insecure location within the configuration or variable files prior to being marked as sensitive in an output.
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.