EX294 Coordinate rolling updates — Timed 30 Questions

Question 1

A company uses Ansible to manage rolling updates of a web server fleet. During a deployment, the playbook fails on one host due to a transient network error, and the rest of the fleet is left in an inconsistent state. Which strategy would best minimize the risk of inconsistency in future rolling updates?

30 minute time limit — choose an answer to begin.

Accepted Answer

Set max_fail_percentage to 0 in the serial block to abort the rollout on any failure.. Setting `max_fail_percentage: 0` in a rolling update (using `serial`) tells Ansible to abort the entire playbook run if any single host fails. This prevents the rest of the fleet from being updated, avoiding an inconsistent state where some hosts have the new deployment and others do not. It directly addresses the risk of partial rollouts caused by transient errors.

Answer

Add retries to each task so transient errors are automatically retried.

Answer

Use a larger serial batch size to complete the rollout faster.

Answer

Set ignore_errors: yes on all tasks to continue despite failures.

Question 2

Refer 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?

Accepted Answer

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

Add retries: 3 to the 'Update Apache config' task.

Answer

Set ignore_errors: yes on the 'Update Apache config' task.

Answer

Increase the serial value to update multiple hosts at once.

Question 3

You are managing a rolling update of a 10-node web application cluster using Ansible. The application requires that at least 8 nodes remain available during the update to handle traffic. You have written a playbook that uses serial: 2 (updates 2 nodes at a time). During a test run, the playbook updates the first batch of 2 nodes successfully, but when it proceeds to the second batch, one of the nodes fails to restart the web service. However, the playbook continues and updates the remaining nodes. At the end, only 7 nodes are healthy, causing performance degradation. You need to ensure that if a batch fails to meet the minimum health requirements, the entire rollout is stopped and no further updates are applied. Which course of action should you take?

Accepted Answer

Use a rolling update strategy with serial: 2 and a post-task health check, and set max_fail_percentage to abort the play if the healthy node count drops below 8.. This approach uses `max_fail_percentage` at the play level to abort the playbook if a certain percentage of tasks fail. Combined with a post-task health check that fails when fewer than 8 nodes are healthy, the playbook stops if the healthy node count drops below the required threshold, preventing further updates and performance degradation. The `serial: 2` ensures nodes are updated in batches, and the health check verifies the minimum healthy count after each batch.

Answer

Add a retry loop to the service restart task with a delay and count of 5.

Answer

Set ignore_errors: yes on the service restart task to avoid failures stopping the playbook.

Answer

Increase serial to 3 to complete the update faster and reduce the chance of node failures.

Question 4

A team runs the playbook shown in the exhibit. They notice that during the update, some requests are still being sent to servers that have been disabled. What is the most likely cause?

Accepted Answer

The 'serial: 2' setting allows two hosts to be disabled simultaneously, and the load balancer may not have drained connections.. The `serial: 2` setting causes Ansible to update two hosts at a time. When a host is disabled in the load balancer, existing connections may not be fully drained before the next batch of hosts is updated, allowing traffic to still reach disabled servers. The load balancer needs time to drain active sessions, and a serial batch of 2 can overlap with that drain window.

Answer

The disable task should use 'state: maintenance' instead of 'state: disabled'.

Answer

The 'delegate_to' should be set to localhost, not lb01.

Answer

The 'serial' keyword is incorrectly used as a global variable.

Question 5

You are managing a Kubernetes cluster running a critical stateful application deployed as a StatefulSet with 3 replicas. The application uses persistent volumes with ReadWriteOnce access mode. You need to update the container image from version 1.0 to 1.1. The application's performance degrades if more than one replica is unavailable at any time. The StatefulSet is configured with the default RollingUpdate strategy (partition=0). You have a maintenance window of 30 minutes. The update must be completed within the window with minimal risk. Which of the following approaches should you take?

Accepted Answer

Use the default rolling update with partition=0; the StatefulSet will update one pod at a time automatically.. The default RollingUpdate strategy with partition=0 updates one pod at a time, ensuring that no more than one replica is unavailable at any moment. This matches the application's constraint that performance degrades if more than one replica is unavailable, and the 30-minute window is sufficient for a rolling update of 3 pods.

Answer

Manually delete each pod and let the StatefulSet recreate them with the new image.

