EX294 Manage automation security and operations Practice Question
An automation team uses Ansible Automation Platform to manage secrets. They have a requirement that certain tasks must not log sensitive output to the Ansible logs. Which Ansible task keyword should be used to prevent a task from logging its output?
⚠ Common exam trap
Test-takers frequently confuse `no_log` with other task keywords that control behavior but do not affect logging, such as `become` or `ignore_errors`.
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
✓
`no_log: true`
The `no_log` keyword is specifically designed to prevent Ansible from logging a task's output. When set to `true`, it suppresses the output that would normally appear in logs, including any sensitive data. This is the recommended approach for tasks that handle passwords, API keys, or other secrets. The other keywords control privilege escalation, error handling, or dry-run mode, none of which address logging of sensitive information.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
`no_log: true`
Why this is correct
The `no_log` keyword, when set to `true` on a task, prevents Ansible from logging the task's output, including any sensitive data. This is the correct way to ensure that secrets are not exposed in logs. It can be applied at the task level or globally in `ansible.cfg` with `no_log = True`. This directly addresses the requirement to avoid logging sensitive output.
- ✗
`ignore_errors: true`
Why it's wrong here
`ignore_errors` allows a playbook to continue even if a task fails. It does not affect logging of task output. Sensitive data could still be logged if the task outputs it. This keyword is about error handling, not security. Therefore, it does not meet the requirement to prevent logging of sensitive information.
- ✗
`check_mode: true`
Why it's wrong here
`check_mode` runs a task in dry-run mode, showing what would change without making changes. It does not suppress logging of task output. In fact, check mode output can still contain sensitive data if the task displays variables. This keyword is for simulation, not for security. It is not the correct choice for preventing sensitive data from being logged.
- ✗
`become: true`
Why it's wrong here
`become` is used for privilege escalation, not for suppressing log output. It allows a task to run with elevated permissions, but it does not prevent the task's output from being logged. In fact, using `become` might increase the sensitivity of the output, making it more important to use `no_log`. This option is unrelated to the requirement.
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.