EX294 Coordinate rolling updates Practice Question
Exhibit
Refer to the exhibit.
PLAY [Update web servers] ********************************************************
TASK [Gathering Facts] *********************************************************
ok: [web1.example.com]
ok: [web2.example.com]
ok: [web3.example.com]
TASK [Update Apache config] ****************************************************
changed: [web1.example.com] => {
"changed": true,
"msg": "Config updated"
}
changed: [web2.example.com] => {
"changed": true,
"msg": "Config updated"
}
failed: [web3.example.com] => {
"changed": false,
"msg": "Permission denied"
}
TASK [Restart Apache] **********************************************************
ok: [web1.example.com] => {
"changed": true,
"msg": "Service restarted"
}
ok: [web2.example.com] => {
"changed": true,
"msg": "Service restarted"
}
skipping: [web3.example.com]
PLAY RECAP *********************************************************************
web1.example.com : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
web2.example.com : ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
web3.example.com : ok=1 changed=0 unreachable=0 failed=1 skipped=1 rescued=0 ignored=0Refer to the exhibit. The playbook uses serial: 1 (one host at a time). The update failed on web3.example.com. Based on the output, what is the most likely reason the play did not abort the rollout and how should the playbook be modified to stop on failure?
⚠ Common exam trap
Red Hat often tests the distinction between per-task error handling (`ignore_errors`, `retries`) and play-level failure thresholds (`max_fail_percentage`), and the trap here is that candidates mistakenly think retrying a task or ignoring errors will stop the rollout, when in fact only `max_fail_percentage` controls whether the play aborts across hosts.
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 max_fail_percentage: 0 to the play to abort on any failure.
The play uses `serial: 1` to update one host at a time, but by default Ansible continues to the next host even if a task fails on the current host. Setting `max_fail_percentage: 0` at the play level tells Ansible to abort the entire play immediately if any host fails, which is the intended behavior for a rolling update where a single failure should stop the rollout.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add retries: 3 to the 'Update Apache config' task.
Why it's wrong here
Retries may help transient failures but do not abort the rollout on persistent failure.
- ✗
Set ignore_errors: yes on the 'Update Apache config' task.
Why it's wrong here
ignore_errors would make the play continue, not abort.
- ✓
Add max_fail_percentage: 0 to the play to abort on any failure.
Why this is correct
max_fail_percentage: 0 aborts the play if any host fails, preventing inconsistent state.
- ✗
Increase the serial value to update multiple hosts at once.
Why it's wrong here
Increasing serial does not abort on failure; it may even cause more failures.
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX294 question from scratch — 520 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.