· about 40 minutes · runs on ubuntu-26.04-devops · unrated
An unrated lab. It runs on your machine with no account and no network, and everything about it — the faults, the checks, the hints and the reference solution — is in the repository. An attempt on it is recorded on your profile and never moves a rating: only rated labs do. Rated and unrated labs.
deploy.service runs the playbook in /srv/deploy at every boot, as the deploy account. It
renders the application's database settings into /srv/app/config/db.conf. The database password
lives in the Ansible Vault file group_vars/app/vault.yml.
Since last week, the application starts with no database settings: the service fails at every boot. Someone "fixed" it by hand on another machine and ran the playbook from their own terminal, where Ansible asked them for the vault password. While debugging they also saved a decrypted copy of the vault file next to it, to read it.
The vault password is in /root/vault-password.txt. Keep using it.
What is expected, and graded:
deploy.service succeeds at boot, with nobody logged in, and /srv/app/config/db.conf holds the
password from the vault./srv/deploy contains the database password in plain text.deploy account can read.You have root through sudo. Everything must still hold after a reboot.
The machine is checked, rebooted, and checked again. A check passes only if it passes both times.
| Check | Objective |
|---|---|
| 01_deploy_runs_unattended | Run a playbook that uses Ansible Vault without a person at the keyboard |
| 02_secrets_encrypted_at_rest | Keep secrets encrypted at rest and the vault password readable only by the account that needs it |
| 03_vault_password_file_protected | Keep secrets encrypted at rest and the vault password readable only by the account that needs it |
| 04_no_secret_in_the_log | Keep secrets out of logs |
Where the lab's hints send you, level by level, as you ask for them (h, then l opens a journal section in the TUI).
4 questions on the same topic, in the lab's Theory tab. They never affect the lab's grade. Three of them, to answer here:
A playbook run from a systemd service fails with `EOFError (ctrl-d) on prompt`. Which `ansible.cfg` setting is the likely cause?
ask_vault_pass = true
ask_vault_pass makes every run prompt for the vault password. A service has no terminal, so the prompt reads end-of-file. vault_password_file is the unattended alternative.
https://docs.ansible.com/ansible/latest/vault_guide/vault_using_encrypted_content.html
A file named by `vault_password_file` has mode 0755. What does Ansible do with it?
Runs it as a program and uses its output as the vault password
An executable password file is treated as a script — the hook for password managers and secret stores. A plain password file should be mode 0400 or 0600, owned by the account that runs Ansible.
https://docs.ansible.com/ansible/latest/vault_guide/vault_managing_passwords.html
Which files in `group_vars/app/` does Ansible load as variables?
Files ending in .yml, .yaml or .json, or with no extension
Files with other extensions, such as vault.yml.plain or vault.yml.bak, are ignored by Ansible — and are still ordinary files that anyone with read permission can open, which is why a decrypted copy left there is a leak even though no playbook uses it.
https://docs.ansible.com/ansible/latest/inventory_guide/intro_inventory.html#organizing-host-and-group-variables · https://docs.ansible.com/ansible/latest/reference_appendices/config.html#yaml-filename-extensions