🔐Module 07 — Secrets & Ansible Vault

Whole-file encryption — nothing is legible:

$ANSIBLE_VAULT;1.1;AES256
35646166326566373432653066363966613464393633613864343739383464643037313961363764
3234353361666232383735623564373135643163373339650a6234623463303433353862373635

Single-variable — structure stays visible:

---
db_host: db01.example.com
db_port: 5432
vault_db_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          66386439653236336462626566653063336164663966303231363934653561363964363833
          6431626536303530376336343832656537303632313433360a6262383463363533313861

Now change one value in each and look at git diff. The whole-file version shows every line as changed, because the ciphertext of the entire file differs. A reviewer sees only "vault.yml changed" and has no way to tell whether you rotated one password or replaced all of them.

The single-variable version shows exactly one variable's block changing, with db_host and db_port untouched and readable. A reviewer can see the shape of the change without ever seeing the secret.

When to choose which — the answer interviewers want: whole-file for a dedicated secrets file where everything in it is sensitive; encrypt_string when secrets are mixed into configuration that benefits from being reviewable. Many teams use both.

Symmetric AES256 encryption for files in your repository, so secrets can be committed to Git safely. It is built into Ansible with no infrastructure to run, and decryption is transparent at run time.

It protects against someone reading your repository. It does not protect against someone who can run your playbooks — they have the password. It offers no rotation, no audit log and no per-user access control, and secrets are plaintext in memory at run time and can leak into logs without no_log.

Whole-file for a dedicated secrets file where everything is sensitive; it is simpler and there is nothing to review anyway.

encrypt_string when secrets sit alongside ordinary configuration, because the rest of the file stays readable and git diff shows which secret changed without revealing it. Whole-file encryption makes every change look like the entire file was rewritten, so review is impossible.

Most mature repositories use both, choosing per file.

It writes plaintext to disk permanently, and the next git add -A commits the secret. Use view to read and edit to modify — both keep the file encrypted at rest.

decrypt exists for deliberately retiring a file from Vault, not for inspecting it.

Never in the repository. In a file in the user's home directory with 0600 permissions, referenced by vault_password_file in ansible.cfg — committing the path is fine, committing the file is a breach. Add the pattern to .gitignore as a second line of defence.

In CI it comes from the platform's secret store, written to a temporary file for the run. In AWX it is a Vault credential managed by the platform.

TASK [LEAKS - the argument is echoed] ******************************
ok: [localhost]

TASK [LEAKS - and so does the registered result] *******************
ok: [localhost] => {
    "r1.stdout": "connecting with SuperSecret123"
}

TASK [SAFE - no_log censors everything] ****************************
ok: [localhost] => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this task"}

With -vvv the count is high — the password appears in the constructed command line, in the module arguments, and in the result object, several times over.

Vault did its job perfectly here. The file on disk was encrypted, the value was decrypted correctly at run time — and then printed to standard output, into CI logs, into log aggregation, and into anyone's terminal scrollback.

The habit to build: no_log: true goes on any task that touches a secret, at the moment you write it. Adding it later means auditing every log you have ever produced. And note the third task shows nothing useful at all — that is the deliberate cost, and why you use no_log surgically rather than everywhere.

The indirection pattern: a readable vars.yml and an encrypted vault.yml in the same group_vars directory. vault.yml defines only vault_-prefixed variables; vars.yml maps them — db_password: "{{ vault_db_password }}".

Three benefits: reviewers can see which secrets exist without decrypting; playbooks reference db_password rather than vault_db_password, so the backing store can be swapped later without touching them; and grep vault_ enumerates every secret the project consumes, which is what a security review asks for.

Labelled vault passwords — --vault-id prod@~/.vault-prod — so different files can be encrypted with different passwords and Ansible matches each file to its label automatically.

The reason: one password for everything means anyone who can deploy to dev can decrypt production. Vault IDs give per-environment separation.

The source can be prompt, a file, or an executable script, and the script form is what scales — it can fetch the password from HashiCorp Vault or a CI secret store at run time, so no password file exists on disk.

Vault encrypts at rest, not at run time. The decrypted value can reach logs through task output, through the item echo on a loop over dictionaries, and through -vvv verbose output which prints full module arguments.

Fixes: no_log: true on any task handling secrets, loop_control: label: on loops over credential dictionaries, and never routinely running production playbooks at -vvv.

no_log also makes that task undebuggable, which is the deliberate trade.

ansible-vault rekey on every encrypted file, then distribute the new password through your secret store.

The uncomfortable part worth volunteering: rekeying does not protect history. Anyone who ever had the old password can decrypt any older commit. Genuine revocation means rotating the underlying secrets themselves — the database passwords and API tokens — not just the vault password.

