EX294 Implement advanced Ansible automation Practice Question
An administrator needs to securely store a database password used across multiple roles in a shared repository. Which approach is recommended?
⚠ Common exam trap
A common mix-up: candidates confuse 'secure storage in a repository' with external secrets managers (Option B), but the question explicitly limits the context to a shared repository, making ansible-vault the correct built-in solution.
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
✓
Use ansible-vault to encrypt the password string and store it in a file, then include_vars.
Ansible-vault encrypts sensitive data at rest using AES-256, and the encrypted file can be safely stored in a shared repository. The `include_vars` module then decrypts the file at runtime when the vault password is provided, allowing multiple roles to access the password without exposing it in plaintext.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use ansible-vault to encrypt the password string and store it in a file, then include_vars.
Why this is correct
ansible-vault encrypts the password string at rest, and include_vars loads the decrypted variable into playbooks at runtime, so multiple roles in the shared repository reference one protected secret. This satisfies secure storage without exposing plaintext credentials in version control.
- ✗
Use a lookup plugin to fetch from a secrets manager.
Why it's wrong here
A lookup plugin retrieves secrets at runtime from an external manager, but the shared repository then depends on that manager being reachable and configured for every user and node. It is tempting because it centralises rotation, yet it suits organisations already running such a manager, not self-contained repository storage.
- ✗
Store the password in an environment variable on the controller.
Why it's wrong here
An environment variable on the controller exists only on that host, so other users and execution nodes in the shared repository cannot access it, and it is not encrypted at rest. It is tempting for avoiding plaintext in files, but it suits single-machine CI injection, not shared, version-controlled secret storage.
- ✗
Hardcode the password in the playbook and use .gitignore.
Why it's wrong here
Hardcoding the password leaves it in plaintext in the repository's history, readable by anyone with clone access, and .gitignore only prevents future commits, not exposure. It is tempting for quick local runs, but committed secrets cannot be rotated safely, unlike Ansible Vault-encrypted variables.
Quick reference
Symmetric Encryption Algorithm Comparison
| Algorithm | Key Size | Block Size | Status | Notes |
|---|---|---|---|---|
| AES-128 | 128-bit | 128-bit | Current standard | NIST approved; WPA3, TLS |
| AES-256 | 256-bit | 128-bit | Current standard | Preferred for sensitive / govt data |
| 3DES | 112-bit effective | 64-bit | Deprecated (2023) | Replaced by AES |
| DES | 56-bit | 64-bit | Broken | Cracked in < 24 h; never deploy |
| ChaCha20 | 256-bit | Stream cipher | Current | TLS 1.3, WireGuard |
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX294 question from scratch — 392 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX294 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX294 exam.