Coordinate rolling updates →hardMultiple Select

EX294 Coordinate rolling updates Practice Question

Which TWO of the following are best practices when coordinating rolling updates with Ansible?

⚠ Common exam trap

Watch out — candidates often confuse 'any_errors_fatal' (which stops on the first failure globally) with 'max_fail_percentage' (which aborts only after a threshold of failures in a batch), leading them to select option E instead of A.

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

✓

Define a 'max_fail_percentage' to abort the update if too many hosts fail.

Option B is correct because the 'serial' keyword controls how many hosts are targeted per play iteration, which is the fundamental mechanism for performing a rolling update in Ansible—updating a small batch at a time rather than all hosts at once. Option A is correct because 'max_fail_percentage' works together with 'serial' to abort the entire play if the number of failed hosts in a batch exceeds the defined threshold, preventing a bad rollout from cascading across the fleet. Option C is not a best practice for rolling updates because 'strategy: free' lets each host proceed through tasks independently without waiting for others, which breaks the controlled batch-by-batch ordering that rolling updates require. Option D is not inherently a rolling-update best practice; disabling fact gathering may speed execution but does not coordinate or sequence updates and can break plays that depend on facts. Option E is not appropriate here because 'any_errors_fatal: true' aborts the whole play on the very first host failure, which is more aggressive than the graduated tolerance provided by 'max_fail_percentage' and is not the recommended pairing for controlled rolling updates.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Define a 'max_fail_percentage' to abort the update if too many hosts fail.
Why this is correct
Setting `max_fail_percentage` halts the play once failed hosts exceed the threshold, preventing a faulty update from cascading across the remaining batch. This directly satisfies the stem's coordination requirement by bounding blast radius during rolling updates, rather than letting Ansible continue through every host regardless of accumulating failures.
✓
Use the 'serial' keyword to update a subset of hosts at a time.
Why this is correct
The serial keyword splits the host inventory into batches, so each batch completes before the next begins. This keeps most servers serving traffic while a small subset is updated, preserving availability during the rolling update.
✗
Use 'strategy: free' to allow hosts to run tasks independently.
Why it's wrong here
Free strategy lets each host proceed through the whole play without waiting, so hosts update concurrently rather than in controlled batches, defeating the serial ordering rolling updates require. It is tempting because free strategy shortens total runtime, and it is correct for independent, non-coordinated tasks across many hosts.
✗
Use 'gather_facts: no' to speed up the playbook.
Why it's wrong here
Disabling fact gathering removes the variables rolling updates depend on, such as host-specific values used in conditionals and templates, so per-host decisions break. It is tempting because skipping setup does cut runtime on large inventories, and it is correct when a playbook genuinely needs no host data.
✗
Set 'any_errors_fatal: true' to stop the update on the first failure.
Why it's wrong here
Any_errors_fatal aborts the entire play for all hosts on the first failure, so remaining batches never update, leaving the fleet split across versions. It is tempting because halting on failure sounds safe, and it is correct when a single failure must stop a tightly coupled deployment entirely.

Go deeper

EX294 Coordinate rolling updates Practice Question

Why each option matters

Option-by-option breakdown

Related to this question