An administrator uses a rolling update strategy with serial: 3 and max_fail_percentage: 20. They have 10 hosts in the inventory. The first batch of 3 hosts: 2 succeed, 1 fails. What happens next?
Correct. The failure percentage in the batch exceeded max_fail_percentage.
Why this answer
Option D is correct because when `max_fail_percentage` is set to 20% and the inventory has 10 hosts, the maximum allowed failures across the entire play is 2 hosts (20% of 10 = 2). In the first batch of 3 hosts, 1 failure already occurred. If the playbook continued and another failure happened in a subsequent batch, the total failures would exceed 2, violating the `max_fail_percentage` constraint.
Ansible's rolling update logic aborts the entire play immediately when a failure occurs in a batch if the cumulative failures would exceed the allowed percentage, preventing further updates.
Exam trap
The trap here is that candidates mistakenly think `max_fail_percentage` applies per batch rather than to the total inventory, leading them to believe the playbook can continue with the next batch since only 1 of 3 hosts failed in the first batch.
How to eliminate wrong answers
Option A is wrong because continuing with the next batch would risk exceeding the `max_fail_percentage` of 20% (2 failures allowed out of 10 hosts) since 1 failure has already occurred and any additional failure would push the total to 2 or more, which is not permitted. Option B is wrong because Ansible does not automatically retry failed hosts in a rolling update; it aborts the play when the failure threshold is reached, and retrying would not change the fact that the failure count already consumes half of the allowed failures. Option C is wrong because marking the host as unreachable does not resolve the failure count; the `max_fail_percentage` is based on actual failures, not reachability status, and the playbook still aborts to prevent exceeding the threshold.