Answer

Set maxUnavailable to 2 to speed up the rollout, then update the image.

Answer

Perform a canary update by setting partition to 2, updating one pod, validating, then setting partition to 0.

Question 6

Match each Ansible playbook directive to its purpose.

Accepted Answer

hosts: Defines the managed hosts or groups. Correct matches: 'hosts' specifies target hosts, 'tasks' lists actions, 'become' enables privilege escalation. Common confusion includes swapping hosts and tasks.

Answer

hosts: Defines variables used throughout the playbook

Answer

tasks: Defines the target hosts or groups

Question 7

A large enterprise manages thousands of servers grouped by data center. They are designing a rolling update that must complete within a maintenance window. Which combination of Ansible strategies best minimizes total update time while maintaining safety?

Accepted Answer

Set serial to 10% and max_fail_percentage to 25%.. 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.

Answer

Set serial: 0 to update all hosts simultaneously.

Answer

Set forks to 100 and max_fail_percentage to 50.

Answer

Set serial to 1 to update one host at a time with max_fail_percentage: 0.

Question 8

An organization uses Ansible Tower (AWX) for rolling updates. They have a job template that runs a playbook with serial: 5. The inventory contains 50 hosts. The update fails after the first batch due to a syntax error in a playbook. After fixing the error, the administrator wants to resume updating from where it left off without updating already successful hosts. Which approach achieves this?

Accepted Answer

Use the job template survey to input a list of hosts to skip, and pass it as --limit.. Ansible Tower's job template survey can collect a list of hosts to skip, which is then passed as the `--limit` option to the playbook. This allows the administrator to resume the rolling update from the next batch by excluding the first five already-successful hosts, avoiding re-running the playbook on them.

Answer

Create a new job template with a dynamic inventory subset excluding the first batch hosts.

Answer

Modify the playbook to check if a host has already been updated using a fact and skip it.

Answer

Rerun the entire playbook; Ansible will skip hosts that are already in the desired state.

Question 9

What is the effect of setting 'serial: 5' in an Ansible playbook that targets a group of 20 hosts?

Accepted Answer

The playbook runs on 5 hosts at a time, sequentially.. Setting 'serial: 5' in an Ansible playbook configures the playbook to execute each task on a batch of 5 hosts at a time, moving to the next batch only after the current batch completes all tasks. This ensures that no more than 5 hosts are processed concurrently, providing controlled, sequential rolling updates across the 20-host group.

Answer

The playbook runs on 5 hosts per task, then moves to next task.

Answer

The playbook runs only on the first 5 hosts.

Answer

The playbook runs on all 20 hosts at once.

Question 10

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?

Accepted Answer

The playbook continues with the next batch of 3 hosts.. The `max_fail_percentage` parameter applies to the total number of hosts, not per batch. With 10 hosts and 20%, up to 2 hosts can fail overall. The first batch had only 1 failure, which is within the limit, so the playbook continues with the next batch of 3 hosts. Options B, C, and D are incorrect because the failure threshold has not been exceeded.

Answer

The playbook retries the failed host, then continues.

Answer

The playbook marks the failed host as unreachable and continues.

Answer

The playbook aborts and no further hosts are updated.

Question 11

Which TWO options are valid techniques for rolling out updates to a subset of hosts before updating the rest? (Choose exactly two.)

Accepted Answer

Use serial: 3 to update hosts in batches of 3.. Option A is correct because Ansible's serial keyword controls how many hosts are targeted per play iteration, so serial: 3 updates the fleet in batches of three, letting you validate each batch before the next one runs. Option B is correct because a canary group combined with a separate playbook run and manual verification is the classic canary deployment pattern, limiting blast radius by updating a small subset first and only proceeding to the full fleet after checks pass. Option C is not a valid rollout technique as described: inventory host variables plus conditional tasks merely filter which tasks execute on which hosts, but they do not by themselves sequence or throttle updates across the fleet. Option D is incorrect because --forks=1 only limits parallelism to one host at a time; it does not provide batch boundaries, verification points, or a controlled rollout strategy, and it slows execution without the safety semantics of serial. Option E is incorrect because strategy: random is not a valid Ansible strategy directive; valid strategies are linear, free, host_pinned, and debug, so this would not produce a subset-first rollout.

