EX280 Troubleshooting And Diagnostics Practice Test 5 — 15 Questions

Question 1

An administrator notices that the 'storage' ClusterOperator is degraded. Which TWO resources or logs should be inspected to diagnose the underlying CSI driver or provisioner failure? (Choose TWO)

Accepted Answer

oc describe clusteroperator storage. Option B is correct because `oc describe clusteroperator storage` surfaces the ClusterOperator's status conditions, related objects, and the specific reason/message for the degraded state, which typically points to the failing CSI driver or provisioner component. Option D is correct because the cluster-storage-operator deployment in the openshift-cluster-storage-operator namespace manages the storage operators (including CSI driver operators), so its logs reveal reconciliation errors and the underlying cause of the degradation. Option A is not relevant since the openshift-apiserver logs concern API server behavior, not storage provisioning. Option C is unrelated because routes expose services and have no bearing on CSI driver failures. Option E is also unrelated, as clusterversion tracks OpenShift version and update status rather than storage subsystem diagnostics.

Answer

oc logs -n openshift-apiserver deployment/openshift-apiserver

Answer

oc get routes --all-namespaces

Answer

oc describe clusterversion

Question 2

An OpenShift cluster node is reporting High CPU and Memory pressure. Which THREE commands or tools can an administrator use to investigate resource bottlenecks on that node? (Choose THREE)

Accepted Answer

oc describe node . Option A, `oc describe node `, is correct because it surfaces the node's Conditions (MemoryPressure, DiskPressure, PIDPressure), Allocatable vs Capacity, and the resource requests/limits of every scheduled pod, which directly reveals what is consuming the node. Option B, `oc adm top nodes`, is correct because it queries the metrics pipeline (metrics-server) to show live CPU and memory usage and percentage per node, giving an immediate quantitative view of the bottleneck. Option E, `oc debug node/ -- chroot /host top`, is correct because it launches a privileged debug pod on the node, chroots into the host filesystem, and runs `top` against the host's processes, exposing the actual OS-level consumers of CPU and memory. Option C, `oc get events --namespace=default`, is not appropriate because events are namespaced and scoped to workloads in that namespace, not node-level resource pressure. Option D, `oc logs deployment/cluster-version-operator`, is not appropriate because CVO logs concern cluster version upgrades and reconciliation, not node resource bottleneck diagnosis.

Answer

oc get events --namespace=default

Answer

oc logs deployment/cluster-version-operator

Question 3

An administrator is troubleshooting a deployment where pods fail to pull container images. Which TWO potential issues should be checked? (Choose TWO)

Accepted Answer

The image pull secret is missing or misconfigured in the service account.. Option B is correct because image pulls from private registries require valid credentials, and if the imagePullSecret referenced by the pod's service account is missing or has wrong registry credentials, the kubelet will fail with ImagePullBackOff or ErrImagePull. Option E is correct because a typo in the image repository path or a nonexistent tag (e.g., myapp:v2 when only v1 exists) causes the registry to return a manifest-not-found error, which also surfaces as ImagePullBackOff. Option A does not belong because a Pending PVC affects volume mounting and pod scheduling, not the image pull phase. Option C does not belong because an invalid route hostname is an OpenShift networking issue affecting external access, not kubelet image retrieval. Option D does not belong because a short liveness probe timeout causes container restarts after startup, not image pull failures.

Answer

The PersistentVolumeClaim is stuck in Pending.

Answer

The route hostname is invalid.

Answer

The liveness probe timeout is configured too short.

Question 4

An administrator needs to troubleshoot DNS resolution failures inside an application namespace. Which THREE resources or commands should they check? (Choose THREE)

Accepted Answer

oc logs -n openshift-dns -l dns.operator.openshift.io/daemonset-dns=default. Option B is correct because the CoreDNS pods in OpenShift run in the openshift-dns namespace under the daemonset labeled dns.operator.openshift.io/daemonset-dns=default, so `oc get logs` with that label selector reveals CoreDNS errors, plugin failures, or resolution issues affecting the application namespace. Option C is correct because the DNS ClusterOperator reports the overall health, availability, and degraded conditions of the cluster DNS service, quickly indicating whether the DNS operator itself is failing. Option E is correct because launching an interactive debug pod and running `nslookup` or `dig` against the cluster DNS service (for example, the kube-dns service IP) directly tests whether name resolution works from inside the cluster network. Option A is not relevant because MachineSets manage cluster nodes, not DNS resolution. Option D is not relevant because the IngressController resource governs router/ingress behavior, not internal DNS lookups.

