EX294 Coordinate rolling updates Practice Test 3 — 15 Questions

Question 1

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

Question 2

An Ansible rolling update playbook has 'serial: 1' and 'max_fail_percentage: 0'. During the update of a 5-host group, the first host fails. What is the outcome?

Accepted Answer

The play aborts immediately. With 'serial: 1', Ansible updates one host at a time. 'max_fail_percentage: 0' means that if any host fails (0% failure tolerance), the entire playbook run is aborted immediately. When the first host fails, Ansible stops further execution because the failure percentage exceeds the threshold, and no retries or continuation occur.

Answer

The play pauses for manual intervention

Answer

The play retries the failed host

Answer

The play continues with the remaining 4 hosts

Answer

The play marks the host as unreachable and continues

Question 3

An OpenShift rolling update is failing because new pods crash immediately. Which parameter automatically triggers a rollback if no progress is made?

Accepted Answer

progressDeadlineSeconds. The `progressDeadlineSeconds` parameter specifies the maximum duration (in seconds) that a deployment can make no progress before it is considered to have failed. When this deadline is exceeded, the deployment controller automatically triggers a rollback to the previous revision. This is the correct parameter for automatically rolling back a failed rolling update where new pods crash immediately.

Answer

revisionHistoryLimit

Answer

maxSurge

Answer

maxUnavailable

Answer

minReadySeconds

Question 4

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

Accepted Answer

serial: [1,2,3]. Options A, B, and C are all valid 'serial' values for an Ansible rolling update playbook. Ansible's 'serial' keyword controls how many hosts are updated at a time. It accepts an integer (e.g., 1), a percentage string without quotes (e.g., 50%), or a list of integers (e.g., [1,2,3]) to specify varying batch sizes sequentially. Option D is invalid because quoting the percentage (e.g., '25%') treats it as a YAML string that includes the quotes, which Ansible does not interpret correctly. Option E 'batch' is not a valid value.

Answer

serial: '25%'

Answer

serial: 'batch'

Question 5

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

Accepted Answer

oc describe deployment/. `oc describe deployment/` provides detailed information about the deployment, including the current rollout status, revision history, and conditions such as Progressing or Available. This allows you to verify whether a rolling update is in progress, has completed, or has stalled by examining fields like `Replicas`, `UpdatedReplicas`, and `Conditions`.

Answer

oc logs deployment/<name>

Answer

oc get pods -l <selector>

Question 6

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

Accepted Answer

max_fail_percentage. `max_fail_percentage` directly specifies the maximum percentage of hosts that can fail during a rolling update before Ansible aborts the entire batch. Option B is correct because `any_errors_fatal` causes the playbook to stop immediately if any host in the current batch fails, effectively limiting failures to zero before aborting the rolling update.

Answer

throttle

Answer

serial

Answer

ignore_errors

Question 7

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 8

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 9

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

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

Question 10

An operations team is planning a rolling update of a production OpenShift cluster running Red Hat Enterprise Linux CoreOS nodes. Which three practices should be followed to ensure minimal downtime and proper rollback capability?

Accepted Answer

Use canary nodes to validate the update before full rollout.. Using canary nodes allows you to validate the update on a small subset of nodes before rolling it out to the entire cluster. This practice minimizes the blast radius of potential issues, ensuring that if the update causes problems, only the canary nodes are affected, and the rest of the cluster remains stable. It directly supports minimal downtime by catching failures early and provides a clear rollback point by isolating the test group.

Answer

Monitor cluster health via `oc get clusterversion` after each node update.

Answer

Place nodes in the same Availability Zone to simplify rollback.

Question 11

A systems administrator is performing a rolling update of a three-node Red Hat Enterprise Linux 8 cluster running a load-balanced web application. The update involves upgrading the httpd package. The administrator uses Ansible to update one node at a time. After updating the first node, the administrator checks the application health and finds that the node is serving requests correctly. The administrator proceeds to update the second node. However, after the second node update completes, the load balancer reports that both the first and second nodes are unavailable. What is the most likely cause?

Accepted Answer

The second node's update triggered a configuration change that disabled the health check endpoint on both nodes.. The rolling update of the second node could have triggered a configuration change (e.g., via a shared configuration file or package update) that affected the health check endpoint on both the first and second nodes. This would explain why both nodes became unavailable after the second node update. Option A is wrong since a segmentation fault in httpd would likely only affect the node where it occurs and is not automatically triggered by an update on another node. Option B is incorrect because if the first node were excluded from the load balancer pool, it would have been unavailable immediately after its own update, not after the second node update. Option C is wrong because load balancers are typically configured to allow multiple active nodes; restricting to one node is uncommon and would not explain sudden unavailability of both nodes.

Answer

The httpd service on both nodes experienced a segmentation fault after the update.

Answer

The first node was inadvertently excluded from the load balancer pool by the Ansible playbook.

