Ansible Serial Keyword for Quorum in Rolling Updates

• ✓ A.It can be set as a percentage of the total hosts.
• ✓ B.It causes the playbook to run on a subset of hosts at a time.
• ✓ C.It can be combined with max_fail_percentage to control failure thresholds.
• D.It guarantees that only one task runs across all hosts at any time.
• E.It applies globally to all plays in the playbook.

Why A: Option A is correct because the serial keyword accepts a percentage value (e.g., serial: 25%) that Ansible interprets as a fraction of the total hosts in the play, batching them accordingly. Option B is correct because serial defines the number of hosts (or batch size) that Ansible targets per play iteration, so the play runs on a subset of hosts at a time rather than all at once. Option C is correct because serial is commonly paired with max_fail_percentage, which aborts the play if failures within a serial batch exceed the given threshold, enabling controlled rolling updates. Option D is incorrect because serial controls host batching, not task concurrency; it does not guarantee only one task runs across all hosts at any time. Option E is incorrect because serial is set at the play level and applies only to that specific play, not globally to all plays in a playbook.

• ✓ A.Define a 'max_fail_percentage' to abort the update if too many hosts fail.
• ✓ B.Use the 'serial' keyword to update a subset of hosts at a time.
• C.Use 'strategy: free' to allow hosts to run tasks independently.
• D.Use 'gather_facts: no' to speed up the playbook.
• E.Set 'any_errors_fatal: true' to stop the update on the first failure.

Why A: 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.

• A.Set ignore_errors: yes to ensure the playbook continues even if some hosts fail.
• ✓ B.Use the serial keyword to update hosts in batches.
• C.Use the default serial setting (all hosts) for simplicity.
• ✓ D.Set max_fail_percentage to limit the number of failed hosts before aborting.
• E.Run all hosts in parallel to minimize total update time.

Why B: Option B is correct because the serial keyword in Ansible controls how many hosts are targeted per play iteration, allowing rolling updates in controlled batches (e.g., serial: 2 or serial: 25%) so that only a subset of hosts is updated at a time while the rest continue serving traffic. Option D is correct because max_fail_percentage defines a failure threshold within a serial batch; if the percentage of failed hosts exceeds that value, Ansible aborts the play, preventing a bad update from cascading across the entire fleet. Option A is not a best practice for rolling updates because ignore_errors: yes masks failures and lets the playbook proceed even when hosts are broken, defeating the safety purpose of batching. Option C is wrong because the default serial value is effectively all hosts in the play, which performs a simultaneous update rather than a rolling one. Option E is also wrong because running all hosts in parallel maximizes blast radius and downtime risk, the opposite of a rolling-update strategy.

• A.Set serial: 0 to update all hosts simultaneously.
• ✓ B.Set serial to 10% and max_fail_percentage to 25%.
• C.Set forks to 100 and max_fail_percentage to 50.
• D.Set serial to 1 to update one host at a time with max_fail_percentage: 0.

Why B: Setting `serial: 10%` updates hosts in batches of 10% of the inventory, which parallelizes the update across many hosts to minimize total time, while `max_fail_percentage: 25%` provides a safety net by aborting the play if more than 25% of the batch fails, preventing a cascade of failures from taking down the entire data center. This combination balances speed and safety for large-scale rolling updates within a maintenance window.