How do you manage secrets and sensitive values in Terraform?
Learn how to manage Terraform secrets: use a secrets manager, mark values sensitive, secure and encrypt state, and keep credentials out of version control.
Expected Interview Answer
You manage secrets in Terraform by keeping them out of code and state where possible, injecting them from a dedicated secrets manager or environment variables at runtime, marking variables and outputs as sensitive, and encrypting and locking down the state backend.
The key risk is that Terraform writes resolved values into its state file in plain text, so any secret Terraform touches can leak through state even if it never appears in the .tf files. Best practice is to pull secrets from systems like HashiCorp Vault, AWS Secrets Manager, or SSM Parameter Store via data sources at apply time, mark variables and outputs with sensitive = true so they are redacted from CLI output, store state in an encrypted remote backend with strict access control and locking, and never commit .tfvars containing secrets. Where feasible, let the cloud provider generate and hold the secret so Terraform only references it.
- Keeps plaintext secrets out of version control
- Limits exposure in CLI logs via redaction
- Centralizes rotation through a secrets manager
- Protects state with encryption and access control
- Reduces blast radius if code is leaked
AI Mentor Explanation
Managing secrets is like a team's confidential game plan: you never write it on the public scoreboard for the crowd to read. Instead it stays in the locked dressing room, shared only with players who need it, and even team talks avoid saying it aloud. Terraform does the same by pulling secrets from a vault and redacting them from any output spectators could see.
Step-by-Step Explanation
Step 1
Keep secrets out of code
Never hardcode credentials in .tf files or commit .tfvars containing secrets to version control.
Step 2
Source from a secrets manager
Fetch values at apply time from Vault, AWS Secrets Manager, or SSM using data sources, or inject via TF_VAR environment variables.
Step 3
Mark values sensitive
Set sensitive = true on variables and outputs so Terraform redacts them from plan and apply output.
Step 4
Secure the state backend
Use an encrypted remote backend with strict IAM access and state locking, since state stores secrets in plaintext.
Step 5
Prefer provider-generated secrets
Where possible, let the cloud provider generate and hold the secret so Terraform only references it, not its value.
What Interviewer Expects
- Awareness that state stores secrets in plaintext
- Using a dedicated secrets manager or env vars
- Marking variables and outputs as sensitive
- Encrypting and access-controlling the backend
- Not committing secrets to version control
Common Mistakes
- Believing sensitive = true encrypts or protects state
- Hardcoding secrets or committing .tfvars files
- Ignoring that outputs can leak secrets in logs
- Leaving the state backend unencrypted or world-readable
Best Answer (HR Friendly)
“You keep passwords and keys out of the Terraform code and out of version control, pulling them from a secure secrets store when needed and marking them as sensitive so they do not show up in logs. You also lock down and encrypt the state file, since Terraform records values there in plain text.”
Code Example
variable "db_password" {
type = string
sensitive = true
}
output "connection_string" {
value = "postgres://admin:${var.db_password}@db.internal:5432"
sensitive = true
}data "aws_secretsmanager_secret_version" "db" {
secret_id = "prod/db/password"
}
resource "aws_db_instance" "main" {
username = "admin"
password = data.aws_secretsmanager_secret_version.db.secret_string
}Follow-up Questions
- Why does marking a variable sensitive not protect the state file?
- How would you integrate HashiCorp Vault with Terraform?
- What are the risks of storing secrets in outputs?
- How do you secure a remote state backend?
- When should you let the cloud provider generate a secret instead of Terraform?
MCQ Practice
1. Where do secrets Terraform uses end up stored in plaintext?
Terraform records resolved attribute values, including secrets, in the state file as plaintext, which is why the backend must be secured.
2. What does sensitive = true actually do?
sensitive = true only suppresses the value in plan and apply output; it does not encrypt or remove it from state.
3. Which is the best practice for supplying database credentials?
Sourcing secrets from a manager like Vault or AWS Secrets Manager keeps them out of code and centralizes control and rotation.
Flash Cards
Where do Terraform secrets leak most easily? — The state file, which stores resolved values in plaintext.
What does sensitive = true do? — Redacts the value from CLI plan and apply output; it does not encrypt state.
Preferred source for secrets? — A dedicated secrets manager (Vault, AWS Secrets Manager, SSM) fetched at apply time, or TF_VAR env vars.
How to protect state? — Use an encrypted remote backend with strict access control and locking.
Continue Learning
Related Interview Questions
What is Terraform and what problem does infrastructure as code solve?
easy
What is the difference between Terraform and configuration tools like Ansible?
medium
What is declarative vs imperative infrastructure and where does Terraform fit?
medium
What are input variables, output values, and locals in Terraform?
medium