Answer

oc get machineset

Answer

oc describe ingresscontroller default

Question 5

An administrator wants to check cluster networking and SDN communication. Which TWO commands can be used to gather network-related diagnostic information? (Choose TWO)

Accepted Answer

oc get clusteroperator network. Option A, `oc get clusteroperator network`, is correct because it reports the status, availability, and conditions of the OpenShift SDN/OVN-Kubernetes network operator, which directly reflects cluster networking and SDN health. Option D, `oc logs -n openshift-ovn-kubernetes -l app=ovnkube-node`, is correct because it retrieves logs from the ovnkube-node pods in the openshift-ovn-kubernetes namespace, providing detailed SDN/OVN diagnostic information about node-level networking. Option B, `oc get routes`, only lists OpenShift route objects for exposing services and does not diagnose cluster networking or SDN communication. Option C, `oc adm top volume`, reports volume usage statistics and is unrelated to network diagnostics. Option E, `oc describe pvc`, shows details about a PersistentVolumeClaim and its binding/storage status, not SDN or network information.

Answer

oc get routes

Answer

oc adm top volume

Answer

oc describe pvc

Question 6

An administrator is diagnosing why an authentication token exchange is failing for cluster users. Which THREE sources provide relevant error logs and status information? (Choose THREE)

Accepted Answer

oc logs -n openshift-kube-apiserver pod/kube-apiserver-<node-name>. Option B is correct because the kube-apiserver logs in the openshift-kube-apiserver namespace record authentication and token exchange activity, including OAuth token review and authentication errors, making them a primary source for diagnosing token exchange failures. Option D is correct because 'oc describe clusteroperator authentication' shows the status, conditions, and messages of the authentication ClusterOperator, which reveal whether the OAuth server and related authentication components are degraded or failing. Option E is correct because the oauth-openshift deployment in the openshift-authentication namespace runs the OpenShift OAuth server that issues and exchanges tokens, so its logs directly capture token exchange errors. Option A is not relevant because the ingress-operator logs concern ingress controller management, not authentication token exchange. Option C is not relevant because listing namespaces only shows namespace existence and status, providing no authentication error details.

Answer

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

Answer

oc get namespaces

Question 7

An OpenShift cluster upgrade has failed because a MachineConfigPool is degraded. Which THREE actions or commands can an administrator perform to diagnose the root cause of the MachineConfigPool degradation? (Choose THREE)

Accepted Answer

oc logs -n openshift-machine-config-operator daemonset/machine-config-daemon. Option E is correct because `oc describe machineconfigpool ` shows the pool's status conditions, including Degraded, Updated, Updating, and the reason/message fields that identify why the pool is degraded. Option C is correct because listing MachineConfigs with the label `machineconfiguration.openshift.io/role=` shows the rendered and role-specific configs applied to that pool, helping spot a bad or mismatched MachineConfig. Option A is correct because `oc logs -n openshift-machine-config-operator daemonset/machine-config-daemon` retrieves the Machine Config Daemon logs, where the actual node-level failure (e.g., failed systemd unit, file write, or reboot issue) is recorded. Option B is wrong because scaling the cluster-version-operator deployment does not diagnose a degraded MachineConfigPool and is not a supported troubleshooting step. Option D is wrong because `oc adm upgrade cancel` only cancels an in-progress cluster upgrade and does not reveal the root cause of the MachineConfigPool degradation.

Answer

oc scale deployment/cluster-version-operator --replicas=3

Answer

oc adm upgrade cancel

Question 8

During etcd troubleshooting, an administrator suspects quorum loss or follower synchronization issues. Which THREE commands or etcdctl actions performed inside an etcd pod can verify etcd health and cluster state? (Choose THREE)

Accepted Answer

