EX280 Practice Test 30 — 15 Questions

Question 1

An administrator is troubleshooting a pod that fails to schedule and remains in `Pending` state. The administrator runs `oc describe pod` and sees the event `0/9 nodes are available: 9 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.` What is the most likely cause?

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

Accepted Answer

The pod does not have a toleration for the master node taint, so it cannot be scheduled on master nodes.. The event message directly indicates that the scheduler could not place the pod because all nodes had a taint that the pod did not tolerate. In OpenShift, master nodes carry the `node-role.kubernetes.io/master` taint by default, so regular pods must either target worker nodes or include a toleration. The other options would produce different event messages, making the taint explanation the clear cause.

Answer

The pod's resource requests exceed the capacity of all nodes.

Answer

The pod's node selector does not match any node labels.

Answer

The pod is using a PersistentVolumeClaim that cannot be bound.

Question 2

An administrator must determine why a namespace named 'batch' is stuck in the Terminating state and has remained so for over an hour. They need to identify what is blocking finalization so it can be cleared. (Choose two.)

Accepted Answer

Inspect the namespace's spec.finalizers field to see which finalizer entry is still present.. A namespace lingers in Terminating only while its spec.finalizers list is non-empty, and the namespace controller holds that finalizer until every namespaced object is gone. The two productive checks are reading the namespace's finalizers to confirm the condition and enumerating surviving API objects to find the resource whose own finalizer is never being cleared, which is typically a custom resource or a Pod.

Answer

Delete the namespace's ServiceAccount tokens with 'oc delete secret --all' in the namespace.

Answer

Patch the namespace status subresource to set phase to Active so deletion can resume.

Answer

Restart the kube-controller-manager static pod on the control plane node hosting the namespace controller leader.

Question 3

An administrator is managing a DeploymentConfig named frontend in an OpenShift 4.14 cluster. The DeploymentConfig has a ConfigChange trigger enabled. The administrator needs to update the container image in the DeploymentConfig without triggering an automatic rollout, so that multiple changes can be made before a manual rollout. Which action should the administrator take?

Accepted Answer

Run oc rollout pause dc/frontend, make the changes, then run oc rollout resume dc/frontend.. Pausing a DeploymentConfig with oc rollout pause is the standard method to temporarily prevent rollouts from starting, even when triggers fire. This allows an administrator to make multiple changes and then resume the rollout to apply them all at once. It is a reversible and non-destructive operation that does not alter the trigger configuration.

Answer

Run oc rollout cancel dc/frontend before making changes, then run oc rollout latest dc/frontend after changes.

Answer

Run oc edit dc/frontend and change the triggers section to disable the ConfigChange trigger, then apply the change.

Answer

Run oc set triggers dc/frontend --remove --from-config, make the changes, then re-add the trigger.

Question 4

A developer has built a container image and pushed it to an external registry. They now want to deploy this image as a new application in an OpenShift 4.14 project. Which oc command should they use to create a Deployment that runs the image and exposes it with a Service?

Accepted Answer

oc new-app --docker-image=myregistry.com/myimage:latest. The oc new-app command is designed to quickly create applications from various sources, including external container images. Using the --docker-image flag allows specifying an image from an external registry, and new-app automatically creates the necessary Deployment and Service resources, and may create a Route if applicable.

Answer

oc apply -f deployment.yaml --image=myregistry.com/myimage:latest

Answer

oc new-app --image-stream=myimage:latest

Answer

oc create deployment myapp --image=myregistry.com/myimage:latest

Question 5

An administrator is troubleshooting an OpenShift Container Platform 4.14 cluster that is failing to upgrade. The Cluster Version Operator (CVO) reports that the upgrade is blocked due to an unhealthy ClusterOperator. Which TWO commands should the administrator use to identify the specific ClusterOperator and its error condition? (Choose two.)

Accepted Answer

oc describe clusteroperator . To identify the unhealthy ClusterOperator, the administrator should first list all ClusterOperators with 'oc get clusteroperators' to spot the one with a degraded or unavailable status. Then, 'oc describe clusteroperator ' provides in-depth details, including conditions and events, to pinpoint the root cause. The other commands are either too broad or focus on the CVO rather than the specific operator.

Answer

oc get clusterversion

Answer

oc logs -n openshift-cluster-version cluster-version-operator-<pod>

Answer

