Courseiva

EX294 Manage task execution and roles Practice Question

A role's tasks/main.yml contains a task that uses `notify: restart service`. The handler is defined in handlers/main.yml. During a playbook run, the task reports 'changed' but the handler does not run until the end of the play. The administrator wants the handler to run immediately after the task, before any subsequent tasks. Which action should be taken?

⚠ Common exam trap

The trap here is thinking that handler options like run_once or force_handlers change when handlers execute, but only explicit flushing or play end triggers them.

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

✓

Add a task using meta: flush_handlers immediately after the notifying task.

Handlers by default execute at the end of the play after all tasks complete. To run them earlier, a meta: flush_handlers task must be inserted at the desired point. Other options either change failure behavior, batching, or definition location, none of which alter the execution timing of handlers.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Change the handler to use listen: restart service and set run_once: true.

    Why it's wrong here

    Adding listen and run_once does not change when handlers execute; they still run at the end of the play unless flushed. run_once controls host execution, not timing. This option does not make the handler run immediately after the notifying task, so it fails the requirement.

  • ✗

    Set force_handlers: true in the play and use serial: 1.

    Why it's wrong here

    force_handlers ensures handlers run even if a task fails, but it does not change their execution point from the end of the play. serial changes batching. Neither causes the handler to run immediately after the notifying task, so this option does not satisfy the scenario.

  • ✗

    Move the handler definition into the same tasks/main.yml file and rename it.

    Why it's wrong here

    Handler location or naming does not alter the default timing. Handlers always run at the end of the play unless flushed, regardless of where they are defined. Moving or renaming the handler does not make it run earlier, so this option is incorrect for the requirement.

  • ✓

    Add a task using meta: flush_handlers immediately after the notifying task.

    Why this is correct

    Handlers run at the end of each play by default, or when explicitly flushed. Inserting a meta: flush_handlers task right after the notifying task forces all pending handlers to execute at that point, before any later tasks. This fulfills the requirement to run the handler immediately after the task that notified it.

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 →

How Courseiva writes practice questions · Editorial policy

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.