EX294 Coordinate rolling updates Practice Test 4 — 15 Questions

Question 1

An Ansible Engineer is planning a rolling update for a web application deployed across 10 nodes. The playbook uses the 'delegate_to' directive to manage load balancer health checks. Which of the following best describes the recommended approach to minimize downtime?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Use 'serial: 1' and delegate load balancer disable/enable tasks to localhost, ensuring each node is taken out of rotation before updating.. Using 'serial: 1' ensures that only one node is updated at a time, and delegating load balancer disable/enable tasks to localhost (or the Ansible control node) allows the playbook to interact with the load balancer API to remove the node from the pool before the update and re-add it after. This minimizes downtime by ensuring traffic is not sent to a node being updated, while other nodes continue serving requests.

Answer

Run the update playbook with 'serial: 10' to update all nodes at once, then run a separate playbook to update the load balancer.

Answer

Run the update on each node manually using 'ansible-playbook --limit' and skip load balancer management to save time.

Answer

Use 'strategy: free' to allow nodes to update independently without controlling the load balancer.

Question 2

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

Accepted Answer

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

Use 'strategy: free' to allow hosts to run tasks independently.

Answer

Use 'gather_facts: no' to speed up the playbook.

Answer

Set 'any_errors_fatal: true' to stop the update on the first failure.

Question 3

An administrator needs to update a web application that runs as a Kubernetes Deployment with 5 replicas. The application is stateless, but the update must not cause any downtime. Which TWO strategies ensure zero-downtime rolling updates?

Accepted Answer

Set strategy type to RollingUpdate with maxUnavailable=0 and maxSurge=1.. Option B is correct because a RollingUpdate strategy with maxUnavailable=0 and maxSurge=1 guarantees that no existing pod is terminated until a new pod is fully available, so the Deployment always keeps all 5 replicas serving traffic during the update. Option E is correct because a readiness probe tied to the application's health endpoint ensures Kubernetes only routes traffic to new pods once they are actually ready, preventing requests from hitting uninitialized instances during the rollout. Together, maxUnavailable=0/maxSurge=1 plus a readiness probe are the standard mechanism for zero-downtime updates of a stateless Deployment. Option A is wrong because omitting a liveness probe does not prevent downtime and removes Kubernetes' ability to restart unhealthy containers. Option C is wrong because maxUnavailable=1 allows a pod to be taken out of service before its replacement is ready, reducing capacity and risking dropped requests. Option D is wrong because the Recreate strategy terminates all existing pods before creating new ones, causing guaranteed downtime.

Answer

Omit the liveness probe from the pod spec.

Answer

Set maxUnavailable=1 and maxSurge=0.

Answer

Use the Recreate strategy.

Question 4

Drag and drop the steps to configure a firewall rule using firewalld to allow HTTPS traffic in the correct order.

Accepted Answer

Step 1: Check the current default zone. Step 2: Add the HTTPS service permanently using --permanent. Step 3: Reload firewalld. Step 4: Verify the rule is active. Step 5: Test connectivity.. Firewalld commands: check zone, add service with --permanent, reload, verify, test.

Answer

Step 1: Add the HTTPS service without --permanent. Step 2: Reload firewalld. Step 3: Verify the rule. Step 4: Test connectivity.

Answer

Step 1: Add the HTTPS service with --permanent. Step 2: Verify the rule without reloading. Step 3: Reload firewalld. Step 4: Test connectivity.

Answer

Step 1: Reload firewalld. Step 2: Add the HTTPS service with --permanent. Step 3: Verify the rule. Step 4: Test connectivity.

Question 5

An administrator wants to update a web server fleet with minimal downtime. They need to update each server one at a time. Which Ansible playbook directive should be used?

Accepted Answer

serial: 1. The `serial: 1` directive in an Ansible playbook controls the batch size of hosts that are updated simultaneously. Setting it to 1 ensures that only one host is updated at a time, which minimizes downtime by allowing the rest of the fleet to remain available while each server is sequentially updated.

Answer

throttle: 1

Answer

forks: 1

Answer

max_fail_percentage: 0

Question 6

During a rolling update using an Ansible playbook with serial: 2, one host in the first batch becomes unreachable. The playbook fails with an unreachable host error. How should the administrator proceed to complete the update on the remaining hosts while excluding the problematic host?

Accepted Answer

Use 'ansible-playbook playbook.yml --limit all:!hostname' to exclude the unreachable host.. The `--limit` flag with the pattern `all:!hostname` uses Ansible's inventory host pattern syntax to exclude a specific host from the playbook run. This allows the administrator to rerun the playbook against all hosts except the unreachable one, completing the rolling update without re-attempting the failed host. The `serial: 2` setting is irrelevant once the host is excluded, as the playbook will only target the remaining reachable hosts.

Answer

Use 'ansible-playbook playbook.yml --forks 1' to slow down the update.

Answer

Add 'any_errors_fatal: false' to the playbook and rerun.

Answer

Rerun the playbook with the same command; it will skip the unreachable host automatically.

Question 7

An administrator notices that during a rolling update, the playbook seems to hang after updating the first host. The playbook uses serial: 5. What is the most likely cause?

Accepted Answer

