Security & Secrets Management

Let's think about it this way for a second

Hardcoding a password in a Terraform config leaks it the moment it's committed to a git repository — marking a variable `sensitive = true` makes Terraform hide the value in plan/apply output (it's still in the state file though, so state encryption/access control needs to be considered separately). Credentials (like an AWS access key) shouldn't be written directly into the config — set things up so the provider auto-detects them from an environment variable (`AWS_ACCESS_KEY_ID`) or a credentials file (`~/.aws/credentials`). In production, secrets are sometimes pulled dynamically from Vault (HashiCorp Vault) or a cloud secret manager (AWS Secrets Manager).

Let's connect this to a real scenario

Define a database password as `variable "db_password" { type = string; sensitive = true }`, and pass its value through a `.tfvars` file (git-ignored) or an environment variable (`TF_VAR_db_password`) — `terraform plan` output will then show `db_password = (sensitive value)` instead of the real value. AWS credentials shouldn't be written directly into the config either — the provider auto-detects them from an `aws configure` command (or a CI/CD environment variable).

• A sensitive variable marked sensitive = true hides its value in output
• Read credentials from an environment variable/credential file instead of hardcoding them in the config
• In production, secrets are sometimes pulled dynamically from Vault/a cloud secret manager

Let's look at it together

variable "db_password" {
  description = "Database master password"
  type        = string
  sensitive   = true
}

resource "aws_db_instance" "main" {
  # ... other config ...
  password = var.db_password
}

# Set the value via environment variable, never in the .tf file:
# TF_VAR_db_password="..." terraform apply

$ terraform plan
  ~ resource "aws_db_instance" "main" {
      ~ password = (sensitive value)
    }