etcdctl endpoint status. Option C, `etcdctl endpoint status`, is correct because it queries each endpoint and returns the member ID, raft term, raft index, leader ID, and whether the endpoint is a leader or follower, which directly reveals quorum and follower synchronization state. Option D, `etcdctl member list`, is correct because it enumerates all cluster members with their IDs, peer URLs, client URLs, and names, allowing the administrator to confirm the expected member count and detect missing or unhealthy members that would cause quorum loss. Option E, `etcdctl endpoint health`, is correct because it probes each endpoint and reports whether the endpoint is healthy and able to respond, which is the standard way to verify etcd health across the cluster. Option A, `etcdctl snapshot restore`, is not a verification action; it rebuilds a new data directory from a snapshot and is used for recovery, not for checking health or cluster state. Option B, `etcdctl defrag`, is not a verification action either; it compacts the backend database to reclaim space and can temporarily block reads, so it does not report health or cluster membership.

Answer

etcdctl snapshot restore

Answer

etcdctl defrag

Question 9

An administrator notices that a node has been automatically cordoned and drained by the cluster. Which THREE places should the administrator inspect to find the reason for the node eviction or failure? (Choose THREE)

Accepted Answer

oc describe node . Option B, `oc describe node `, is correct because the node's status conditions (such as Ready, MemoryPressure, DiskPressure, PIDPressure) and the associated events/taints like node.kubernetes.io/not-ready or node.kubernetes.io/unreachable reveal why the node was cordoned and drained. Option C, journalctl logs for the kubelet service on the affected node, is correct because the kubelet is the component that reports node status and applies eviction/taints; its logs contain the precise errors (e.g., failed to update node status, container runtime failures, certificate or resource issues) behind the eviction. Option E, `oc get events --field-selector reason=Evicted`, is correct because it filters cluster events specifically for the Evicted reason, showing which pods were evicted, from which node, and the eviction message (e.g., The node was low on resource: memory). Options A and D are incorrect because `oc get storageclass` and `oc get ingresscontroller` list storage and ingress configuration objects, which are unrelated to node cordon/drain/eviction diagnostics.

Answer

oc get storageclass

Answer

oc get ingresscontroller

Question 10

An OpenShift cluster operator is stuck in a Progressing state during an update. Which THREE diagnostic steps help determine why the operator reconciliation loop is blocked? (Choose THREE)

Accepted Answer

Check cluster-wide events related to the operator namespace.. Option B is correct because cluster-wide events (e.g., oc get events -n openshift-) reveal scheduling failures, image pull errors, RBAC denials, or dependency issues that can stall the operator's reconciliation loop. Option C is correct because the operator deployment's pod logs in its openshift-* namespace show the actual reconciliation errors, failed API calls, or exceptions the controller is hitting while trying to progress. Option D is correct because inspecting the Custom Resource's status conditions (e.g., oc get -o yaml) exposes the operator's own reported state, including Degraded/Progressing reasons and messages that pinpoint the blocking condition. Option A is not appropriate because rebooting all control plane nodes simultaneously causes an outage and does not diagnose the reconciliation issue. Option E is not appropriate because deleting persistent volumes destroys data and is unrelated to diagnosing why an operator is stuck Progressing.

Answer

Reboot all control plane nodes simultaneously.

Answer

Delete all persistent volumes in the cluster.

Question 11

An administrator wants to check the status of all api-server instances in the cluster. Which TWO commands are helpful? (Choose TWO)

Accepted Answer

oc get pods -n openshift-kube-apiserver. Option B, `oc get pods -n openshift-kube-apiserver`, is correct because in OpenShift the static api-server pods run in the `openshift-kube-apiserver` namespace, so listing pods there shows the running status of each kube-apiserver instance. Option C, `oc get clusteroperator kube-apiserver`, is correct because the `kube-apiserver` ClusterOperator reports the aggregated availability, progressing, and degraded status of the API server across the cluster. Option A, `oc get storageclass`, only lists storage classes and has nothing to do with API server health. Option D, `oc adm top storage`, is not a valid command for checking API server instances (top subcommands target nodes/pods). Option E, `oc get routes --all-namespaces`, lists OpenShift routes and is unrelated to api-server status.