That limitation is a large part of why teams move to a real secrets manager.

Without the textconv setting:

diff --git a/group_vars/prod/vault.yml b/group_vars/prod/vault.yml
index 8f3a2c1..b7e9d04 100644
Binary files differ

With it:

diff --git a/group_vars/prod/vault.yml b/group_vars/prod/vault.yml
--- a/group_vars/prod/vault.yml
+++ b/group_vars/prod/vault.yml
@@ -1,3 +1,3 @@
 ---
-vault_db_password: SuperSecret123
+vault_db_password: EvenBetterSecret456
 vault_api_token: tok_abc123

A reviewer can now see that exactly one secret rotated, rather than "the file changed somehow".

🚨 Understand precisely what you have done, and the limits. This decrypts locally, for anyone who already has the vault password — it does not weaken the repository, and the committed file is still ciphertext. But it means the plaintext is now rendered by git diff, git log -p and git show on your machine, so it can end up in a terminal recording, a screen share, or a pager's scrollback.

.gitattributes is committed and shared; the diff.ansible-vault.textconv config is local per-clone, so teammates must opt in themselves. That is deliberate — it should be a conscious choice, not something the repository turns on for you.

When you need rotation, an audit trail, per-user access control, or dynamic short-lived credentials — none of which Vault provides.

HashiCorp Vault for dynamic credentials and fine-grained policy; AWS Secrets Manager or SSM Parameter Store when you are already on AWS and want IAM control with CloudTrail auditing; SOPS when you want to keep secrets in Git but need reviewable diffs and KMS-based key management.

A useful middle step: keep Ansible Vault for the content, but fetch the vault password itself from a real secrets manager via a client script.

Rekeying the vault does not revoke their access to history — they can still decrypt any commit made while they had the password.

Real revocation means rotating the underlying secrets: the database passwords, the API tokens, the certificates. Then rekey the vault as hygiene.

This is one of the strongest practical arguments for a real secrets manager, where revoking a person's access is a policy change rather than a rotation of every credential they ever saw.

Lookups run on the control node, and a lookup inside a task that runs per host executes once per host — so a 200-host play makes 200 API calls to Secrets Manager, which is slow and may hit rate limits.

Fetch once with run_once: true plus delegate_to: localhost, set_fact the result, and read it from hostvars on the other hosts. With no_log: true throughout.

Either use encrypt_string so only the values are ciphertext and the file structure stays diffable, or configure a git textconv filter — git config diff.ansible-vault.textconv "ansible-vault view" with a .gitattributes entry — so git diff renders the plaintext locally for anyone who already has the password.

The caveat: the committed file is unchanged and still encrypted, but plaintext now appears in local git diff output, so it can reach a screen share or terminal recording. .gitattributes is shared; the textconv config is per-clone, so it stays an opt-in choice.

SOPS solves this properly by encrypting only values, leaving structure and keys visible by design.

inventories/
  production/group_vars/all/
    vars.yml       readable   -> db_password: "{{ vault_db_password }}"
    vault.yml      encrypted with the prod vault id
  staging/group_vars/all/
    vars.yml       readable
    vault.yml      encrypted with the staging vault id

# Requirement 1 - two identities, two passwords
echo 'prodpass'    > ~/.vault-prod    && chmod 600 ~/.vault-prod
echo 'stagingpass' > ~/.vault-staging && chmod 600 ~/.vault-staging

ansible-vault create --vault-id prod@~/.vault-prod \
  inventories/production/group_vars/all/vault.yml
ansible-vault create --vault-id staging@~/.vault-staging \
  inventories/staging/group_vars/all/vault.yml

# inventories/production/group_vars/all/vars.yml
# Requirements 2 and 3 - readable, shows WHAT exists, not the values
---
db_host: db01.prod.example.com
db_port: 5432
db_user: appuser
db_password: "{{ vault_db_password }}"
api_token: "{{ vault_api_token }}"

# ansible.cfg  -- requirement 5
[defaults]
vault_identity_list = prod@~/.vault-prod, staging@~/.vault-staging

# playbooks/site.yml  -- requirement 4
---
- hosts: all
  tasks:
    - name: Configure the database connection
      ansible.builtin.template:
        src: db.conf.j2
        dest: /etc/app/db.conf
        mode: "0640"
      no_log: true

    - name: Create application database users
      community.postgresql.postgresql_user:
        name: "{{ item.name }}"
        password: "{{ item.password }}"
      loop: "{{ db_users }}"
      loop_control:
        label: "{{ item.name }}"
      no_log: true

# .gitignore  -- requirement 6
.vault-*
*.vault-pass
.vault_pass*
*.pem
*.key

