TF-Associate-004 - Terraform configuration (21% of the exam) - Section 4h
Understand best practices for managing sensitive data, including secrets management with Vault.
Marking values sensitive suppresses them in output, but they are still stored in plaintext in state, so state must be protected. Candidates should understand sourcing secrets from a system such as Vault rather than committing them, and why sensitive does not encrypt state.
sensitive argumentsecrets in state are plaintextHashiCorp Vault providerprotecting state files
Practice question for this objective
lock_openFree sampleTerraform configurationmedium
A module exposes a generated database password through an output and marks that output with sensitive = true. A colleague expects that the value will now be encrypted where Terraform records it and hidden everywhere. Which statement most accurately describes what sensitive = true actually does?
output "db_password" {
value = random_password.db.result
sensitive = true
}
AIt encrypts the output value inside the state file and redacts it from CLI output, so the plaintext never appears in state or on screen.
BIt prevents the output from being written to state at all, so the value exists only transiently during the run and cannot be read afterwards.
CIt blocks other configurations from reading the output through a remote state data source, restricting access to the declaring module only.
DIt redacts the value from plan, apply, and output display, but the value is still stored in plaintext in the state file.check_circle Correct
Marking an output sensitive redacts it from CLI display but does not encrypt it or remove it from the plaintext state file. The sensitive argument on an output tells Terraform to hide the value in plan, apply, and terraform output, and to propagate the sensitive marking to expressions that use it. It does not encrypt state or prevent persistence, so the underlying value remains readable to anyone who can open the state file.
Why A is wrong: Tempting because sensitive sounds like encryption, but Terraform state stores sensitive values in plaintext; the flag only affects display, so this overstates the protection.
Why B is wrong: Tempting if a candidate assumes hiding implies exclusion, but outputs are always persisted to state; sensitive does not stop the value being recorded there.
Why C is wrong: Tempting because it sounds like an access control, but sensitive imposes no cross configuration read restriction; a remote state data source can still consume the value.
Why D is correct: Correct: the sensitive flag suppresses the value in CLI output and marks it as sensitive downstream, yet Terraform writes it to state as plaintext, so the state file must still be protected by other means.
Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.
The value is encrypted inside the state file automatically once the variable is marked sensitive, so no further action is required.
errorWhy it is wrong: Tempting because sensitive sounds like it secures storage, but the local backend does not encrypt state; the marking only affects console output.
Terraform encrypts the value both in the state file and in any CLI output, so it can never be read back in plaintext.
errorWhy it is wrong: This is tempting because the label 'sensitive' suggests encryption, but Terraform does not encrypt sensitive values; it only redacts them from display while storing them in plaintext.
It encrypts the entire Terraform state file at rest using a Vault-managed key.
errorWhy it is wrong: State encryption at rest is a backend concern, not a function of the Vault provider, which reads and writes Vault data rather than encrypting the state file.