One of the hosts in the batch is taking too long to complete its tasks.. When `serial: 5` is set, Ansible processes hosts in batches of five. If one host in the batch takes an unusually long time to complete its tasks (e.g., due to a slow network, a hanging service restart, or a long-running command), the entire batch will appear to hang because Ansible waits for all hosts in the current batch to finish before proceeding to the next batch. This is the most likely cause of the observed behavior during a rolling update.

Answer

The playbook has an infinite loop.

Answer

The SSH control path is exhausted.

Answer

The max_fail_percentage is set too high.

Question 8

A team uses Ansible to update a database cluster with one primary and two replicas. The goal is zero downtime. Which update order is the safest?

Accepted Answer

Update replicas first, then the primary.. Updating replicas first ensures that if the update introduces a regression, it affects only the read-only replicas, which can be quickly rolled back without impacting write availability. Once replicas are confirmed healthy, the primary is updated and a controlled failover (e.g., using `patronictl switchover` or `repmgr standby switchover`) promotes a replica to primary, minimizing downtime to seconds. This order aligns with the principle of reducing blast radius and maintaining quorum in a cluster.

Answer

Update in random order.

Answer

Update all nodes simultaneously.

Answer

Update the primary first, then replicas.

Question 9

A company wants to implement a rolling update for a stateful application where hosts cannot be updated in parallel due to data consistency. They also need to ensure that if any host fails, the entire update is rolled back. Which strategy meets these requirements?

Accepted Answer

Use serial: 1 and any_errors_fatal: yes. Setting `serial: 1` ensures hosts are updated one at a time, preventing parallel updates that could break data consistency for a stateful application. Adding `any_errors_fatal: yes` causes the entire playbook run to abort immediately if any host fails, which satisfies the requirement for a full rollback on failure.

Answer

Use serial: 2 and any_errors_fatal: yes

Answer

Use serial: 1 and ignore_errors: yes

Answer

Use serial: 0 and max_fail_percentage: 0

Question 10

Which THREE statements correctly describe the behavior of the 'serial' keyword in Ansible? (Choose exactly three.)

Accepted Answer

It can be set as a percentage of the total hosts.. 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.

Answer

It guarantees that only one task runs across all hosts at any time.

Answer

It applies globally to all plays in the playbook.

Question 11

A team uses Ansible to update a web application across 10 servers with minimal downtime. Which playbook directive achieves one-at-a-time updates?

Accepted Answer

serial: 1. C is correct because the `serial: 1` directive in an Ansible playbook controls the number of hosts that are updated simultaneously. Setting `serial: 1` forces Ansible to execute the playbook on one host at a time, ensuring that the web application is updated sequentially across the 10 servers, which minimizes downtime by keeping the other 9 servers available during each individual update.

Answer

run_once: true

Answer

delegate_to: localhost

Answer

throttle: 1

Answer

forks: 10

Question 12

In OpenShift, a DeploymentConfig uses the RollingUpdate strategy. Which parameter controls the maximum number of pods that can be unavailable during an update?

Accepted Answer

maxUnavailable. In OpenShift, the RollingUpdate strategy for a DeploymentConfig uses the `maxUnavailable` parameter to specify the maximum number or percentage of pods that can be unavailable during the update process. This ensures that the desired number of pods remain available to serve traffic while the update rolls out, controlling the trade-off between update speed and availability.

Answer

minReadySeconds

Answer

maxSurge

Answer

revisionHistoryLimit

Answer

progressDeadlineSeconds

Question 13

An Ansible playbook sets 'serial: 20%' for rolling updates, but the inventory contains 5 hosts. How many hosts are updated simultaneously?

Accepted Answer

1. When 'serial: 20%' is set in an Ansible playbook, the percentage is calculated based on the total number of hosts in the inventory. With 5 hosts, 20% of 5 equals 1.0, which is rounded down to 1. Therefore, only 1 host is updated at a time during the rolling update.

Answer

2

Answer

3

Answer

0

Answer

5

Question 14

An Ansible rolling update playbook includes 'max_fail_percentage: 20'. If more than 20% of hosts fail during any batch, what happens?

Accepted Answer

The play aborts immediately. The `max_fail_percentage` parameter in Ansible's rolling update strategy defines the maximum percentage of hosts that can fail in a single batch before the playbook aborts entirely. When the failure rate exceeds this threshold, Ansible stops execution immediately to prevent cascading failures or inconsistent state across the remaining hosts.

Answer

The play pauses and waits for user input

Answer

The failed hosts are removed from inventory

Answer

The play retries failed hosts

Answer

The play continues with remaining hosts

Question 15

In OpenShift, a deployment must gradually shift traffic to new pods during a rolling update. Which default strategy achieves this?

Accepted Answer

RollingUpdate. The RollingUpdate strategy is the default deployment strategy in OpenShift (and Kubernetes) that gradually replaces old pods with new ones while maintaining application availability. It achieves this by incrementally scaling down the old ReplicaSet and scaling up the new one, controlled by parameters like maxSurge and maxUnavailable, ensuring a smooth transition of traffic to new pods.

Answer

Blue-green deployment

Answer

Canary deployment

Answer

Custom strategy

Answer

Recreate