Secrets and Vault Management — the way you protect passwords, API keys, and private data when automating IT tasks with Ansible. This matters for EX294 because the exam expects you to know how to encrypt sensitive files so that even if someone accesses your automation code, they cannot read your passwords.
Jump to a section
A simple way to picture Secrets and Vault Management
Do you keep the front door key to your house tucked under the doormat, where anyone who passes by could grab it?
Think about sharing a house with several housemates. You all need access to the Netflix password, the Wi-Fi code, and the building's main door key fob. You could write these on a sticky note and leave it on the kitchen counter. That's convenient, but any visitor, delivery person, or stranger who walks through could snap a photo. One day, a visitor uses the Wi-Fi code to access your shared cloud drive and steals your tax documents. Disaster.
Instead, your house uses a lockbox mounted by the front door. The lockbox itself is secured with a single master code that only your housemates know. Inside the lockbox, you store the Netflix password, the Wi-Fi code, and the building key fob. Now, when a new housemate moves in, you give them the master lockbox code, not the individual secrets themselves. If someone moves out, you don't have to change the Netflix password or get a new building key — you just change the master lockbox code. The secrets stay encrypted and protected behind that one secure point of entry. This is exactly what Ansible Vault does: it provides a single, secure lockbox (the encrypted vault file) that holds all your sensitive passwords and keys, and you only manage the one master password that unlocks it.
When you write Ansible playbooks, you often need to include sensitive pieces of information. This could be a password to connect to a database, an API key to authenticate with a cloud service like Amazon Web Services, or a private SSH key to log into a remote server. If you were to write this sensitive data directly into a plain-text file, anyone who could view that file — a colleague, a version control system like Git, or an attacker who gains access to your folder — would immediately see your secrets. That would be insecure and potentially catastrophic for your organisation.
Ansible Vault solves this problem. It is a built-in feature of Ansible that allows you to encrypt entire files or individual variables so that they become unreadable gibberish to anyone who does not have the correct password. The encrypted data is called "vault-encrypted" text. When you run your playbook, Ansible automatically decrypts the data in memory, uses it to perform the task (like logging into a server), and then discards the decrypted content once the task is finished. The plain-text secret never touches the disk.
Let's break down the key technical terms. "Encryption" is the process of converting readable data (plain-text) into an unreadable format (cipher-text) using a specific algorithm and a secret key. "Decryption" is the reverse process — turning the cipher-text back into plain-text using the same secret key. The secret key you use for Ansible Vault is a password or a key file that you must keep safe. If you lose it, you cannot decrypt your vaulted files, and all your encrypted data becomes permanently lost.
You can use Ansible Vault in two main ways:
Encrypting entire files: You create a YAML file (a human-readable data format used in Ansible) containing variables like db_password: super_secret_123, and then you run a command to encrypt the whole file. The file's contents are replaced with an encrypted block.
Encrypting individual variables: You can mark a single variable inside an otherwise unencrypted playbook as "vault-encrypted". For example, db_password: !vault | $ANSIBLE_VAULT;... This allows you to keep your playbook structure readable while protecting only the sensitive values.
Why does this exist? Before Ansible Vault, IT professionals had to rely on external secrets management tools like HashiCorp Vault or CyberArk, or they had to manually password-protect files using tools like GPG (GNU Privacy Guard). These solutions worked but added complexity, requiring additional software, setup, and maintenance. Ansible Vault is built directly into Ansible, so you do not need any extra tools. It replaces the old habit of storing plain-text passwords in playbooks or configuration files, which was a massive security risk.
How it works in practice: You create a file called vault.yml with your secrets. You encrypt it with the command ansible-vault encrypt vault.yml. The system prompts you for a password. After encryption, the file looks like random characters. When you run your playbook, you provide the vault password either by typing it with the --ask-vault-pass flag or by pointing to a password file with --vault-password-file. Ansible then decrypts the data in memory only, uses the values, and discards them. This means the secret is never written to disk in plain-text.
Ansible Vault also supports multiple vault passwords. You can have different passwords for different files or groups of secrets. For example, you might use one vault password for development secrets and another for production secrets. This provides an additional layer of security through segregation.
Create a Vault Password File
Instead of typing your vault password every time, create a plain-text file (e.g., 'vault-pass.txt') that contains only the vault password on the first line. Save it with restricted permissions using `chmod 600 vault-pass.txt` so only you can read it. This file will be used to automatically provide the password to Ansible commands.
Encrypt an Existing Variable File
Take your plain-text secrets file (e.g., 'secrets.yml' which contains `db_password: mysecret`) and run `ansible-vault encrypt secrets.yml`. You will be prompted for a vault password or you can provide the password file with `--vault-password-file vault-pass.txt`. After this, 'secrets.yml' becomes unreadable gibberish to anyone without the password.
Reference the Encrypted File in Your Playbook
In your main playbook, add `vars_files:` followed by the path to your encrypted file. For example: `vars_files: - secrets.yml`. When the playbook runs, Ansible will automatically decrypt this file in memory using the vault password you provide, and the variables inside (like `db_password`) will be available for use.
Run the Playbook with the Vault Password
Execute the playbook with either `--ask-vault-pass` (to type the password interactively) or `--vault-password-file vault-pass.txt` (to use the password file). Ansible decrypts the vault data only in memory, performs the tasks, and then discards the decrypted data.
Edit the Encrypted File Safely
Never manually edit the encrypted file because you could corrupt the encryption header. Instead, use `ansible-vault edit secrets.yml`. This command decrypts the file, opens it in your default text editor (e.g., vi), waits for you to make changes and save, then re-encrypts the file automatically. Your plain-text edits are never left on disk.
Change the Vault Password (Rekey)
If you need to rotate the vault password (e.g., after a team member leaves), use `ansible-vault rekey secrets.yml`. You will be prompted for the old password and then the new one. This changes only the encryption key, not the secrets themselves.
Decrypt a File for a One-Time Task
If you absolutely need the secrets in plain-text (for debugging or migration), use `ansible-vault decrypt secrets.yml`. Be extremely cautious: this permanently converts the file back to plain-text. Always re-encrypt it afterward with `ansible-vault encrypt secrets.yml`.
Imagine you are an IT professional working for a mid-sized e-commerce company called ShopFast. The company uses Ansible to automate the configuration of its web servers, application servers, and databases. You need to write a playbook that connects to the production database to run a schema migration. The database credentials — username, password, and host — are sensitive. If these credentials were exposed, an attacker could drop the entire product catalogue.
Here is what you would actually do:
1. Create a vault file: You create a file named prod_db_vault.yml with the following content:
db_user: shopfast_admin
db_password: My!Secure!Pass123
db_host: prod-db-01.shopfast.internal
Encrypt the file: Open your terminal and run ansible-vault encrypt prod_db_vault.yml. The tool asks you to enter a new vault password (e.g., VaultMaster2024!). You confirm it. The file is now encrypted and looks like a messy block of data starting with $ANSIBLE_VAULT;...
Store the vault password securely: You cannot just write the vault password on a sticky note. Your team uses a shared password manager like Bitwarden or 1Password to store the vault password. Only the DevOps team members who need to run production playbooks have access to this password.
4. Reference the vault file in your playbook: In your playbook db_migration.yml, you add a line like `vars_files:
- prod_db_vault.yml`. This tells Ansible to load the variables from that encrypted file.
Run the playbook: You execute ansible-playbook db_migration.yml --ask-vault-pass. Ansible prompts you for the vault password. You type VaultMaster2024!. Ansible decrypts the vault file in memory, reads the db_user, db_password, and db_host variables, uses them to connect to the database, runs the migration, and then discards the decrypted data.
Rotate the credentials: Six months later, the company policy requires changing the database password. You update prod_db_vault.yml with the new password in plain-text, then re-encrypt it with ansible-vault encrypt prod_db_vault.yml. You also update the database server itself. The playbook starts using the new password immediately.
Share with a colleague: A new DevOps engineer joins your team. You give them access to the vault password via the password manager. They can now decrypt and view the vault file using ansible-vault view prod_db_vault.yml if needed, but the file in version control remains encrypted and safe.
This scenario demonstrates that an IT professional uses Ansible Vault not as an academic exercise but as a daily, practical tool to protect sensitive data while enabling automation. Without this, you would either have to hard-code passwords in playbooks (a serious security risk) or rely on a separate secrets management server that adds complexity and a single point of failure.
The EX294 exam tests your ability to create, encrypt, decrypt, view, edit, and rekey Ansible Vault files. You need to know the exact command syntax and understand how to use vault passwords in playbook execution.
Specific exam topics you must master:
Creating a new vault-encrypted file: ansible-vault create filename.yml. This opens a text editor (usually vi or vim) where you enter your variables. When you save and exit, the file is automatically encrypted.
Encrypting an existing unencrypted file: ansible-vault encrypt filename.yml. This takes a plain-text file and encrypts it in place.
Decrypting a vault file back to plain-text: ansible-vault decrypt filename.yml. This removes the encryption. You should know this but remember that decrypting permanently exposes the data.
Viewing the contents of an encrypted file without editing: ansible-vault view filename.yml. This decrypts the file to memory, displays it on screen, and does not write the decrypted content to disk.
Editing an already encrypted file: ansible-vault edit filename.yml. This decrypts the file, opens it in an editor, and re-encrypts it upon saving.
Changing the vault password on an existing encrypted file: ansible-vault rekey filename.yml. This prompts you for the old password and then for a new one. It does not change the secrets, only the vault encryption password.
Running a playbook with vault-encrypted data using --ask-vault-pass to be prompted interactively.
Running a playbook with a vault password file using --vault-password-file /path/to/passwordfile. The password file must contain the vault password as its first line, with no extra whitespace.
Common traps the exam sets:
Confusing ansible-vault encrypt with ansible-vault create. Remember: encrypt works on an existing file; create makes a new encrypted file in one step.
Forgetting that ansible-vault decrypt permanently exposes the secrets. The exam might ask which command to use to view secrets without leaving a decrypted copy — the answer is ansible-vault view.
Thinking you can run a playbook with a vault file without providing the password. Ansible will fail with an error like "A vault password must be specified" if you do not use --ask-vault-pass or --vault-password-file.
Mishandling vault password files: the file must have the password on the first line and nothing else. The exam may present a password file with extra blank lines or a second line containing a comment, which will cause decryption to fail.
Key definitions to memorise:
Vault ID: An optional label (like @prod or @dev) that allows you to use multiple vault passwords in the same playbook. The exam might test the syntax: ansible-vault encrypt --vault-id prod@passwordfile secret.yml.
Password file: A plain-text file containing the vault password. It must be kept as secure as the vault itself, often with restricted file permissions (e.g., chmod 600 so only the owner can read it).
Ansible Vault is not a substitute for role-based access control (RBAC) on the file system. It only protects the content of the file from being read by people who do not have the vault password. Anyone who can execute ansible-vault decrypt with the correct password can read everything.
Use ansible-vault encrypt to protect an existing plain-text file by encrypting it in place.
Use ansible-vault create to generate a new encrypted file directly without ever writing plain-text to disk.
Use ansible-vault view to inspect the contents of an encrypted file without creating a decrypted copy.
Use ansible-vault rekey to change the vault password on an already encrypted file without touching the secrets inside.
Always provide the vault password when running a playbook that uses vaulted data by using --ask-vault-pass or --vault-password-file.
If you lose the vault password, your encrypted data is gone forever — there is no recovery mechanism.
You can encrypt individual variables in a playbook using the !vault tag instead of encrypting the entire file.
Vault IDs allow you to use different passwords for different environments (e.g., dev vs prod) in the same playbook.
These come up on the exam all the time. Here's how to tell them apart.
ansible-vault encrypt
Takes an existing plain-text file as input
Encrypts the file in place, overwriting the original
Requires you to have already written the plain-text file to disk
ansible-vault create
Creates a brand new encrypted file from scratch
Opens a text editor immediately; you never write plain-text to disk
More secure because plain-text is never stored unencrypted on disk
ansible-vault view
Shows the decrypted content in the terminal
Does not write decrypted data to any file on disk
Safe for quick inspection without risk of exposing plain-text long-term
ansible-vault decrypt
Converts the encrypted file back to plain-text permanently
Creates a new plain-text file (overwrites the encrypted version)
Risky — leaves plain-text secrets on disk, which must be re-encrypted later
Single vault password
One password for all vault-encrypted data
Simpler to manage for small projects
All files are encrypted with the same key — if it leaks, all secrets are exposed
Multiple vault IDs
Different passwords for different environments (e.g., @dev, @prod)
More secure by limiting exposure of production secrets
Requires careful organisation and multiple --vault-id flags when running playbooks
Encrypting a whole file
The entire file becomes unreadable until decrypted
You must reference the file in vars_files
Simpler to manage if most of the file is sensitive
Encrypting a single variable
Only the specific variable value is encrypted; the file remains mostly readable
Useful when you have a mix of sensitive and non-sensitive variables
More granular control but requires careful YAML formatting with !vault tag
Mistake
You can only encrypt entire files with Ansible Vault.
Correct
You can also encrypt individual variables within a playbook or variable file using the !vault tag. This allows you to keep most of your file readable while protecting only the sensitive values.
Beginners often only see examples of whole-file encryption in tutorials and assume that is the only method. They may not realise that Ansible supports variable-level encryption, which offers more flexibility.
Mistake
Once a file is encrypted with Ansible Vault, you must always run ansible-vault edit to change it.
Correct
You can still edit the file with a regular text editor after decrypting it first with ansible-vault decrypt, then re-encrypt it with ansible-vault encrypt. However, ansible-vault edit is the safer workflow because it avoids leaving a decrypted file on disk.
Users may think the encryption is a permanent, irreversible operation on the file itself. They do not realise that decryption is reversible and that the file can be toggled between encrypted and plain-text states.
Mistake
If I lose the vault password for an encrypted file, I can recover the data using a backup or by asking Ansible support.
Correct
There is no backdoor. If you lose the vault password, the encrypted data is permanently unrecoverable. Ansible Vault uses strong encryption (AES-256) that cannot be broken without the password.
People are used to password recovery flows in websites and apps. They assume Ansible Vault has a similar 'forgot password' feature. It does not, and this assumption can lead to catastrophic data loss.
Mistake
Encrypting a file with Ansible Vault makes it impossible for anyone to see the data, even during playbook execution.
Correct
The decrypted data is available in memory while the playbook runs. If an attacker has root access to the control node while the playbook is executing, they could potentially capture the decrypted data from memory or process logs. Vault encryption protects data at rest, not during execution.
Beginners often think encryption is an absolute shield. They do not understand the concept of 'data at rest' vs 'data in use'. This misconception can lead to a false sense of security.
Mistake
Ansible Vault passwords must be complex, alphanumeric strings with special characters.
Correct
The vault password can be any string, including a long sentence or a passphrase. Security strength comes from length and unpredictability, not from complexity rules. A 30-character sentence is often more secure than a 10-character random string.
People carry over password complexity requirements from corporate IT policies into Ansible Vault. They waste time trying to generate 'special character' requirements when a memorable phrase would work better.
Mistake
You can only use one vault password for all your Ansible Vault files in a single playbook run.
Correct
You can use multiple vault passwords via Vault IDs. Each encrypted file or variable can be associated with a different Vault ID (e.g., @dev, @prod), and you can provide multiple --vault-id options when running a playbook.
Many introductory examples use a single password. Beginners may not realise that Ansible supports multiple vault passwords, which is a critical feature for separating environments or teams.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
`encrypt` takes an existing plain-text file and encrypts it. `create` makes a new file that is encrypted from the start — you never write the plain-text to disk.
Your encrypted data is permanently unrecoverable. There is no password reset feature. Always store the vault password in a secure password manager or a password file with restricted permissions.
Yes. You can use the `!vault` tag in your YAML file to mark a specific variable as encrypted. For example: `password: !vault | $ANSIBLE_VAULT...`.
Create a password file (e.g., 'vault-pass.txt' containing only the password) and use the `--vault-password-file` option: `ansible-playbook playbook.yml --vault-password-file vault-pass.txt`.
Yes. Ansible Vault uses AES-256 encryption, which is an industry-standard strong cipher. However, security depends on protecting the vault password itself — if someone gets your vault password, they have access to all secrets.
Yes, by using Vault IDs. You can label encrypted files with identifiers like `@dev` or `@prod` and provide multiple `--vault-id` options when running the playbook.
It is a plain-text file where the vault password must be the first line, with no extra spaces, newlines, or comments after it. For example: `MyVaultPassword` followed by a newline.
You've finished Secrets and Vault Management. Continue through the EX294 study guide to build a complete picture of the exam.
Done with this chapter?