EX280 Troubleshooting And Diagnostics Practice Test 2 — 15 Questions

Question 1

An administrator notices that a node is marked as 'SchedulingDisabled' (Cordoned). Which command should be executed to allow pods to be scheduled on this node again?

Accepted Answer

oc adm uncordon . The `oc adm uncordon ` command is the correct way to reverse the cordon operation. When a node is cordoned, the Kubernetes scheduler marks it as unschedulable by setting the `spec.unschedulable` field to `true`. The `uncordon` command explicitly sets this field back to `false`, allowing new pods to be scheduled onto the node. This is the standard administrative command for this purpose in OpenShift, built on top of the Kubernetes API.

Answer

oc patch node <node-name> --type=json -p='[{"op": "replace", "path": "/spec/unschedulable", "value": false}]'

Answer

oc adm drain <node-name> --undo

Answer

oc scale node <node-name> --replicas=1

Question 2

A worker node's root filesystem reaches 100% capacity due to accumulated container images and logs, causing the kubelet to enter an eviction state. After freeing up disk space on the node, the administrator notices the node status remains NotReady. What action is required to clear the kubelet's node pressure condition?

Accepted Answer

Restart the kubelet service on the affected node or reboot the node.. When a node's root filesystem fills up, the kubelet triggers disk pressure eviction and marks the node NotReady. Even after disk space is freed, the kubelet may not automatically clear the pressure condition because its internal state remains stuck; restarting the kubelet service (or rebooting the node) forces it to re-evaluate node conditions and clear the pressure taint, allowing the node to become Ready again. This is a known behavior in OpenShift 4 where kubelet does not always recover from eviction state without a restart.

Answer

Run 'oc adm uncordon' on the node.

Answer

Delete and recreate the clusterversion resource.

Answer

Scale the machineconfigpool to zero and back.

Question 3

An application pod is failing to write data because its mounted PersistentVolume is mounted as ReadOnly. The administrator checks the PVC definition and sees accessMode is set correctly to ReadWriteOnce. What is the most likely cause of the read-only mount?

Accepted Answer

The storage backend experienced an I/O error and remounted the block device as read-only.. When a PVC is correctly set to ReadWriteOnce but the pod still sees a read-only mount, the most likely cause is that the underlying storage backend or node experienced an I/O error and the kernel remounted the filesystem or block device read-only to prevent data corruption. Kubernetes does not automatically change the mount to read-only based on access modes, so the read-only state must originate from the storage layer or kernel. This is a classic symptom of a failed block device or full filesystem triggering ext4/xfs read-only remount.

Answer

The ServiceAccount lacks storage-admin permissions.

Answer

The namespace quota restricts write operations.

Answer

The pod security standard blocked write permissions.

Question 4

An application pod is experiencing intermittent network drops. The administrator wants to capture network packets passing through the pod's interface for analysis. Which tool can be used inside a debugging session attached to the pod namespace?

Accepted Answer

oc debug pod/ -- tcpdump -i any -w /tmp/packet.pcap. The correct command uses 'oc debug' to create a debugging session attached to the pod's namespace, then runs tcpdump inside that session to capture packets on any interface and write to a pcap file. This is the standard OpenShift way to capture network traffic for a pod without installing additional tools on the node. The 'oc debug pod/' command creates a copy of the pod with a shell, and the '--' passes the tcpdump command to run inside.

Answer

oc network capture <pod-name>

Answer

oc exec pod/<pod-name> -- wireshark

Answer

oc adm tcpdump pod/<pod-name>

Question 5

An administrator needs to collect logs from all router pods in the 'openshift-ingress' namespace. Which TWO methods can achieve this? (Choose TWO)

Accepted Answer

oc logs -l ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default -n openshift-ingress. Option A is correct because `oc logs -l ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default -n openshift-ingress` uses a label selector to aggregate logs from all pods matching the ingress controller label in the openshift-ingress namespace, which is exactly how router pods are identified. Option E is correct because `oc logs deployment/router-default -n openshift-ingress` retrieves logs from all pods belonging to the router-default deployment, which is the standard deployment name for the default Ingress Controller's router pods. Option B is incorrect because `oc describe deployment` only shows deployment metadata, events, and status, not container logs. Option C is incorrect because `oc get routes` lists OpenShift Route objects, which is unrelated to collecting pod logs. Option D is incorrect because `oc rsh` opens an interactive shell into a pod rather than collecting logs.