Answer

The load balancer was configured to only allow one node to be active at a time.

Question 12

A DevOps engineer is responsible for coordinating a rolling update of a Red Hat OpenShift Container Platform 4.12 cluster with 10 worker nodes. The cluster hosts a stateful application that uses persistent volumes with ReadWriteOnce access mode. The update involves a minor version upgrade of the cluster from 4.12.0 to 4.12.5. The engineer uses the recommended `oc adm upgrade` command. During the update, after the first worker node is updated, the engineer notices that the node's status shows 'NotReady' and the cluster version operator reports a degraded status. A check of the node logs reveals 'kubelet: Failed to run kubelet: Could not get kubelet config from cluster: could not get config from cluster: context deadline exceeded'. Which action should the engineer take first?

Accepted Answer

Check the network connectivity between the updated node and the control plane nodes on port 6443.. The error indicates the kubelet cannot communicate with the control plane on port 6443, likely due to a network issue (e.g., firewall, DNS, or routing). Option A is wrong because rolling back the entire cluster is a drastic first step; the issue is likely isolated. Option C is wrong because changing kubelet parameters is not a standard resolution for connectivity problems. Option D is wrong because rebuilding the node from scratch is unnecessary and time-consuming; the issue is likely resolvable by restoring network connectivity.

Answer

Rebuild the node from scratch using the machine config operator.

Answer

Roll back the entire cluster to version 4.12.0 using the `oc adm upgrade --to=4.12.0` command.

Answer

Increase the kubelet's `--node-status-update-frequency` parameter on the updated node.

Question 13

A company uses Ansible to perform a rolling update of 10 web servers behind an HAProxy load balancer. The playbook uses the `serial` keyword and includes tasks to disable a host from the load balancer, update the web server package, and re-enable the host. Which TWO best practices should the administrator apply to minimize downtime and ensure a successful rolling update?

Accepted Answer

Set `serial: 1` to update one host at a time.. Setting `serial: 1` ensures that only one host is updated at a time, which is the safest way to perform a rolling update without overwhelming the load balancer or causing a service outage. This allows the playbook to complete the full update cycle (disable, update, re-enable) for each host before moving to the next, minimizing the number of hosts out of service simultaneously.

Answer

Use `any_errors_fatal: true` to stop the playbook if any host fails.

Answer

Use `throttle: 1` to limit the number of concurrent tasks across all hosts.

Answer

Use `async` and `poll` to run the update tasks in the background while proceeding to the next host immediately.

Question 14

An administrator runs this playbook against a group of 10 web servers. The update fails on the third host (host3) due to a yum error. What is the most likely outcome?

Accepted Answer

The playbook continues with the remaining hosts because the number of failures (1) is below the 25% threshold.. The playbook uses the `serial: 2` directive, which batches hosts in groups of two, and the `max_fail_percentage: 25` setting. With 10 hosts, 25% allows up to 2 failures (2.5 rounded down). Since only one failure occurred (on host3), the playbook continues processing the remaining batches after the failed batch completes.

Answer

Only the first batch (host1 and host2) are updated successfully; the remaining hosts are skipped.

Answer

All hosts are disabled in HAProxy and the playbook fails.

Answer

The playbook halts immediately after the failure on host3.

Question 15

An organization uses Ansible Automation Platform to perform rolling updates on a 5-node PostgreSQL replication cluster. The playbook uses `serial: 1` and includes tasks to promote a standby, demote the primary, update PostgreSQL packages, and then re-elect the original primary. The cluster health check task verifies that replication lag is under 10 seconds before proceeding to the next node. Recently, during an update of the primary node (node1), the health check after re-election fails because replication lag is 15 seconds due to a large write load. The playbook aborts, leaving the cluster in a degraded state with node1 updated but not serving as primary. The administrator needs to ensure that the update continues while still maintaining cluster integrity. Which action should the administrator take?

Accepted Answer

Wrap the update tasks in a block with a rescue handler that reverts the update on the failed host and then continues with the next host.. Using a rescue block allows reverting the update on node1 (e.g., demote it back to standby, re-promote the original standby) so the cluster returns to its original state, and then continue with the next node. This ensures no node remains in an inconsistent state and the update can proceed. Option B is wrong because `ignore_errors` would continue without reverting the failed node, leaving node1 in a half-updated state that could cause issues. Option C is wrong because removing the health check could allow a broken cluster state to go undetected, risking data integrity. Option D is wrong because `max_fail_percentage: 20` would allow only 1 failure out of 5, but if node1 fails, the count is 1 (20%), so the playbook would still abort; even if it continued, it would not revert the failed node, leading to inconsistencies.

Answer

Add `ignore_errors: yes` to the health check task so the playbook continues despite the failure.

Answer

Remove the health check task to allow the update to proceed without interruption.

Answer

Set `max_fail_percentage: 20` to allow up to one failure per update run.