Answer

Use inventory host variables to mark hosts for early update and use conditional tasks.

Answer

Use the --forks=1 option to update one host at a time.

Answer

Use the 'strategy: random' directive in the playbook.

Question 12

Which TWO conditions cause an Ansible rolling update playbook to abort immediately? (Choose exactly two.)

Accepted Answer

The failure count in a batch exceeds max_fail_percentage.. Option A is correct because max_fail_percentage defines the tolerated percentage of hosts that may fail within a batch; once the failure count in that batch exceeds this threshold, Ansible aborts the play for the remaining hosts. Option C is correct because any_errors_fatal: yes makes any task failure on any host immediately fatal, causing Ansible to stop executing the play on all hosts rather than continuing with the remaining hosts. Option B is not correct because changed_when: false simply forces the task's changed status to false and does not abort the playbook. Option D is not correct because --check runs the playbook in dry-run mode, reporting what would change without aborting due to that flag alone. Option E is not correct because an unreachable host is normally removed from the play and execution continues for reachable hosts unless a fatal condition such as any_errors_fatal or max_fail_percentage is triggered.

Answer

A task returns 'changed' when 'changed_when: false' is used.

Answer

The playbook runs with the --check flag.

Answer

A host is unreachable due to network issues.

Question 13

An Ansible playbook uses the 'deployment' resource with a 'rolling_update' strategy. Which module is typically used to manage this in a Kubernetes/OpenShift environment?

Accepted Answer

kubernetes.core.k8s. The `kubernetes.core.k8s` module is the correct choice because it directly manages Kubernetes/OpenShift resources, including Deployments, and supports rolling update strategies natively. It interacts with the Kubernetes API to apply declarative configurations, handling the rolling update logic (e.g., `maxSurge`, `maxUnavailable`) without requiring manual orchestration via shell commands or file copies.

Answer

ansible.builtin.copy

Answer

ansible.builtin.command

Answer

ansible.builtin.shell

Answer

ansible.builtin.service

Question 14

An OpenShift deployment is stuck in a degraded state after a rolling update. Which command helps diagnose the root cause by showing status conditions?

Accepted Answer

oc describe deployment/myapp. `oc describe deployment/myapp` displays the full status conditions of the Deployment, including `Progressing`, `Available`, and `ReplicaFailure` conditions. When a rolling update leaves the Deployment in a degraded state, the `Conditions` field under `Status` explicitly shows the reason (e.g., `ProgressDeadlineExceeded` or `MinimumReplicasUnavailable`), which directly points to the root cause of the degradation.

Answer

oc rollout history

Answer

oc get pods

Answer

oc logs deployment/myapp

Answer

oc get events

Question 15

Which THREE of the following are valid 'serial' values for an Ansible rolling update playbook?

Accepted Answer

serial: [1,2,3]. Option A (serial: [1,2,3]) is correct because Ansible accepts a list of integers for serial, applying each value in sequence to successive batches of hosts (first 1 host, then 2, then 3). Option B (serial: 50%) is correct because serial accepts a percentage string, so Ansible processes 50% of the hosts in each batch. Option C (serial: 1) is correct because a plain integer is the most basic valid serial value, running the play on one host at a time. Option D (serial: '25%') is not a valid serial value because the percentage must be an unquoted YAML scalar (or quoted without issue only when the value is a string, but Ansible expects the percentage form as a plain scalar; quoting it makes it a string that Ansible does not interpret as a percentage). Option E (serial: 'batch') is not valid because 'batch' is not a recognized keyword or numeric/percentage value for serial.

Answer

serial: '25%'

Answer

serial: 'batch'

Question 16

Which THREE commands can verify the status of a rolling update on an OpenShift deployment?

Accepted Answer

oc describe deployment/. Option A, `oc describe deployment/`, is correct because the deployment's status section reports the rolling update state, including the updated replicas, available replicas, and conditions such as Progressing or Available, letting you confirm whether the rollout has completed. Option C, `oc get events`, is correct because rollout-related events (for example, scaling replicas up/down or failing to create pods) are recorded as Kubernetes events and reveal the progress or problems of a rolling update. Option E, `oc rollout status deployment/`, is correct because it is the purpose-built command that watches the deployment's rollout and reports whether it has successfully completed or is still in progress. Option B, `oc logs deployment/`, is not appropriate because logs show application output from the pods, not the deployment controller's rollout status, and a deployment object itself does not produce container logs. Option D, `oc get pods -l `, is not one of the marked answers because it only lists matching pods and their phases; while useful, it does not directly report the deployment's rolling update status as the three correct commands do.