oc get pods -n openshift-cluster-version

Question 6

An administrator is diagnosing an application pod that repeatedly restarts. The pod's container shows a Completed exit with code 0 in its last termination state, yet Kubernetes restarts it anyway. The Deployment specifies 'restartPolicy: Always'. What is the correct interpretation?

Accepted Answer

Exit code 0 with restartPolicy Always means the container finished its work; the administrator should switch the workload to a Job.. restartPolicy Always instructs the kubelet to restart a container whenever it exits, regardless of exit code. A container that completes successfully with code 0 inside such a pod will be restarted forever, producing a rising restart count and a misleadingly healthy status. The workload type, not the exit code, determines whether this is expected.

Answer

The restart count is a cosmetic counter that resets on each node reboot and can be ignored if the pod is Ready.

Answer

Exit code 0 indicates a successful shutdown, so Kubernetes should not restart it; the observed restarts must come from a liveness probe failure.

Answer

The container is being OOMKilled; exit code 0 is the kubelet's translation of an out-of-memory termination.

Question 7

An administrator suspects a pod named 'cache-0' in namespace 'data' is being evicted due to node memory pressure. They want to confirm the eviction reason and see the kubelet's decision. Which command most directly provides the eviction evidence?

Accepted Answer

oc get pod cache-0 -n data -o jsonpath='{.status.reason} {.status.message}'. The kubelet records an eviction by updating the pod's status with reason Evicted and a message identifying the exhausted resource. Querying those status fields with JSONPath or reading the pod YAML yields unambiguous evidence, whereas logs, node conditions, and metrics each describe adjacent signals without tying the specific pod's termination to memory pressure.

Answer

oc describe node <node> | grep -i pressure

Answer

oc adm top pod cache-0 -n data --containers

Answer

oc logs cache-0 -n data --previous

Question 8

An administrator manages a Deployment named payments-api in the project finance-prod. During a maintenance window, changes to the pod template must be staged without any new pods being created. Once all edits are complete, a single rollout should start. Which oc command should the administrator run first?

Accepted Answer

oc rollout pause deployment/payments-api. Pausing a Deployment suspends the rollout controller, so multiple pod-template edits accumulate in the Deployment spec without creating intermediate ReplicaSets or pods. When the Deployment is resumed with oc rollout resume, OpenShift performs a single rollout reflecting all staged changes. Reporting status, undoing a revision, or scaling to zero all fail to suppress rollout creation and therefore do not meet the staged-change requirement.

Answer

oc rollout undo deployment/payments-api

Answer

oc rollout status deployment/payments-api

Answer

oc scale deployment/payments-api --replicas=0

Question 9

An administrator is preparing to upgrade an OpenShift Container Platform 4.14 cluster from version 4.13.12 to 4.14.6. Before starting the upgrade, the administrator wants to ensure that all cluster Operators are healthy and that no prerequisites are blocking the upgrade. Which command should the administrator run to view the current upgrade status and any available updates?

Accepted Answer

oc adm upgrade. The `oc adm upgrade` command is designed to show the current cluster version, any available updates, and conditions that might prevent an upgrade. It provides a concise summary that helps administrators decide whether to proceed. Before upgrading, it is essential to confirm that all ClusterOperators are available and not degraded, and that no upgrade blockers exist. This command directly surfaces that information.

Answer

oc get nodes -o wide

Answer

oc describe clusteroperators

Answer

oc get clusterversion version -o yaml

Question 10

An administrator is troubleshooting a node that is reporting `NotReady` in an OpenShift cluster. The administrator runs `oc get nodes` and sees the node's status as `NotReady,SchedulingDisabled`. Which command should the administrator use to view the node's conditions and determine the specific reason for the NotReady state?

Accepted Answer

oc describe node <node-name>. When a node is NotReady, the most efficient way to see why is to inspect its conditions. The oc describe node command presents these conditions in a readable format, including the Ready condition's status, reason, and message, along with any taints and recent events. This allows the administrator to quickly pinpoint issues like kubelet not posting status or network plugin problems.

Answer

oc get node <node-name> -o yaml

Answer

oc adm top node <node-name>

Answer

oc logs -n openshift-node <node-name>

Question 11

An administrator is defining a StorageClass that should use the CSI driver 'csi.example.com' and allow volume expansion. The StorageClass must also have a parameter 'type: fast'. Which YAML snippet correctly defines this StorageClass?

