EX294 Coordinate rolling updates Practice Question
You are designing a rolling update for a stateful service where each node must be removed from a load balancer, updated, and re-added before the next node is touched. The update must never take more than one node offline at a time, and if the update fails on a node, the play must stop and leave the remaining nodes untouched. Which playbook configuration achieves this?
⚠ Common exam trap
The trap here is thinking that ignore_errors or a failure percentage provides safety, when both allow the rollout to continue and risk taking additional nodes offline after a failure.
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
✓
serial: 1 with any_errors_fatal: true and tasks ordered to drain, update, and re-add within the same play.
Ensuring only one node is offline at a time and halting on failure requires a batch size of one and play-level fatal error handling. serial: 1 isolates each node, while any_errors_fatal: true stops the play immediately on any failure, leaving the remaining nodes untouched and still in rotation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
serial: 1 with ignore_errors: true on the update task so the play can continue to the next node.
Why it's wrong here
ignore_errors: true allows the play to continue after a failure, so the next node would be updated even though the previous node may be in a broken state. This violates the requirement to stop on failure and leave remaining nodes untouched, and it can leave a node drained but not re-added.
- ✓
serial: 1 with any_errors_fatal: true and tasks ordered to drain, update, and re-add within the same play.
Why this is correct
serial: 1 processes one host per batch, guaranteeing that only one node is offline at a time. any_errors_fatal: true ensures that a failure on that node stops the entire play, leaving all remaining nodes untouched. Ordering drain, update, and re-add within the same play keeps the node out of rotation only during its own update.
- ✗
serial: 2 with max_fail_percentage: 50 so that one failure in a batch is tolerated and the play continues.
Why it's wrong here
serial: 2 takes two nodes offline at once, which exceeds the one-node limit. max_fail_percentage: 50 would allow the play to continue after one of the two nodes fails, so the remaining nodes would still be updated despite the failure, contradicting the requirement to stop.
- ✗
serial: 1 with run_once: true on the drain and re-add tasks so they execute only once per batch.
Why it's wrong here
run_once: true executes a task on a single host and applies the result to all hosts in the batch, which is wrong for per-node drain and re-add operations. With serial: 1 there is only one host per batch, so run_once adds no benefit and can cause the drain and re-add to be skipped on other nodes in later batches.
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.