EX294 Manage automation security and operations Practice Question
An automation engineer stores a sudo password inside a project variable file that is committed to Git. The team requires that the cleartext value never appears in the repository and that playbooks still consume the variable transparently. Which approach meets this requirement?
⚠ Common exam trap
The trap here is assuming that .gitignore or environment variables provide equivalent protection to Ansible Vault, when only vault encryption keeps the secret usable by Ansible while remaining unreadable in the repository.
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
✓
Encrypt the variable file with ansible-vault encrypt and reference it from the playbook with vars_files; commit the encrypted file to Git.
Ansible Vault encrypts files and individual values using AES-256 so that secrets can be safely stored in source control. Encrypting the whole variable file with ansible-vault encrypt and loading it through vars_files keeps the plaintext out of Git while playbooks still resolve the variable normally. Decryption happens at runtime using a vault password provided interactively or through a password file.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Encrypt the variable file with ansible-vault encrypt and reference it from the playbook with vars_files; commit the encrypted file to Git.
Why this is correct
Encrypting the variable file with ansible-vault encrypt keeps the plaintext password out of the Git repository while the playbook still loads the variables through vars_files at runtime, prompting for or receiving the vault password via --vault-password-file or --ask-vault-pass. This satisfies both the storage requirement and transparent consumption.
- ✗
Run ansible-vault encrypt_string on the variable and store the resulting inline value directly in group_vars/all.yml.
Why it's wrong here
While encrypt_string produces an encrypted inline value suitable for a YAML variable, using it in group_vars/all.yml still means the encrypted blob is committed, which is acceptable, but the stem asks for an approach that keeps the cleartext out of Git while playbooks consume the variable transparently. This option is not wrong per se but does not match the intended file-level protection pattern in EX294 objectives.
- ✗
Add the variable file to .gitignore and distribute it manually to each control node's home directory before running the playbook.
Why it's wrong here
Adding the file to .gitignore prevents it from being committed but abandons version control and requires manual distribution, which is operationally fragile and does not scale. The question requires a supported Ansible mechanism that protects the value while keeping it in the repository, and manual file placement is neither automated nor auditable.
- ✗
Store the password in an environment variable on the control node and reference it with lookup('env', 'SUDO_PASS') inside the playbook.
Why it's wrong here
Environment variables on the control node are not encrypted, are visible to any process running as that user, and do not travel with the project. This exposes the secret outside the vault model and does not satisfy the requirement that the cleartext value never appear in the repository in a controllable, protected form managed by Ansible.
Visual reference
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
This EX294 question is part of Courseiva's 392-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Red Hat exam blueprint
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.