Accepted Answer

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: csi.example.com
allowVolumeExpansion: true
parameters:
  type: fast. A StorageClass for a CSI driver must set the provisioner field to the CSI driver name. The allowVolumeExpansion field enables PVC expansion, and parameters pass driver-specific settings. The correct snippet includes these without extraneous fields that could alter behavior or are not requested.

Answer

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/csi
allowVolumeExpansion: true
parameters:
  driver: csi.example.com
  type: fast

Answer

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: csi.example.com
allowVolumeExpansion: true
parameters:
  type: fast
volumeBindingMode: WaitForFirstConsumer

Answer

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: csi.example.com
allowVolumeExpansion: true
parameters:
  type: fast
reclaimPolicy: Delete

Question 12

A developer needs to mount an existing PersistentVolumeClaim into a pod, but the application requires that the volume be mounted read-only to prevent accidental writes. The PVC was created with accessMode ReadWriteOnce. Which configuration in the pod's volumeMounts is correct?

Accepted Answer

Set readOnly: true in the volumeMounts section for that volume.. To mount a volume read-only in a pod, set readOnly: true in the volumeMounts entry for that volume within the container. This is independent of the PVC's access mode. The access mode governs how many nodes can mount the volume and whether they can write, but the pod-level readOnly flag enforces read-only at the mount point for that container.

Answer

Set readOnly: true in the PersistentVolume's spec.

Answer

Change the PVC's accessMode to ReadOnlyMany.

Answer

Set readOnly: true in the pod's volumes section for that volume.

Question 13

A team runs a Deployment named catalog-api in project retail. After a configuration change, pods crash with an application error, and the administrator needs to return the Deployment to the last known-good revision. The administrator runs oc rollout history deployment/catalog-api and sees revision 7 as the current one. Which single command restores the previous working revision?

Accepted Answer

oc rollout undo deployment/catalog-api --to-revision=6. Deployment revisions are retained in the controller's ReplicaSet history, so the last known-good pod template can be restored by undoing to a specific revision. Using the undo subcommand with the revision number that preceded the failure reinstates that template and starts a rollout, bringing the application back without manual manifest edits or loss of history.

Answer

oc delete deployment/catalog-api && oc apply -f catalog-api-backup.yaml

Answer

oc rollout restart deployment/catalog-api

Answer

oc set image deployment/catalog-api catalog-api=registry.example.com/catalog-api:previous

Question 14

A cluster administrator is preparing a PersistentVolume for a database that must survive node failures and be reattached to a rescheduled pod. The storage backend is a CSI driver that supports topology-aware provisioning. Which access mode should the administrator specify in the PersistentVolumeClaim to allow the volume to be mounted as read-write by a single node at a time?

Accepted Answer

ReadWriteOnce. ReadWriteOnce grants read-write access to a single node, letting the CSI driver detach and reattach the volume when the pod moves to a healthy node. This balances write exclusivity with failure recovery, unlike ReadOnlyMany, ReadWriteMany, or the pod-scoped ReadWriteOncePod, which either forbid writes or over-constrain attachment.

Answer

ReadWriteMany

Answer

ReadOnlyMany

Answer

ReadWriteOncePod

Question 15

An administrator is troubleshooting why a Pod in namespace `app-a` cannot reach a Pod in namespace `app-b` on TCP port 3306, even though both Pods are Running and the Services resolve correctly. A NetworkPolicy in `app-b` allows ingress only from Pods labeled `tier: frontend` in `app-a`. The source Pod in `app-a` has the label `tier: backend`. What is the most likely cause?

Accepted Answer

The source Pod's label does not match the NetworkPolicy's allowed source selector, so ingress is denied.. NetworkPolicy ingress rules can restrict allowed sources by namespace and Pod label selectors. When a source Pod's labels do not match the allowed selector, its traffic is dropped even if the Pod is healthy and the destination Service resolves. In this case, the source Pod labeled `tier: backend` fails to match the policy's requirement for `tier: frontend`, so the ingress is denied by policy rather than by application or DNS failure.

Answer

The cluster's DNS service is not resolving the destination Service name.

Answer

The destination Pod is not listening on port 3306, so the connection is refused.

Answer

The source namespace `app-a` lacks a matching egress NetworkPolicy allowing traffic to `app-b`.