TF-004 Understand Terraform basics Practice Question
A company is using Terraform to manage secrets in AWS Secrets Manager. They want to ensure that sensitive values are not exposed in logs, the console, or plan output. Which two practices should they implement? (Choose two.)
⚠ Common exam trap
A common trap is thinking that using a remote backend with encryption or a data source alone is sufficient to protect secrets from exposure in logs and plan output, when in fact only explicit `sensitive` annotations on variables and outputs control 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
✓
Use the sensitive flag in variable definitions
Marking a variable with `sensitive = true` in its definition block tells Terraform to redact its value in CLI output, logs, and plan output. This prevents the secret from being displayed in plaintext during `terraform plan` or `terraform apply`, even if the variable is used in a resource argument. Option E is correct because setting `sensitive = true` on an output value instructs Terraform to suppress that output in the CLI and in any logs or console displays, ensuring the secret value is not exposed after apply.
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 the sensitive flag in variable definitions
Why this is correct
Using sensitive = true within a variable definition explicitly instructs Terraform to redact the variable's value from all CLI outputs, including terraform plan and terraform apply. This ensures that sensitive data, such as API keys or database credentials, is replaced with (sensitive value) in the console, preventing accidental exposure in build logs or terminal history. This mechanism is crucial for maintaining the confidentiality of secrets during the infrastructure provisioning lifecycle.
- ✗
Use a remote backend with encryption
Why it's wrong here
While using a remote backend with encryption, such as an S3 bucket with SSE-KMS, is essential for securing the Terraform state file at rest, it does not influence the visibility of sensitive data in the CLI output. The encryption protects the stored state file from unauthorized access but does not prevent variable values from being displayed in plaintext during terraform plan or terraform apply operations. This measure addresses data at rest, not data in transit or display during execution.
- ✗
Use a data source to fetch secrets at runtime instead of hardcoding
Why it's wrong here
Employing a data source to fetch secrets at runtime, for instance from AWS Secrets Manager, is a robust security practice for avoiding hardcoded credentials. However, fetching a secret via a data source does not automatically mark its value as sensitive for display purposes in the terraform plan output. Unless the specific attribute containing the fetched secret is then passed to a sensitive variable or output, or the resource argument itself is implicitly sensitive, the secret's value may still appear in the plan.
- ✗
Store variable values in terraform.tfvars file
Why it's wrong here
Storing variable values in a terraform.tfvars file is merely a method for supplying input values to Terraform configurations, offering no inherent security or obfuscation properties. Regardless of whether a variable's value originates from a .tfvars file, environment variables, or the command line, Terraform will display it in the plan output by default. This file type serves as a convenient input mechanism, not a security control for output redaction.
- ✓
Mark outputs as sensitive = true
Why this is correct
Marking an output block with sensitive = true ensures that the value of that specific output is redacted from the CLI after a terraform apply operation completes and when using terraform output. This prevents sensitive information, such as generated passwords or private keys, from being displayed in the terminal summary or retrieved via subsequent terraform output commands. However, this protection applies only to the output itself and does not prevent the value from appearing in the terraform plan if it's part of a resource argument.
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.