In an Ansible repository, when would you encrypt an entire vars file with ansible-vault versus using ansible-vault encrypt_string for individual values?

## Two packagings of the same cipher Ansible Vault encrypts at two granularities. `ansible-vault encrypt secrets.yml` turns a whole file into one blob. `ansible-vault encrypt_string` encrypts a single scalar and prints a YAML fragment you paste into an otherwise plaintext file, tagged so the parser knows to decrypt it: ```yaml db_host: db-prod-01.internal db_user: app db_password: !vault | $ANSIBLE_VAULT;1.1;AES256 62313365396662343061393464336163383437343266333962... ``` The cipher, the header and the password are identical in both cases. Anywhere Ansible loads variables — `group_vars`, `host_vars`, a `vars_files` entry, role `defaults` — either form works, and Ansible decrypts lazily when it reads the file. ## What whole-file encryption costs you The cost is code review, and it is bigger than it sounds. Because the payload is salted, re-encrypting identical content produces completely different ciphertext, so a diff on an encrypted file is always a full-blob replacement. A reviewer approving a pull request that touches `group_vars/prod/vault.yml` learns exactly one thing: it changed. They cannot see whether you rotated one API token or accidentally deleted four unrelated variables, and merge conflicts on that file cannot be resolved by hand at all — you have to decrypt both sides, merge, and re-encrypt. That matters least when the file contains nothing but secrets, which is why the dominant convention is a dedicated `vault.yml` per environment holding only encrypted values, and never a mixed file where a hostname change is indistinguishable from a credential change. ## What inline strings cost you Inline strings fix reviewability at the cost of manageability. Each one is ten-odd lines of hex embedded in your data structure, so a file with a dozen secrets becomes unreadable for a different reason. More importantly, `ansible-vault rekey` works on encrypted **files** — it will not walk a plaintext YAML file re-encrypting the `!vault` scalars inside it. Rotating the vault password across a repository full of inline strings means finding and regenerating every one of them with `encrypt_string` under the new password. Inline strings also break the trick of simply not loading the encrypted file when you do not need the secret, since the surrounding file is always loaded. Generating one looks like this: ```bash ansible-vault encrypt_string --vault-id prod@prompt \ 'correct-horse-battery-staple' --name 'db_password' ``` Read the value from stdin rather than passing it as an argument when you care about shell history and the process table. ## The pattern most teams land on The widely used compromise is indirection. Keep two files per environment: a plaintext one that a reviewer can read, and an encrypted one that holds the raw values under prefixed names. ```yaml # group_vars/prod/vars.yml (plaintext, reviewable) db_host: db-prod-01.internal db_password: "{{ vault_db_password }}" # group_vars/prod/vault.yml (fully encrypted) vault_db_password: correct-horse-battery-staple ``` This gives you the best of both: the plaintext file documents which variables exist and where each one comes from, so a review of "we now pass a password to the app" is meaningful; the encrypted file is a single blob that `rekey` can rotate in one command; and the `vault_` prefix makes it obvious at a glance which values are sensitive and greppable in templates. The tradeoff is one extra layer of naming, and a failure mode where the plaintext file references a `vault_` variable the encrypted file no longer defines — an undefined-variable error at run time rather than at review time. ## Choosing in an interview Say the decision rule out loud: whole-file when the file is all secrets and you want cheap rotation and a clean rekey story; inline strings when one secret has to live inside a mostly public structure — a single token in a role's `defaults/main.yml`, or a value in an inventory file you want to stay readable. Then mention that at any real scale you use the indirection pattern so review stays possible, and that neither form changes the underlying security properties: same password, same cipher, same lack of per-user access control.