EX280 Troubleshooting And Diagnostics Practice Test 3 — 15 Questions

Question 1

An administrator needs to collect cluster-wide diagnostic information from an OpenShift 4.14 cluster for a Red Hat support case. Which command should be executed?

Accepted Answer

oc adm must-gather. `oc adm must-gather` is the official OpenShift command that collects cluster-wide diagnostic data — including clusteroperator status, pod logs, events, and resource definitions — into a tarball suitable for Red Hat support. It is the standard first step for any support case and is documented as such in the OpenShift support workflow.

Answer

oc adm diagnose

Answer

oc cluster-info dump

Answer

oc get clusteroperators -o yaml

Question 2

An application pod is failing its liveness probe and continuously restarting. Where can an administrator quickly check the reason for the liveness probe failure?

Accepted Answer

oc describe pod . The `oc describe pod ` command shows detailed information about the pod, including events and container statuses. When a liveness probe fails, the events section typically records the probe failure and the reason, such as connection refused or HTTP status code. This is the quickest way to diagnose the issue.

Answer

oc get routes

Answer

oc get pod <pod-name> -o json

Answer

oc adm diagnostics

Question 3

An administrator notices that the Cluster Version Operator (CVO) is blocked during an upgrade because a cluster operator is missing version annotations. Which command allows checking the current status and payload version of the CVO?

Accepted Answer

oc get clusterversion. 'oc get clusterversion' displays the ClusterVersion resource, which shows the current cluster version, the desired version, the upgrade channel, and the status of the CVO — including conditions like Failing, Progressing, and Available. This is the command that reveals whether the CVO is blocked and what payload version it is targeting.

Answer

oc adm upgrade status

Answer

oc get clusteroperators

Answer

oc version

Question 4

A pod fails to start with a 'CreateContainerConfigError' error message. What is the most common cause of this error that an administrator should investigate?

Accepted Answer

A referenced ConfigMap or Secret in the pod specification does not exist.. `CreateContainerConfigError` occurs when the kubelet cannot create the container's configuration, most commonly because a referenced ConfigMap or Secret in the pod spec (via `envFrom`, `valueFrom`, or volume mounts) does not exist in the namespace. The kubelet fails to resolve the reference and reports this error. Administrators should verify the ConfigMap/Secret names and namespaces.

Answer

The liveness probe timed out before the application started.

Answer

The container image pull policy is set to Always and the registry is down.

Answer

The container exceeded its memory limit upon initialization.

Question 5

An OpenShift cluster's SDN (OVN-Kubernetes) experiences packet loss between nodes. The administrator needs to inspect the Open vSwitch (OVS) flow tables on a specific worker node. How should they access the node to run 'ovs-ofctl dump-flows'?

Accepted Answer

oc debug node/ -- chroot /host ovs-ofctl dump-flows br-int. To inspect OVS flow tables on a specific node, the administrator must run 'ovs-ofctl' inside the node's host network namespace. 'oc debug node/ -- chroot /host ' starts a debug pod on the node, chroots into the host filesystem, and runs the command with access to the host's OVS binaries and sockets — which is exactly what 'ovs-ofctl dump-flows br-int' requires.

Answer

oc adm diagnostics ovs

Answer

oc exec daemonset/ovn-controller -- ovs-ofctl dump-flows

Answer

oc rsh daemonset/ovnkube-node

Question 6

A container inside a pod is failing with 'ImagePullBackOff'. The administrator verifies the image tag exists. What is the next most logical troubleshooting step to check authentication or registry access?

Accepted Answer

Check if a pull secret is correctly configured and bound to the service account.. ImagePullBackOff with a verified image tag almost always indicates an authentication or registry-access problem, so the next step is to verify that a pull secret is correctly configured and bound to the service account used by the pod. OpenShift uses the service account's imagePullSecrets to authenticate to private registries, and a missing or misbound secret causes the kubelet to fail the pull.

Answer

Inspect the etcd cluster operator status.

Answer

Run 'oc debug' to inspect the container file system.

Answer

Restart the cluster version operator.

Question 7

During a troubleshooting session on a degraded cluster operator, an administrator finds that the operator's operand configuration is controlled by a Custom Resource (CR). Where is the most reliable place to look for error status messages reported by the operator controller loop regarding this CR?

Accepted Answer