Answer

oc describe deployment router-default -n openshift-ingress

Answer

oc get routes -n openshift-ingress

Answer

oc rsh -n openshift-ingress deployment/router-default

Question 6

An administrator is analyzing a severe networking issue where pod-to-pod communication across different worker nodes fails. Which THREE diagnostic utilities or commands should they execute inside an oc debug session on the nodes? (Choose THREE)

Accepted Answer

tcpdump -i . Option B (tcpdump -i ) is correct because capturing packets on the node's physical or overlay interface lets the administrator verify whether pod-to-pod traffic is actually leaving and arriving at the worker nodes, revealing drops, MTU issues, or missing encapsulation. Option C (ovs-ofctl dump-flows br-int) is correct because OpenShift SDN/OVN-Kubernetes uses Open vSwitch, and inspecting the flow tables on the br-int bridge shows whether the OVS rules correctly forward traffic between pods on different nodes. Option E (ip route show) is correct because cross-node pod communication depends on correct routing entries (e.g., routes to the pod CIDR or tunnel endpoints), so checking the node's routing table confirms whether packets have a valid path to the remote node's pod subnet. Option A (oc adm upgrade status) is unrelated, as it only reports cluster upgrade progress and has no bearing on live pod-to-pod connectivity. Option D (etcdctl endpoint health) checks the health of the etcd datastore, which, while important for the control plane, does not diagnose data-plane forwarding failures between pods on different worker nodes.

Answer

oc adm upgrade status

Answer

etcdctl endpoint health

Question 7

An application pod fails to start because of a volume mount permission error (Permission Denied). Which TWO settings or configurations should an administrator investigate? (Choose TWO)

Accepted Answer

The cluster version operator status.. Checking SecurityContextConstraints (SCCs) and pod security settings (runAsUser, fsGroup) resolves permission denied issues on mounted volumes.

Answer

The ingress router certificate expiration.

Question 8

An administrator needs to troubleshoot an OpenShift Route that returns a '503 Service Unavailable' error. Which THREE resources or objects should be inspected? (Choose THREE)

Accepted Answer

oc describe route <route-name>. Checking the Route configuration, the backing Service endpoints, and the Ingress Controller logs resolves 503 errors.

Answer

oc get clusteroperator etcd

Question 9

An administrator suspects that a memory leak in a system daemon on an RHCOS worker node is causing system instability. Which THREE commands or log sources can be examined via an oc debug node session to investigate system memory consumption? (Choose THREE)

Accepted Answer

chroot /host top -b -n 1. Option A, `chroot /host top -b -n 1`, is correct because entering the host's root filesystem via chroot lets you run the host's `top` in batch mode to capture a snapshot of per-process memory usage (RES, %MEM) on the RHCOS node, which is exactly what's needed to spot a leaking daemon. Option E, `chroot /host free -h`, is correct because it reports the host's overall memory and swap consumption in human-readable units, giving a quick view of total memory pressure on the node. Option D, `journalctl -k -e`, is correct because the kernel ring buffer logs OOM-killer events, allocation failures, and other memory-related kernel messages that reveal which process triggered instability, and `-e` jumps to the end of the journal for the most recent entries. Option B, `oc get pvc`, is not relevant because it only lists PersistentVolumeClaims and says nothing about node memory consumption. Option C, `oc adm cluster-status`, is not a valid command for inspecting node memory (and is not a standard OpenShift memory-diagnostic tool), so it does not belong here.

Answer

oc get pvc

Answer

oc adm cluster-status

Question 10

An OpenShift cluster experiences intermittent API server timeouts. Which THREE log sources or diagnostic commands should an administrator analyze to identify API server performance bottlenecks? (Choose THREE)

Accepted Answer

Audit logs located in /var/log/kube-apiserver/ on control plane nodes.. Option B is correct because the kube-apiserver audit logs written to /var/log/kube-apiserver/ on control plane nodes record every request (including verb, resource, user, and response latency), so they reveal slow or excessive API calls that cause timeouts. Option C is correct because oc logs -n openshift-kube-apiserver pod/kube-apiserver-<node-name> retrieves the kube-apiserver container logs, which expose request-handling errors, watch cache problems, and latency warnings directly tied to API server performance. Option D is correct because etcdctl endpoint health checks the health and responsiveness of the etcd endpoints backing the API server; since slow etcd directly causes API server timeouts, this command isolates storage-layer bottlenecks. Option A is not relevant because oc get routes only lists OpenShift Route objects and does not diagnose API server performance. Option E is not relevant because oc get machineconfigpool shows MachineConfigPool status for node configuration management, not API server or etcd performance data.

