EX294 Manage automation security and operations Practice Question
You are reviewing an Ansible playbook that uses the `ansible.builtin.shell` module to run a command that includes a sensitive API key as an argument. You want to prevent the API key from being displayed in the job output. Which task-level directive should you add?
⚠ Common exam trap
The trap here is assuming that other task directives like `become` or `ignore_errors` might hide output, when only `no_log` controls logging.
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: true` directive on a task suppresses all logging for that task, including the command line and its output. This prevents the sensitive API key from appearing in job output. The other directives control privilege escalation, error handling, or change reporting, none of which affect logging of task details. Therefore, `no_log` is the correct choice.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
changed_when: false
Why it's wrong here
`changed_when: false` overrides the task's changed status, which is useful for idempotency but does not affect logging. The command and its arguments would still be logged. This directive does not hide sensitive data. Therefore, it is not the correct choice for preventing the API key from being displayed.
- ✓
no_log: true
Why this is correct
The `no_log` directive, when set to true on a task, prevents Ansible from logging the task's output, including the command and its arguments. This ensures that the sensitive API key passed to the shell module is not displayed in job output. It is the correct task-level control to suppress logging of sensitive data. It works regardless of the module used, as long as it is applied to the task.
- ✗
ignore_errors: true
Why it's wrong here
`ignore_errors: true` allows the playbook to continue even if the task fails. It has no effect on logging. The API key would still appear in the output. This directive is used for error handling, not for security. Thus, it does not prevent the sensitive data from being exposed.
- ✗
become: true
Why it's wrong here
`become: true` enables privilege escalation, which is unrelated to logging. It does not prevent the API key from being displayed. In fact, using `become` might still log the command and arguments. This directive is used for running tasks with elevated privileges, not for hiding sensitive data. Therefore, it does not address the requirement.
Go deeper
Related to this question
About these practice questions
One of 392 original EX294 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.