The status field of the specific Custom Resource instance (e.g., 'oc get

-o yaml').. Operator controllers reconcile a Custom Resource and write observed state, conditions, and error messages back into the CR's status field. The most reliable place to see controller-reported errors is the status subresource of that specific CR instance, typically viewed with 'oc get

-o yaml'. This reflects the controller's own view of the operand's health and any reconciliation failures.

Answer

The default Kubernetes events in the default namespace.

Answer

The global clusterversion object status conditions.

Answer

The /var/log/messages file on the master nodes.

Question 8

An administrator wants to verify if all required cluster operators are available and not degraded after an installation. Which command provides this summary?

Accepted Answer

oc get clusteroperators. The `oc get clusteroperators` command lists all ClusterOperators in an OpenShift cluster, showing their AVAILABLE, PROGRESSING, and DEGRADED status columns. This directly answers whether all required operators are available and not degraded after installation. It is the standard, high-level health check for the operator framework that manages core cluster components.

Answer

oc adm cluster-status

Answer

oc get nodes

Answer

oc get pods --all-namespaces

Question 9

An application pod is running, but HTTP requests to the service are returning '502 Bad Gateway'. The administrator wants to check if the endpoints controller has populated the Service with active pod IP addresses. Which command verifies this?

Accepted Answer

oc get endpoints my-service. The Endpoints object is what the endpoints controller populates with the IP addresses and ports of pods that match a Service's selector. Running 'oc get endpoints my-service' shows whether the Service has active backend pod IPs; if the endpoints list is empty, the Service selector does not match any ready pods, which is a common cause of 502 errors from the router.

Answer

oc get svc my-service

Answer

oc describe ingress

Answer

oc get routes my-route

Question 10

An OpenShift cluster node has experienced kernel panics due to a faulty third-party kernel module. The administrator needs to review the kernel crash logs (vmcore or kdump logs) stored on the node. Where are these logs typically written on a CoreOS worker node?

Accepted Answer

/var/crash. On CoreOS worker nodes, kernel crash dumps (vmcore) and kdump logs are typically stored in /var/crash. This directory is the default location for kdump to save vmcore files when a kernel panic occurs. Administrators can inspect this directory to analyze the crash.

Answer

/run/log/journal

Answer

/var/lib/kubelet/pods

Answer

/var/log/audit/audit.log

Question 11

The 'dns' ClusterOperator is reporting Degraded=True because CoreDNS pods are failing health checks. The administrator suspects DNS request loops or upstream forwarding failures. Which log source is most effective for diagnosing CoreDNS resolution errors?

Accepted Answer

oc logs -n openshift-dns -l dns.operator.openshift.io/daemonset-dns=default. In OpenShift 4.x, CoreDNS runs as a DaemonSet in the openshift-dns namespace, and its pods are labeled with `dns.operator.openshift.io/daemonset-dns=default`. The most direct way to view CoreDNS resolution errors is to fetch logs from those pods using a label selector, which is exactly what option D does. This targets the actual DNS pods rather than the operator or a non-existent kube-dns deployment.

Answer

oc logs -n kube-system deployment/kube-dns

Answer

journalctl -u coredns

Answer

oc logs -n openshift-network-operator deployment/network-operator

Question 12

An administrator is troubleshooting a certificate expiration issue that has broken communication between the kubelet and the API server. Where are the kubelet client certificates stored on a worker node that can be inspected via an oc debug session?

Accepted Answer

/var/lib/kubelet/pki/. On a worker node, kubelet client certificates used to authenticate to the API server are stored under /var/lib/kubelet/pki/. This directory contains kubelet-client-current.pem and related files. Inspecting this path via 'oc debug node/<node>' confirms certificate presence, expiry, and rotation state, which is directly relevant to kubelet-to-API-server communication failures.

Answer

/var/lib/etcd/cert

Answer

/etc/origin/node/certificates

Answer

/etc/kubernetes/pki

Question 13

An administrator notices that the Ingress Operator is failing to deploy routers because of a persistent validation error in the Default IngressController resource. How can the administrator inspect the exact validation schema failure reported by the operator?

Accepted Answer

oc describe ingresscontroller default -n openshift-ingress-operator. The Ingress Operator reports validation errors in the status of the IngressController custom resource. Using `oc describe ingresscontroller default -n openshift-ingress-operator` displays the resource's status conditions, including the exact validation failure message from the operator. This is the direct way to inspect schema validation errors reported by the operator.

Answer

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

Answer

oc adm inspect router

Answer

oc get validatingwebhookconfigurations

Question 14

An administrator needs to check the IP address and network status assigned to a running pod. Which command displays this information quickly?

Accepted Answer

oc get pod -o wide. The command `oc get pod -o wide` extends the default tabular output to include additional columns such as the pod's IP address and the node it is running on. This is the fastest way to retrieve the IP address of a running pod without needing to inspect detailed YAML or describe output. It directly answers the question by displaying the assigned IP in a concise, readable format.

Answer

oc ip pod <pod-name>

Answer

oc describe pod <pod-name> --network

Answer

oc get network-attachment-definitions

Question 15

An administrator wants to view the last 50 lines of logs for a pod named 'api-server-xyz' and keep the stream open for new log entries. Which command should they use?

Accepted Answer

oc logs api-server-xyz --tail=50 -f. 'oc logs api-server-xyz --tail=50 -f' retrieves the last 50 lines and then follows the stream, printing new entries as they arrive. The --tail flag limits historical output, and -f (short for --follow) keeps the connection open. This is the standard pattern for live-tailing pod logs in OpenShift.

Answer

oc describe pod api-server-xyz --lines=50

Answer

oc logs api-server-xyz --lines=50 --follow

Answer

oc tail api-server-xyz -n 50