Answer

oc get routes

Answer

oc get machineconfigpool

Question 11

An administrator runs `oc get pods -n payments` and sees that the pod `payments-api-7d9f8c6b5-2xqzv` is in `CrashLoopBackOff`. The pod was previously running and then started crashing. Which command should the administrator run FIRST to view the application's standard error output from the current crash?

Accepted Answer

oc logs -n payments payments-api-7d9f8c6b5-2xqzv. The quickest way to see why a container is crashing is to read its standard error output. Running oc logs against the pod without extra flags displays the current container instance's stderr, which contains the fatal error or panic. Other tools like describe show events but not application stack traces, and exec-based commands cannot run when the container is not alive.

Answer

oc describe pod -n payments payments-api-7d9f8c6b5-2xqzv

Answer

oc logs -n payments payments-api-7d9f8c6b5-2xqzv --previous

Answer

oc rsh -n payments payments-api-7d9f8c6b5-2xqzv -- cat /var/log/app.log

Question 12

An administrator is troubleshooting a service that is not routing traffic to its backend pods. The administrator suspects that the service's selector does not match the pods' labels. Which TWO commands can confirm whether the pods have the labels expected by the service? (Choose two.)

Accepted Answer

oc get pods -n <namespace> --show-labels. To diagnose a service selector mismatch, the administrator must compare the service's expected selector with the actual labels on the pods. Extracting the selector with jsonpath and listing pod labels with --show-labels provides both sides of the comparison. Other commands like endpoints or describe show the result of the mismatch but not the label details needed to correct it.

Answer

oc get endpoints -n

Answer

oc get pod -n -o yaml

Answer

oc describe service -n

Question 13

An OpenShift administrator needs to investigate a pod that is failing with an 'OOMKilled' exit code. Which command reveals the memory limit configuration and historical usage right before the crash?

Accepted Answer

oc describe pod . 'oc describe pod ' shows the container's resource requests and limits (including memory limit), the last state with the OOMKilled reason, and the exit code 137. It also displays events and the node the pod ran on, giving the administrator the configuration and crash context in one view. This is the standard first command for diagnosing OOMKilled pods.

Answer

oc top pod <pod-name> --containers

Answer

oc get pod <pod-name> -o yaml

Answer

oc adm diagnostics

Question 14

An administrator is troubleshooting a failing MachineConfig update in an OpenShift cluster. The MachineConfigPool 'worker' is degraded and reports that a node is failing to apply the rendered-worker configuration. Which log stream is critical for determining why the Machine Config Daemon failed to update system files on the target node?

Accepted Answer

oc logs -n openshift-machine-config-operator daemonset/machine-config-daemon. The Machine Config Daemon (MCD) runs as a DaemonSet in the openshift-machine-config-operator namespace and is the component that actually applies rendered MachineConfigs to each node — writing files, updating the kubelet config, and rebooting when required. When a node fails to apply a rendered config, the MCD pod on that node logs the precise failure (e.g., file write errors, systemd unit failures, drain failures). Therefore 'oc logs -n openshift-machine-config-operator daemonset/machine-config-daemon' is the critical log stream.

Answer

oc describe machineconfigpool worker

Answer

oc logs -n openshift-cluster-version-operator deployment/cluster-version-operator

Answer

journalctl -u kubelet -e

Question 15

An administrator wants to view the logs of a specific container named 'backend' inside a pod with multiple containers. Which command should be used?

Accepted Answer

oc logs pod/my-pod -c backend. `oc logs pod/my-pod -c backend` uses the `-c` flag to specify the container name 'backend' within a multi-container pod, which is the correct syntax to retrieve that container's logs. Without `-c`, oc logs would default to the first container or error out, so the flag is required.

Answer

oc logs pod/my-pod backend

Answer

oc rsh pod/my-pod backend

Answer

oc describe pod/my-pod -c backend