Manage inventories and credentials →mediumMultiple Select

EX294 Manage inventories and credentials Practice Question

You must store a database password that a playbook will use on managed nodes. Your security policy forbids clear-text secrets in the repository and requires that the secret remain usable with `ansible-playbook --vault-password-file /home/devops/.vault_pass`. Which two actions satisfy the policy? (Choose two.)

⚠ Common exam trap

The trap here is treating .gitignore or environment-variable lookups as secret protection, when both leave the value readable in clear text.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create the secret with `ansible-vault encrypt_string --vault-password-file /home/devops/.vault_pass --name db_password` and paste the resulting block into the vars file.

Both accepted approaches produce artifacts encrypted with the same vault password that the required --vault-password-file supplies. Inline encryption with encrypt_string hides a single value inside an otherwise readable vars file, while encrypting an entire vars file protects a group of secrets referenced through vars_files. Each keeps clear-text secrets out of the repository while remaining fully usable at run time.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Reference the password with `lookup('env', 'DB_PASSWORD')` so it is read from the environment at run time.
Why it's wrong here
An environment lookup merely relocates the clear-text secret to the shell or CI environment, where it can be inspected by other processes and captured in logs. It creates no encrypted artifact and has no relationship to the vault password file, so the security policy's requirement for protected storage remains unmet.
✓
Create the secret with `ansible-vault encrypt_string --vault-password-file /home/devops/.vault_pass --name db_password` and paste the resulting block into the vars file.
Why this is correct
encrypt_string produces an inline encrypted variable that can be embedded directly in a YAML vars file while leaving the rest of the file readable in version control. Because it is encrypted with the same vault password, the playbook decrypts it transparently when run with the matching --vault-password-file, satisfying both the no-clear-text rule and the operational requirement.
✗
Commit the password in a vars file and add the file path to a .gitignore entry in the repository root.
Why it's wrong here
A .gitignore entry only prevents an untracked file from being added to the repository; it does nothing to protect a secret already committed or shared outside Git. The password still sits in clear text on the control node and in any backup or archive of the project directory, which directly violates the stated policy against clear-text secrets.
✓
Store the password in a YAML file, run `ansible-vault encrypt db_vars.yml`, and reference it from the playbook with `vars_files`.
Why this is correct
Encrypting the whole vars file protects the secret at rest in the repository, and vars_files causes Ansible to decrypt the content at run time using the supplied vault password file. This is the canonical pattern for keeping a group of sensitive variables together, and it works seamlessly with the required --vault-password-file option.
✗
Define the password as an extra variable with `-e db_password=...` in the playbook invocation.
Why it's wrong here
Passing a secret with -e exposes it in clear text in the shell history, in process listings, and in any logged command output. It also keeps no protected artifact in the repository, so there is nothing for the vault password file to decrypt. Extra variables cannot satisfy a policy that requires secrets to be stored encrypted.

Go deeper

EX294 Manage inventories and credentials Practice Question

Why each option matters

Option-by-option breakdown

Related to this question