Answer

oc logs deployment/<name>

Answer

oc get pods -l <selector>

Question 17

Which TWO Ansible playbook parameters directly control the number of host failures allowed before aborting a rolling update?

Accepted Answer

max_fail_percentage. Option A, max_fail_percentage, is correct because it sets a threshold percentage of hosts in the current batch that may fail before Ansible aborts the play for the remaining hosts, directly governing how many failures are tolerated during a rolling update. Option B, any_errors_fatal, is correct because when set to true it causes the play to abort immediately on the first host failure, effectively controlling whether any failure stops the rolling update. Option C, throttle, is incorrect because it limits the number of hosts executing a task concurrently, not the number of failures allowed. Option D, serial, is incorrect because it defines the batch size (how many hosts are updated per iteration), not the failure tolerance. Option E, ignore_errors, is incorrect because it allows a task to continue despite failure rather than controlling when the play aborts based on host failures.

Answer

throttle

Answer

serial

Answer

ignore_errors

Question 18

The deployment has 4 replicas. During a rolling update, what is the maximum number of pods that can be unavailable at any single time?

Accepted Answer

1. The default rolling update strategy for a Deployment in Kubernetes sets `maxUnavailable` to 25% of the desired replicas, rounded up. With 4 replicas, 25% equals 1, so at most 1 pod can be unavailable during the update. This ensures minimal disruption while allowing the update to proceed.

Answer

2

Answer

4

Answer

0

Answer

3

Question 19

There are 5 hosts in the webservers group. All updates succeed on the first batch of 2 hosts. On the second batch, one host fails. What is the result?

Accepted Answer

The play aborts due to max_fail_percentage being exceeded.. Assuming the default max_fail_percentage of 0% (or a low threshold), the failure of one host in the second batch causes the cumulative failure percentage to exceed the allowed limit. Since the threshold is exceeded, the play aborts, making option D correct. Option E suggests an immediate abort, but the abort is specifically due to max_fail_percentage being exceeded.

Answer

The play retries the failed host automatically.

Answer

The play marks the host as failed and continues with the next batch.

Answer

The play continues with the remaining 1 host in the third batch.

Answer

The play aborts immediately after the failure.

Question 20

You are managing a critical web application deployed on OpenShift with 12 replicas. The application must maintain at least 10 replicas available during updates to meet an SLA. You initiate a rolling update using the default strategy, but the rollout is progressing slowly because only 2 new pods are created at a time, causing a prolonged update duration. You need to speed up the rollout without violating the SLA (10 available replicas). The current Deployment configuration has maxSurge: 25% (3 pods) and maxUnavailable: 25% (3 pods). You have permission to update the DeploymentConfig during the active rollout. Which action should you take?

Accepted Answer

Set maxSurge to 10 and maxUnavailable to 2, then run 'oc rollout resume'.. The current maxSurge is 25% of 12, which is 3 pods, and maxUnavailable is 25%, which is 3 pods. To speed up the rollout while maintaining at least 10 available replicas, we need to ensure that maxUnavailable does not exceed 2 (since 12 - 2 = 10). Increasing maxSurge allows more new pods to be created simultaneously, speeding up the rollout. Setting maxSurge to 10 and maxUnavailable to 2 satisfies the SLA and significantly increases the number of new pods created at a time. The command 'oc rollout resume' is used to resume a paused rollout, but the question states the rollout is progressing slowly, not paused. However, in OpenShift, you can update the DeploymentConfig during a rollout, and the changes will apply to the ongoing rollout. The correct action is to set maxSurge to 10 and maxUnavailable to 2, then resume if needed. Option D is correct.

Answer

Cancel the current rollout, set maxSurge to 4 and maxUnavailable to 2, then start a new rollout.

Answer

Set maxSurge to 50% and maxUnavailable to 50%, then run 'oc rollout resume'.

Answer

Set maxSurge to 5 and maxUnavailable to 2, then run 'oc rollout retry'.