TF-004 Understand Terraform basics Practice Question
An organization uses Terraform with multiple workspaces to manage different environments (dev, staging, prod). They want to ensure that sensitive variables for prod are not exposed in the plan output. What should they do?
⚠ Common exam trap
A common misconception is that storing a variable in an environment variable or using a data source automatically hides it from plan output, when in fact only the `sensitive` attribute in the variable definition controls CLI display.
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
✓
Mark the variable as `sensitive = true` in the variable definition
Marking a variable as `sensitive = true` in the variable definition prevents Terraform from displaying its value in CLI output, including plan and apply summaries. This is the direct and intended mechanism to protect sensitive data from exposure during Terraform operations, without affecting how the variable is stored or used.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Mark the variable as `sensitive = true` in the variable definition
Why this is correct
Marking a variable as `sensitive = true` in its `variable` block definition instructs Terraform to redact its value from the console output during `terraform plan`, `terraform apply`, and `terraform output` commands. This prevents the secret from being accidentally exposed in logs or terminal displays. While the value is still stored in the state file, this flag significantly reduces the risk of inadvertent exposure during routine operations.
- ✗
Use an output block to display the variable only when needed
Why it's wrong here
An output block's primary function is to explicitly display values from the Terraform configuration, making them accessible after an apply operation. Even if an output is conditionally displayed, its very purpose is to expose the value, directly contradicting the goal of hiding sensitive information. Therefore, using an output block for a sensitive variable would defeat the purpose of keeping it secret, as it would be printed to standard output.
- ✗
Store the variable in the state file
Why it's wrong here
Storing a sensitive variable directly within the Terraform state file is a significant security vulnerability. State files, especially when stored in remote backends without specific encryption at rest, can often be accessed by authorized users or systems, potentially exposing plaintext secrets. While some backends offer encryption, relying solely on the state file for secret storage is generally discouraged due to the risk of unauthorized access or accidental exposure.
- ✗
Store the variable in an environment variable instead of a .tfvars file
Why it's wrong here
While using environment variables (e.g., `TF_VAR_my_secret`) is a common method to inject values without hardcoding them or committing them to version control, it does not inherently prevent Terraform from printing these values. Unless the corresponding `variable` definition in the `.tf` file is explicitly marked with `sensitive = true`, Terraform will still display the environment variable's value in plan and apply outputs. This means the secret could still appear in console logs or CI/CD pipelines.
- ✗
Use a data source to retrieve the secret at runtime
Why it's wrong here
Using a data source to retrieve a secret from a dedicated secret management service (like AWS Secrets Manager or HashiCorp Vault) is a recommended security practice for storing secrets. However, the act of retrieving the secret via a data source does not automatically mask its value within Terraform's execution outputs. The retrieved value, once referenced in a resource or an output, will still be displayed in plaintext during `terraform plan` or `terraform apply` unless the specific attribute or output referencing it is also marked as sensitive.
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.