EX294 Coordinate rolling updates Practice Test 2 — 15 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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.. The `serial: 3` directive in an Ansible playbook limits the number of hosts updated in each batch, allowing you to roll out changes to a subset of hosts before proceeding to the next batch. This is a native Ansible mechanism for controlling rolling updates by specifying the batch size, ensuring that only three hosts are updated at a time, with the play pausing between batches.

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 8

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.. The 'serial' keyword in Ansible can be specified as a percentage (e.g., 'serial: 50%'), which tells Ansible to run the play on that percentage of hosts in the batch at a time. This is useful for controlling the rollout pace across a dynamic inventory where the exact host count may vary.

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 9

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.. Ansible's rolling update logic uses `max_fail_percentage` to control batch failure tolerance. If the number of failed hosts in a batch exceeds this percentage, the playbook aborts immediately to prevent cascading failures. Option C is correct because setting `any_errors_fatal: yes` causes the entire playbook to abort as soon as any task fails on any host, regardless of batch boundaries.

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 10

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 11

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 12

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

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