EX294 Implement advanced Ansible automation Practice Question
A role contains a handler. The playbook includes the role and also defines a task that notifies the same handler. When the playbook runs, the handler executes only once. Which of the following best explains this behavior?
⚠ Common exam trap
Many exam-takers think handlers are executed immediately upon notification or that multiple notifications cause multiple executions, but Ansible deduplicates by handler name and runs them only once per play, regardless of the number of notifications.
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
✓
handlers are deduplicated by name; multiple notifications trigger the handler only once per play
Ansible handlers are deduplicated by name within a play. When a handler is notified multiple times—whether from a role or a playbook task—it runs only once at the end of the play, after all tasks have completed. This prevents redundant executions and is a core design feature of Ansible's handler system.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
the handler was already triggered by the role and is skipped for the play task
Why it's wrong here
Handlers are not marked as consumed after a role triggers them; Ansible deduplicates by running each notified handler once per play, regardless of how many tasks notify it. The 'already triggered' idea is tempting because it matches how one-shot flags behave in other tools, and would apply if handlers were stateful rather than queued by name.
- ✓
handlers are deduplicated by name; multiple notifications trigger the handler only once per play
Why this is correct
Handlers are deduplicated by name, so notifications from both the role and the playbook task resolve to the same handler. It runs once per play after all notifying tasks complete, regardless of how many tasks notified it.
- ✗
the role's handler uses 'listen' which overrides notifications
Why it's wrong here
The 'listen' directive adds extra notification topics to a handler; it does not override or suppress notifications sent to the handler's own name. It is tempting because 'listen' genuinely lets multiple handlers respond to one notify, and would be the correct explanation if the stem described several handlers firing from a single notification.
- ✗
the playbook's task notifies a different handler with the same name
Why it's wrong here
A task notifying a same-named handler in the play still resolves to the single handler definition; Ansible does not maintain two separate handlers sharing a name. Duplicate-name resolution is tempting because shadowing occurs with variables and roles, and would be correct if the play and role each defined distinct handlers with identical names.
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 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.