# Requirement 7 - prove no plaintext secret is committed
git grep -nE '(password|token|secret|api_key)\s*:\s*[^"{ ]' -- \
  ':!*vault.yml' ':!*.md' || echo "CLEAN - no plaintext secrets found"

The six decisions that matter:

1. vault_identity_list in ansible.cfg — requirement 5. Both identities are always available, Ansible matches each file to its label, and neither environment needs a flag.
2. group_vars/all/ as a *directory* containing both files — Module 02 Part C2. Ansible merges every file in the directory, which is exactly how the readable/encrypted split works.
3. Playbooks reference db_password, never vault_db_password — requirement 2. Swap to HashiCorp Vault later by editing one line in vars.yml.
4. no_log: true on both tasks, plus loop_control: label: — requirement 4. The label alone is not enough for the postgresql_user task, because the module arguments contain the password.
5. .vault-* in .gitignore matches the actual filenames chosen — a .gitignore full of patterns that match nothing is theatre.
6. The git grep in requirement 7 excludes vault.yml deliberately: those files are supposed to contain secrets, and they are ciphertext. What you are hunting for is a plaintext password that leaked into a readable file.

Verify:

ansible-playbook -i inventories/staging    playbooks/site.yml --list-tasks
ansible-playbook -i inventories/production playbooks/site.yml --check
ansible-vault view --vault-id prod@~/.vault-prod \
  inventories/production/group_vars/all/vault.yml
ansible-vault view --vault-id staging@~/.vault-staging \
  inventories/production/group_vars/all/vault.yml   # MUST fail - wrong password
git status --short                                  # no ~/.vault-* files

That second view failing is the proof that requirement 1 actually holds.

It protects against someone reading your repository — AES256 encryption at rest.

It does not protect against anyone who can run your playbooks, it has no rotation, no audit log and no per-user access control, secrets are plaintext in memory at run time, and rekeying does not stop old commits from being decryptable by anyone who ever had the password.

A readable vars.yml mapping db_password: "{{ vault_db_password }}", and an encrypted vault.yml defining only vault_-prefixed variables.

Benefits: reviewers see which secrets exist without decrypting; playbooks never reference vault_* so the backing store can be swapped by editing one line; and grep vault_ enumerates every secret the project consumes.

Only the value is ciphertext, so the file's structure and its non-secret keys stay readable and git diff shows exactly which secret changed. Whole-file encryption makes every change look like the entire file was rewritten.

Labelled passwords — --vault-id prod@~/.vault-prod — letting different files use different passwords with Ansible matching each file to its label.

Without them, one password decrypts everything, so anyone who can deploy to dev can read production secrets.

Task output echoing module arguments, the item echo on a loop over credential dictionaries, and -vvv printing full module arguments.

Fixes: no_log: true, loop_control: label:, and not routinely running production at high verbosity.

It appears in the process list, in shell history, and frequently in job logs. Write it to a 0600 temp file and use --vault-password-file, removing it in an after_script that runs even on failure — or use a client script so it is never written to disk at all.

An executable given as the vault-id source, which prints the password to stdout and exits 0. It can fetch the password from AWS Secrets Manager or HashiCorp Vault at run time, authenticated by the runner's IAM role — so no password file exists on disk and rotation happens in one place.

Rotate the underlying secrets — database passwords, API tokens, certificates. Rekeying the vault alone does not revoke access to history; they can still decrypt any commit made while they held the password.

Then rekey the vault as hygiene. This limitation is a primary argument for a real secrets manager, where revocation is a policy change.

When you need rotation, audit trails, per-user access or dynamic short-lived credentials. HashiCorp Vault for dynamic credentials and policy; AWS Secrets Manager or SSM if you are on AWS and want IAM control with CloudTrail; SOPS if you want to stay in Git but need diffable, KMS-managed encryption.

The pragmatic middle step: keep Vault for the content, fetch the vault password from a real secrets manager via a client script.

Lookups run on the control node and execute once per host, so a 200-host play makes 200 API calls — slow and liable to hit rate limits.

Fetch once with run_once: true and delegate_to: localhost, set_fact it, and read from hostvars elsewhere. With no_log: true throughout.

Behaviour verified against the current official Ansible Vault guide.

Question selection cross-referenced against publicly published 2026 Ansible interview question sets:

• Spacelift — 50+ Top Ansible Interview Questions & Answers for 2026
• GeeksforGeeks — Top 50+ Ansible Interview Questions and Answers
• Vinsys — Top 30 Ansible Interview Questions and Answers 2026
• K21 Academy — Ansible Interview Questions & Answers 2026
• Hirist — Top 25+ Ansible Interview Questions and Answers 2026

Answers were rewritten and deepened rather than reproduced — published versions are usually correct but shallow, and the added operational detail is what differentiates a candidate in the room.