EX294 Coordinate rolling updates Practice Question
An administrator notices that during a rolling update, the playbook seems to hang after updating the first host. The playbook uses serial: 5. What is the most likely cause?
⚠ Common exam trap
Red Hat often tests the misconception that `serial` controls parallelism across all hosts (like `forks`), but the trap here is that `serial` batches hosts sequentially, so a single slow host in a batch blocks the entire batch from completing, causing the playbook to appear to hang.
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
✓
One of the hosts in the batch is taking too long to complete its tasks.
When `serial: 5` is set, Ansible processes hosts in batches of five. If one host in the batch takes an unusually long time to complete its tasks (e.g., due to a slow network, a hanging service restart, or a long-running command), the entire batch will appear to hang because Ansible waits for all hosts in the current batch to finish before proceeding to the next batch. This is the most likely cause of the observed behavior during a rolling update.
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 playbook has an infinite loop.
Why it's wrong here
An infinite loop would spin indefinitely on the first host, never completing it, whereas the stem says the first host finished updating. Loops are tempting because they are a classic cause of hung playbooks, but a loop that never terminates would prevent any host from being marked changed.
- ✓
One of the hosts in the batch is taking too long to complete its tasks.
Why this is correct
With `serial: 5`, Ansible waits for every host in the current batch to finish all tasks before starting the next batch. A single slow host therefore blocks the remaining four, making the playbook appear to hang after the first host completes. The constraint is batch-wide synchronisation, not task failure.
- ✗
The SSH control path is exhausted.
Why it's wrong here
SSH multiplexing exhaustion produces connection errors or refused sessions, not a silent stall after one host. ControlPersist and ControlPath settings are tempting because they tune connection reuse across many hosts, yet Ansible opens fresh connections per task here, so the hang lies elsewhere.
- ✗
The max_fail_percentage is set too high.
Why it's wrong here
A high max_fail_percentage tolerates host failures; it never pauses a play. It is tempting because it governs batch abort behaviour, and lowering it would stop a run early — but the stem describes a stall, not an abort, so the serial batch size and unreachable-host timeout are the real suspects.
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 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.