EX294 Manage task execution and roles Practice Question
An Ansible playbook fails intermittently due to a service not starting in time. The administrator wants to configure a task to retry until the service confirms it is running. Which Ansible feature should be used?
⚠ Common exam trap
EX294 often tests the difference between retry mechanisms ('until' with retries/delay) and error-handling constructs ('block'/'rescue', 'failed_when'), so candidates who pick a recovery construct instead of a polling loop get it wrong.
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
✓
Until loop with retries and delay.
The 'until' loop in Ansible repeatedly retries a task until a specified condition evaluates to true, and it can be combined with 'retries' and 'delay' to control how many attempts are made and how long to wait between them. This is the idiomatic way to handle a service that takes time to start, such as waiting for a port to open or a status command to succeed. It directly addresses intermittent timing failures without failing the playbook prematurely.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Until loop with retries and delay.
Why this is correct
An until loop with retries and delay repeatedly runs the task until its condition evaluates true, pausing between attempts. This directly satisfies the intermittent-startup constraint: the service check is re-evaluated after each delay, so transient timing failures no longer abort the playbook.
- ✗
Failed_when with conditional retry.
Why it's wrong here
Failed_when only overrides the failure condition; it neither repeats the task nor waits for the service. Retrying until a condition is met requires until with retries and delay, which loops the task until the service reports running. Failed_when is for redefining success, such as tolerating a specific non-zero exit code.
- ✗
Block and rescue to catch failure.
Why it's wrong here
Block and rescue handles a task's failure by running recovery tasks; it does not repeat the original task until a condition succeeds. It is tempting because rescue catches the intermittent failure, but the requirement is conditional repetition until the service reports running, which block/rescue cannot express.
- ✗
Async with poll interval.
Why it's wrong here
Async with poll interval launches a task in the background and polls for completion; it does not re-run a failed task conditionally. It is tempting because polling resembles waiting for a service, but retrying until a condition holds is the until/retries loop, which async does not provide.
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.