EX294 Manage automation security and operations Practice Question
An automation team must ensure that sensitive variables used in playbooks are protected both at rest and during job execution in Ansible Automation Platform. Which TWO actions should be taken? (Choose two.)
⚠ Common exam trap
The trap here is focusing only on encryption at rest and forgetting that job output can leak decrypted secrets unless no_log: true is applied to tasks handling sensitive data.
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
✓
Mark tasks that use sensitive variables with no_log: true to prevent values from appearing in job output.
Encrypting sensitive variables with Ansible Vault and supplying the vault password via a controller credential protects data at rest, while no_log: true prevents runtime exposure in job output. Plaintext group_vars, verbose logging, and repository-stored vault passwords all undermine security and fail to meet the dual protection requirement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store the vault password in the project repository as a plaintext file for easy access.
Why it's wrong here
Placing the vault password in the repository in plaintext defeats the purpose of vault encryption. Anyone with repository access could decrypt the sensitive variables. The vault password must be stored securely, such as in a controller credential or a protected file outside the repository.
- ✓
Mark tasks that use sensitive variables with no_log: true to prevent values from appearing in job output.
Why this is correct
The no_log: true directive suppresses task output, preventing expanded sensitive variables from being displayed in job logs. While it does not protect data at rest, it addresses runtime exposure in job output, complementing vault encryption for a complete protection strategy.
- ✗
Define sensitive variables in group_vars/all in plaintext so they are available to all hosts.
Why it's wrong here
Storing sensitive variables in plaintext in group_vars/all leaves them readable in the repository and at rest, violating the requirement for at-rest protection. This approach makes secrets broadly available and is a security anti-pattern, not a protective measure.
- ✗
Enable verbose logging with -vvv to capture all variable values for auditing.
Why it's wrong here
Increasing verbosity with -vvv causes Ansible to print more task details, including variable values, which increases the risk of exposing secrets in job output. Verbose logging is useful for troubleshooting but directly conflicts with the goal of protecting sensitive data during execution.
- ✓
Store sensitive variables in an Ansible Vault-encrypted file and provide the vault password through a controller credential.
Why this is correct
Using an Ansible Vault-encrypted file protects variables at rest, and supplying the vault password via a controller credential keeps the decryption secret encrypted in the controller database and out of playbooks. This combination satisfies both at-rest and runtime protection for sensitive variables.
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.