Ansible Vault is the built-in encryption system that allows sensitive data — passwords, API keys, private keys, connection strings — to be stored directly in the Ansible repository in an encrypted form. Unlike Terraform, where the primary guidance is to avoid storing secrets in the configuration at all (using SSM or Secrets Manager ARNs instead), Ansible's architecture frequently requires secrets to be available at playbook execution time for tasks like configuring database passwords in application config files, setting up service accounts, and deploying SSL private keys. Vault bridges this requirement with security by encrypting the secrets with AES-256-GCM using a password or key file that is never committed to version control. The encrypted ciphertext can be safely committed to Git — only someone with the vault password can decrypt it.
Ansible Vault supports three encryption granularities: entire files (encrypt a whole vars file or any file containing sensitive content), individual strings (encrypt just one variable's value within an otherwise-plaintext vars file), and variables mixed throughout playbooks (via the '!vault' YAML tag). Each approach has different tradeoffs for readability, diff clarity and team workflow. The individual string approach ('ansible-vault encrypt_string') produces a YAML-embeddable encrypted blob that allows the variable name and file structure to remain visible in Git diffs while only the value is encrypted — this is the recommended approach for most teams because it enables meaningful code review without exposing secrets. Multiple vault passwords (vault IDs) allow different secrets to be encrypted with different passwords — production secrets with the production vault password, staging secrets with the staging vault password — enabling role-based access where not everyone needs the production vault password.