Answer

oc get storageclass

Answer

oc adm top storage

Answer

oc get routes --all-namespaces

Question 12

An administrator wants to inspect cluster events filtered by warning type. Which TWO commands or techniques can help? (Choose TWO)

Accepted Answer

oc describe pod (to view recent warning events for that pod).. Option B, `oc get events --field-selector type=Warning`, is correct because the `--field-selector` flag on `oc get events` filters the returned Event objects server-side by their `type` field, and `Warning` is the exact value used for warning-type events in Kubernetes/OpenShift. Option A, `oc describe pod `, is correct because `describe` renders the pod's status and appends the related Events section, which surfaces recent warning events (e.g., FailedScheduling, BackOff) tied to that specific pod. Option C, `oc get clusterversion --warnings`, is not a valid flag for that command and does not filter events by type. Option D, `oc logs --warnings`, is invalid because `oc logs` streams container logs and has no `--warnings` flag. Option E, `oc adm must-gather --warnings-only`, is not a real flag; must-gather collects diagnostic data and does not filter events by warning type.

Answer

oc get clusterversion --warnings

Answer

oc logs --warnings

Answer

oc adm must-gather --warnings-only

Question 13

An administrator wants to verify node health and readiness across the cluster. Which TWO commands provide this information? (Choose TWO)

Accepted Answer

oc describe node . Option A, `oc describe node `, is correct because it dumps the full node object status, including Conditions such as Ready, MemoryPressure, DiskPressure, and PIDPressure, plus allocated resources, taints, and recent events — exactly the per-node health and readiness detail an administrator needs. Option B, `oc get nodes`, is correct because it lists every node in the cluster with its STATUS (Ready/NotReady/SchedulingDisabled), ROLES, AGE, and VERSION, giving a fast cluster-wide readiness overview. Option C, `oc get clusterversion`, only reports the OpenShift cluster version and update channel, not node health. Option D, `oc get routes`, lists exposed routes and their hosts/admission status, which is application networking, not node state. Option E, `oc adm top volume`, shows volume usage statistics, not node readiness or conditions.

Answer

oc get clusterversion

Answer

oc get routes

Answer

oc adm top volume

Question 14

An administrator needs to troubleshoot why an OLM (Operator Lifecycle Manager) managed operator installation is failing. Which THREE resources should be inspected? (Choose THREE)

Accepted Answer

oc get subscription . Option A, `oc get subscription `, is correct because the Subscription is the OLM resource that declares which operator and channel to install and records the resolution state, so its status reveals whether the operator was resolved and any resolution failures. Option B, `oc get installplan`, is correct because the InstallPlan is generated by OLM to enumerate the CSVs and approval requirements needed to install or upgrade an operator, and its status shows whether the plan is pending approval or has failed to execute. Option E, `oc get csv`, is correct because the ClusterServiceVersion represents the actual running operator deployment and its status/phase (e.g., Failed, Pending) exposes installation errors such as unmet dependencies or failed deployments. Option C, `oc get routes`, is not relevant because Routes only expose services externally and are not part of the OLM installation pipeline. Option D, `oc get pv`, is not relevant because PersistentVolumes relate to storage provisioning and are not OLM installation resources unless a specific storage issue is already suspected.

Answer

oc get routes

Answer

oc get pv

Question 15

An administrator is troubleshooting a pod that is repeatedly restarting in the 'app-prod' namespace. The pod's restart count is high, and the administrator needs to determine the exit code of the last terminated container to identify whether the process exited due to an application error or was killed by the OOM killer. Which single command provides this information most directly?

Accepted Answer

oc get pod -n app-prod <pod-name> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'. The pod's status object contains containerStatuses with lastState.terminated, which records the exit code and reason for the most recent terminated container instance. Querying that field with jsonpath returns the exact exit code, allowing the administrator to distinguish an OOM kill (commonly exit code 137) from an application error (other exit codes). This is more precise than logs or describe output because it reads the authoritative status field directly.

Answer

oc logs -n app-prod <pod-name> --previous

Answer

oc describe pod -n app-prod <pod-name>

Answer

oc exec -n app-prod -- cat /var/log/containers/.log