Auditors find database passwords in plaintext inside a terraform.tfstate object in the S3 bucket used as a team's backend. Every engineer in the account can read the bucket, and server-side encryption is off. Which response addresses the finding?
Select an answer to reveal the explanation.
Short Explanation
Here's the hard truth: state is a diary of your infrastructure, secrets included, so you guard it like a password vault. Lock down who can read the bucket, encrypt it, and where the provider allows, keep secrets out of state entirely with write-only arguments. The sensitive flag only hides values on screen; they're still in the file.
Full Explanation
Terraform state records resource attributes, which can include initial passwords, keys and tokens, and the sensitive flag does not prevent this: sensitive values are still written to state and plan files. The remediation therefore treats the backend as a secret store. For S3 this means server-side encryption, the backend's encrypt setting, bucket policies that limit read and write to the pipeline identity and a small break-glass group, versioning for recovery, and access logging. Going further, resources that offer write-only arguments, fed by ephemeral values, keep the secret out of state altogether. Marking variables and outputs sensitive only redacts CLI and UI display; the plaintext remains in the state object. Moving to a local backend committed to Git spreads plaintext secrets into every clone and history, the opposite of containment. Removing the database resources from state stops Terraform from managing them and does not touch secrets in older state versions. Exam caveat: secrets already exposed must be rotated, because tightening access does not undo past reads, and prior object versions still contain them. Operational check: confirm bucket encryption and the restrictive policy, attempt a read as an ordinary engineer and expect access denied, then rotate the passwords.