HashiCorp Terraform Associate (004) Question 127
Single answer4h Understand best practices for managing sensitive data, including secrets management with VaultYour team uses Terraform in a CI/CD pipeline to provision cloud infrastructure. A recent security review found that a database administrator password was hardcoded in a Terraform variable file and also appeared in Terraform state after being used to configure a managed database resource. The team wants to reduce secret exposure while continuing to use Terraform and HashiCorp Vault. Which approach is the MOST appropriate?
- A
Store the password in Vault, read it from Terraform using a Vault data source at apply time, and mark the Terraform variable as sensitive so the secret is fully prevented from appearing in state.
- B
Store the password in Vault and use Terraform only to retrieve the secret when needed, understanding that if Terraform uses the secret in resource arguments it can still be written to state depending on the provider and resource behavior.
- C
Encrypt the terraform.tfvars file with GPG and commit it to version control, because encrypted variable files are not considered sensitive data once committed.
- D
Set the password as an environment variable named TF_VAR_db_password on the CI runner, because values passed through TF_VAR variables are never stored in state.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to store secrets in Vault and retrieve them at run time rather than hardcoding them in Terraform configuration or variable files. This aligns with Terraform and Vault best practices for sensitive data handling. However, candidates must also recognize a key Terraform concept tested on the Associate exam: sensitive data can still end up in state when used in managed resources, because state records resource attributes as returned or maintained by providers. Marking variables or outputs as sensitive helps reduce accidental display in CLI output, but it is not a state-encryption mechanism and does not guarantee secrets are omitted from state. Therefore, the practical best practice is a combination of using Vault for secret storage, minimizing secret use in Terraform where possible, and securing remote state with appropriate access controls and encryption. Relevant references include Terraform documentation on managing sensitive data and state, as well as Vault provider/data source usage patterns.
- A. Incorrect.
This is incorrect because although Vault is an appropriate place to store and access secrets, marking an input variable as sensitive does not guarantee the value will never appear in Terraform state. The sensitive setting mainly affects CLI output and redaction in plans and logs. If a provider/resource stores that value in state, Terraform state can still contain it.
- B. Correct.
This is correct. A recommended practice is to keep secrets out of configuration files and version control by storing them in a secrets manager such as Vault. However, Terraform users must understand an important limitation: when secret values are supplied to resources, providers may persist those values in state. Using Vault reduces exposure in code and variable files, but does not automatically eliminate state sensitivity concerns. This is why protecting state storage and limiting state access remain critical best practices.
- C. Incorrect.
This is incorrect because encrypting a tfvars file before commit may reduce some risk, but it is not the preferred best practice for operational secret management in Terraform. The secret still exists as a static credential that must be decrypted for use, and teams must manage keys separately. HashiCorp guidance generally favors dedicated secrets management systems like Vault over storing secrets in configuration artifacts, even if encrypted.
- D. Incorrect.
This is incorrect because environment variables can be useful to avoid hardcoding values in files, but they do not prevent secrets from being written to state if those values are used by resources that persist them. This option reflects a common misconception: input method changes how Terraform receives a value, not how providers handle it in state.