Knowledge + Practice

CCNA Troubleshooting And Diagnostics Questions

56 questions · Troubleshooting And Diagnostics · All types, answers revealed

Practice these questions Domain overview All questions

1

MCQhard

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

A.oc adm diagnostics ovs

B.oc debug node/<node-name> -- chroot /host ovs-ofctl dump-flows br-int

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

D.oc rsh daemonset/ovnkube-node

AnswerB

oc debug node/<node-name> launches a privileged pod on the target node, and chroot /host enters the host filesystem where ovs-ofctl and the br-int bridge reside. This grants the host-level access needed to dump OVS flow tables.

Why this answer

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/<node-name> -- chroot /host <command>' 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.

Exam trap

The trap is choosing a command that targets a pod or daemonset (oc exec/rsh) instead of the node itself. OVS runs on the host, not inside a pod, so you must use 'oc debug node/<node> -- chroot /host' to reach the host's OVS binaries and sockets.

How to eliminate wrong answers

Option A is wrong because 'oc adm diagnostics ovs' is not a valid diagnostic subcommand — 'oc adm diagnostics' runs cluster diagnostics but has no 'ovs' target. Option C is wrong because 'oc exec daemonset/ovn-controller' is not valid syntax (oc exec requires a pod, not a daemonset), and even if it worked, the ovn-controller container may not have ovs-ofctl or access to the host OVS socket. Option D is wrong because 'oc rsh daemonset/ovnkube-node' is also invalid syntax (rsh takes a pod) and would land in the ovnkube-node container, which does not have the host's OVS database/socket mounted for ovs-ofctl to query br-int.

Practice this question →

2

Multi-Selecteasy

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

Select 2 answers

A.oc describe pod <pod-name> (to view recent warning events for that pod).

B.oc get events --field-selector type=Warning

C.oc get clusterversion --warnings

D.oc logs --warnings

E.oc adm must-gather --warnings-only

AnswersA, B

oc describe pod surfaces the pod's recent events, including Warning-type entries such as image pull failures, scheduling conflicts or probe errors. This satisfies the stem's requirement to inspect cluster events filtered by warning type for a specific pod.

Why this answer

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 <pod-name>`, 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.

Exam trap

EX280 often tests whether candidates know that events are queried via `oc get events` with field selectors or viewed per-object via `oc describe` — the trap is picking non-existent flags like `--warnings` on `oc logs` or `oc get clusterversion`.

Practice this question →

3

MCQeasy

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

A.oc logs pod/my-pod backend

B.oc rsh pod/my-pod backend

C.oc describe pod/my-pod -c backend

D.oc logs pod/my-pod -c backend

AnswerD

Using `-c backend` selects the named container within the multi-container pod, which is the constraint the stem specifies. Without it, `oc logs` defaults to the first container, returning the wrong output. The `pod/my-pod` resource syntax is valid for OpenShift's `oc logs` command.

Why this answer

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

Exam trap

EX280 often tests the exact flag for selecting a container in a multi-container pod, and candidates frequently omit `-c` or use `oc describe` instead of `oc logs`.

How to eliminate wrong answers

Option A is wrong because `oc logs pod/my-pod backend` treats 'backend' as a second pod argument rather than a container selector, which is invalid syntax. Option B is wrong because `oc rsh pod/my-pod backend` opens an interactive shell in the container, not a log view. Option C is wrong because `oc describe pod/my-pod -c backend` shows pod metadata and events, not container logs, and `-c` is not a valid describe flag for selecting a container's logs.

Practice this question →

4

MCQeasy

An administrator needs to verify which user account or service account they are currently logged into the OpenShift cluster with. Which command provides this information?

A.oc whoami

B.oc user-info

C.oc auth current-user

D.oc get user --current

AnswerA

`oc whoami` queries the OpenShift API server using the current OAuth access token and returns the authenticated identity, satisfying the requirement to confirm which user or service account the session belongs to. It reads the active kubeconfig context, so no cluster-admin rights or additional flags are needed.

Why this answer

The `oc whoami` command displays the currently authenticated user, including the username and, if applicable, the service account. It queries the OpenShift API to return the identity of the current session. This is the standard way to verify the active user context in OpenShift.

Exam trap

EX280 often tests the confusion between valid `oc` commands and non-existent ones, causing candidates to select plausible but invalid commands like `oc user-info` or `oc auth current-user`.

How to eliminate wrong answers

Option B is wrong because `oc user-info` is not a valid OpenShift command; there is no such subcommand. Option C is wrong because `oc auth current-user` is not a valid command; authentication is managed via `oc login` and `oc whoami`. Option D is wrong because `oc get user --current` is not a valid syntax; `oc get user` lists users but does not show the current user, and `--current` is not a supported flag.

Practice this question →

5

MCQhard

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?

A.oc get node <node-name> -o yaml

B.oc adm top node <node-name>

C.oc describe node <node-name>

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

AnswerC

oc describe node provides a concise summary of the node's status, including its conditions such as Ready, MemoryPressure, DiskPressure, and PIDPressure, along with reasons and messages. It also shows taints and recent events. This makes it the most direct command to identify why the node is NotReady, such as a kubelet communication failure or resource pressure.

Why this answer

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.

Exam trap

The trap here is choosing to dump the full node YAML, which contains the data but is cumbersome to parse, instead of using describe which summarizes conditions and events.

Practice this question →

6

MCQeasy

An administrator wants to check the logs of the Cluster Version Operator to see why an upgrade failed. In which namespace does the CVO run?

A.openshift-cluster-version

B.openshift-operator-lifecycle-manager

C.openshift-config-operator

D.kube-system

AnswerA

The Cluster Version Operator runs in the openshift-cluster-version namespace, so its logs are retrieved there. This namespace hosts the CVO deployment that reconciles ClusterVersion resources and orchestrates upgrades, making it the correct place to inspect why an upgrade failed.

Why this answer

The Cluster Version Operator (CVO) runs in the 'openshift-cluster-version' namespace, where it reconciles the ClusterVersion resource and manages cluster upgrades. To diagnose a failed upgrade, an administrator inspects the CVO pod logs in that namespace. This is the canonical location in OpenShift 4 for all cluster version and upgrade activity.

Exam trap

EX280 often tests namespace memorization for OpenShift operators — candidates confuse the CVO namespace with OLM or config-operator namespaces because the names sound similar.

How to eliminate wrong answers

Option B is wrong because 'openshift-operator-lifecycle-manager' hosts OLM components (catalog, olm-operator) that manage Operator subscriptions, not the cluster version upgrade process. Option C is wrong because 'openshift-config-operator' manages the cluster-wide configuration resources (like the 'cluster' ConfigMap), not version upgrades. Option D is wrong because 'kube-system' is the upstream Kubernetes namespace for core components like kube-dns and kube-proxy; OpenShift's CVO is not deployed there.

Practice this question →

7

Multi-Selecteasy

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

Select 2 answers

A.The PersistentVolumeClaim is stuck in Pending.

B.The image pull secret is missing or misconfigured in the service account.

C.The route hostname is invalid.

D.The liveness probe timeout is configured too short.

E.The container image tag or repository path specified in the pod spec is incorrect.

AnswersB, E

Image pulls authenticate against the registry using credentials from the pod's service account. If the referenced imagePullSecret is absent or its dockerconfigjson is malformed, the kubelet receives an authorisation failure, producing ImagePullBackOff regardless of network reachability.

Why this answer

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.

Exam trap

EX280 often tests the distinction between scheduling-phase failures (PVC, node selector, taints) and runtime-phase failures (probes, routes) versus image-pull-phase failures — candidates frequently pick PVC or probe answers because they sound like generic pod problems.

Practice this question →

8

MCQeasy

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?

A.oc adm diagnose

B.oc adm must-gather

C.oc cluster-info dump

D.oc get clusteroperators -o yaml

AnswerB

must-gather aggregates cluster-wide diagnostics — node, pod, operator and etcd data — into a single archive for Red Hat support. It satisfies the requirement to collect cluster-wide diagnostic information, unlike narrower commands that capture only one resource's state.

Why this answer

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

Exam trap

EX280 often tests whether candidates know the exact supported command for support-case diagnostics, and candidates frequently pick `oc cluster-info dump` or a non-existent `oc adm diagnose`.

How to eliminate wrong answers

Option A is wrong because `oc adm diagnose` is not a valid OpenShift command; there is no such subcommand. Option C is wrong because `oc cluster-info dump` collects API server and cluster state but is not the supported, comprehensive diagnostic bundle Red Hat support expects, and it omits many operator-specific artifacts. Option D is wrong because `oc get clusteroperators -o yaml` only dumps ClusterOperator objects and does not collect logs, events, or the full diagnostic set.

Practice this question →

9

MCQhard

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?

A.oc describe node <node> | grep -i pressure

B.oc get pod cache-0 -n data -o jsonpath='{.status.reason} {.status.message}'

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

D.oc logs cache-0 -n data --previous

AnswerB

When the kubelet evicts a pod, it sets status.reason to Evicted and status.message to a sentence such as 'The node was low on resource: memory', and the JSONPath query extracts exactly those fields. This confirms both that the pod was evicted and which resource triggered it, which is the direct evidence the administrator needs.

Why this answer

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.

Exam trap

The trap here is chasing container logs or node conditions for eviction evidence, when the kubelet writes the reason into the pod's status fields.

Practice this question →

10

MCQeasy

An administrator needs to list all persistent volume claims in the cluster that are currently stuck in the 'Pending' state. Which command can be combined with grep or custom formatting to identify them?

A.oc get pvc --all-namespaces

B.oc describe storage-cluster

C.oc adm storage pending

D.oc get pv --status=Pending

AnswerA

`oc get pvc --all-namespaces` satisfies the cluster-wide scope constraint by querying persistent volume claims across every namespace, not just the current project. Its output includes a STATUS column showing `Pending`, which grep or custom formatting can filter to isolate stuck claims.

Why this answer

PersistentVolumeClaims are namespaced resources, so listing them across the entire cluster requires the '--all-namespaces' flag. The command 'oc get pvc --all-namespaces' returns every PVC in every namespace, and the output can be piped to grep or formatted with -o wide/custom-columns to filter for those in Pending state. This is the correct base command for identifying stuck PVCs cluster-wide.

Exam trap

EX280 often tests whether candidates confuse PersistentVolumes (cluster-scoped) with PersistentVolumeClaims (namespaced), tricking them into using 'oc get pv' when the question asks about PVCs.

How to eliminate wrong answers

Option B is wrong because 'storage-cluster' is not a valid resource type — there is no such object to describe, and it would not list PVCs. Option C is wrong because 'oc adm storage pending' is not a real oc subcommand; 'oc adm storage' does not have a 'pending' verb. Option D is wrong because 'oc get pv --status=Pending' queries PersistentVolumes (cluster-scoped storage objects), not PersistentVolumeClaims, and PVs do not use a Pending status the way PVCs do — PVs use Available, Bound, Released, or Failed.

Practice this question →

11

MCQeasy

An administrator wants to check the cluster-wide resource consumption of nodes (CPU and Memory percentages). Which command provides this tabular overview?

A.oc get nodes --metrics

B.oc adm top nodes

C.oc cluster-capacity

D.oc describe nodes --usage

AnswerB

oc adm top nodes queries metrics-server and prints a tabular view of each node's CPU and memory usage alongside capacity percentages. This directly satisfies the cluster-wide consumption overview requirement, unlike oc describe node, which shows allocations rather than live usage.

Why this answer

'oc adm top nodes' is the OpenShift CLI command that queries the metrics subsystem and returns a tabular view of each node's CPU and memory consumption as a percentage of capacity. It is the node-level analog of 'oc adm top pods' and is the standard way to get a cluster-wide resource overview from the command line.

Exam trap

EX280 often tests the confusion between 'oc get' (object listing) and 'oc adm top' (live metrics), so candidates must recognize that resource-usage percentages come only from the 'oc adm top' family.

How to eliminate wrong answers

Option A is wrong because 'oc get nodes --metrics' is not a valid flag — 'oc get nodes' returns node objects, and the --metrics flag does not exist for that subcommand. Option C is wrong because 'oc cluster-capacity' is a deprecated/removed tool that estimated how many pods could fit on the cluster; it does not report live CPU/memory percentages. Option D is wrong because 'oc describe nodes --usage' is not a valid invocation — 'oc describe node' shows node details and allocated resources but not live usage percentages, and --usage is not a supported flag.

Practice this question →

12

MCQmedium

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?

A.Inspect the etcd cluster operator status.

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

C.Check if a pull secret is correctly configured and bound to the service account.

D.Restart the cluster version operator.

AnswerC

ImagePullBackOff with a valid tag typically means the kubelet cannot authenticate to the registry. Verifying that the correct pull secret exists and is referenced by the Pod's service account confirms registry credentials, directly addressing the authentication check the stem asks for.

Why this answer

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.

Exam trap

EX280 often tests whether candidates jump to node-level or operator-level troubleshooting for ImagePullBackOff instead of checking the service account's pull secret binding, which is the most common root cause.

How to eliminate wrong answers

Option A is wrong because etcd cluster operator status is unrelated to image pull authentication and would not explain ImagePullBackOff. Option B is wrong because `oc debug` inspects a running container's filesystem, but the container never started, so there is nothing to inspect. Option D is wrong because restarting the cluster version operator does not affect image pull authentication and is a disruptive, unrelated action.

Practice this question →

13

MCQeasy

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?

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

B.The pod does not have a toleration for the master node taint, so it cannot be scheduled on master nodes.

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

D.The pod is using a PersistentVolumeClaim that cannot be bound.

AnswerB

The event states that all nodes had the master taint and the pod did not tolerate it. In OpenShift, master nodes are tainted to prevent regular workloads from running on them. Without a matching toleration, the scheduler will not place the pod on those nodes, leaving it Pending. The solution is to schedule the pod on worker nodes or add a toleration if appropriate.

Why this answer

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.

Exam trap

The trap here is overlooking the explicit taint message in the event and instead assuming a resource or selector issue, which are common but not indicated by this specific event.

Practice this question →

14

MCQmedium

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

A.The liveness probe timed out before the application started.

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

C.A referenced ConfigMap or Secret in the pod specification does not exist.

D.The container exceeded its memory limit upon initialization.

AnswerC

A missing ConfigMap or Secret referenced by the pod causes the kubelet to fail resolving environment variables or volume mounts, producing CreateContainerConfigError before the container starts. This directly satisfies the scenario's constraint: the pod never launches, so the administrator should verify the referenced object exists in the same namespace.

Why this answer

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

Exam trap

EX280 often tests whether candidates can distinguish `CreateContainerConfigError` (missing ConfigMap/Secret) from `ImagePullBackOff` (registry/image issues) and `CrashLoopBackOff` (runtime/probe failures) — candidates commonly pick the image pull or probe option because those are more familiar failure modes.

How to eliminate wrong answers

Option A is wrong because a liveness probe timeout produces a `CrashLoopBackOff` or `Unhealthy` event, not `CreateContainerConfigError` — probe failures happen after the container starts. Option B is wrong because an image pull failure produces `ErrImagePull` or `ImagePullBackOff`, not `CreateContainerConfigError`, since image pulling is a separate stage from container config creation. Option D is wrong because exceeding a memory limit causes an OOMKill and `CrashLoopBackOff` after the container starts, not a config creation error before startup.

Practice this question →

15

MCQmedium

An administrator receives an alert that the Cluster Monitoring Operator is degraded because Prometheus cannot scrape metrics from a custom application namespace. Where should the administrator check to verify the ServiceMonitor configuration targeting the application?

A.oc describe clusteroperator monitoring

B.oc logs deployment/prometheus-k8s

C.oc get servicemonitor -n <app-namespace>

D.oc get prometheus-rules

AnswerC

ServiceMonitor objects are namespaced custom resources, so the operator's scrape configuration for a custom application lives in that application's namespace. Listing them there confirms whether the selector matches the Service labels and whether the endpoint port is exposed, which is exactly the misconfiguration degrading the Cluster Monitoring Operator.

Why this answer

A ServiceMonitor is a custom resource that tells the Prometheus Operator which services to scrape. If Prometheus cannot scrape a custom application namespace, the first place to verify the targeting configuration is the ServiceMonitor object in that namespace. Running `oc get servicemonitor -n <app-namespace>` confirms whether the ServiceMonitor exists, its selector labels, and its endpoints — the most likely cause of a missing scrape target.

Exam trap

EX280 often tests whether candidates know that ServiceMonitor CRs — not Prometheus logs or clusteroperator status — are the authoritative source for scrape target configuration.

How to eliminate wrong answers

Option A is wrong because `oc describe clusteroperator monitoring` shows the overall Cluster Monitoring Operator status and conditions, not the per-namespace ServiceMonitor configuration that determines scrape targets. Option B is wrong because `oc logs deployment/prometheus-k8s` shows Prometheus server logs, which may mention scrape failures but do not reveal the ServiceMonitor's selector/label configuration. Option D is wrong because `oc get prometheus-rules` lists alerting/recording rules, which are unrelated to scrape target discovery.

Practice this question →

16

Multi-Selecteasy

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

Select 2 answers

A.oc get clusteroperator network

B.oc get routes

C.oc adm top volume

D.oc logs -n openshift-ovn-kubernetes -l app=ovnkube-node

E.oc describe pvc

AnswersA, D

`oc get clusteroperator network` reports the Network operator's status conditions, surfacing whether the SDN/OVN-Kubernetes control plane has degraded or failed to roll out. For checking cluster networking and SDN communication, it confirms the operator managing that stack is healthy, satisfying the diagnostic requirement without inspecting individual pod logs or node interfaces.

Why this answer

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.

Exam trap

EX280 often tests whether candidates can distinguish network diagnostics (clusteroperator network, ovnkube-node logs) from storage diagnostics (PVC describe, top volume) when asked to gather networking information.

Practice this question →

17

Multi-Selectmedium

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)

Select 2 answers

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

B.oc describe clusteroperator storage

C.oc get routes --all-namespaces

D.oc logs -n openshift-cluster-storage-operator deployment/cluster-storage-operator

E.oc describe clusterversion

AnswersB, D

Inspecting `oc describe clusteroperator storage` exposes the operator's status conditions, revealing which CSI driver or provisioner is failing and the exact error message behind the degraded state. This directly satisfies the stem's requirement to diagnose the underlying cause, since the condition's reason and message fields pinpoint the faulting component.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know that ClusterOperator status is inspected with `oc describe clusteroperator <name>` and that the relevant logs are in the operator's own namespace, not in unrelated namespaces like openshift-apiserver.

Practice this question →

18

Multi-Selecteasy

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

Select 2 answers

A.oc get storageclass

B.oc get pods -n openshift-kube-apiserver

C.oc get clusteroperator kube-apiserver

D.oc adm top storage

E.oc get routes --all-namespaces

AnswersB, C

Listing pods in the `openshift-kube-apiserver` namespace directly enumerates every static pod backing the API server, satisfying the requirement to check all api-server instances. Each master's kube-apiserver pod appears here with its phase and restart count, giving per-instance status without querying cluster operators.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know the difference between per-pod inspection (`oc get pods -n openshift-kube-apiserver`) and operator-level status (`oc get clusteroperator kube-apiserver`) — the trap is picking unrelated resources like storageclass or routes.

Practice this question →

19

MCQhard

An OpenShift cluster's Ingress controller is failing to route external traffic because the router pods are crashing with 'Bind: address already in use'. What is the most likely cause that an administrator should investigate?

A.Another service or daemon on the worker node is already binding to host ports 80 or 443.

B.The OAuth client secret is invalid.

C.The default router deployment replica count is set to zero.

D.The wildcard DNS record for the cluster points to the wrong IP address.

AnswerA

The router pods bind to host ports 80 and 443, so a conflicting process already listening on those ports on the worker node prevents binding. Checking which daemon owns those ports identifies the conflict causing the crash.

Why this answer

The 'Bind: address already in use' error means the router pod's haproxy process cannot bind to host ports 80/443 because another process on the node already holds them. OpenShift's Ingress Controller runs as a hostNetwork pod binding directly to the node's ports 80 and 443, so any conflicting daemon (nginx, httpd, another load balancer, or a leftover router) will cause the crash. Administrators should check with 'ss -tlnp | grep -E ":80|:443"' or 'netstat -tulpn' on the worker node to identify the conflicting process.

Exam trap

EX280 often tests whether candidates can distinguish between a port-binding conflict (host-level resource contention) and higher-level configuration issues like DNS, OAuth, or replica count — the 'address already in use' string is the key diagnostic clue.

How to eliminate wrong answers

Option B is wrong because an invalid OAuth client secret would cause authentication failures for the OpenShift web console or API, not a port-binding error in router pods. Option C is wrong because a zero replica count would simply mean no router pods exist at all — there would be no crash and no bind error, just no routing. Option D is wrong because a misconfigured wildcard DNS record would cause external clients to fail name resolution or reach the wrong endpoint, but it would not produce a 'Bind: address already in use' error inside the router container.

Practice this question →

20

Multi-Selecthard

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

Select 2 answers

A.Inspect the namespace's spec.finalizers field to see which finalizer entry is still present.

B.List API resources still present in the namespace to find objects whose own finalizers block deletion.

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

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

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

AnswersA, B

A namespace remains Terminating while its status.phase is Terminating and spec.finalizers still lists the 'kubernetes' finalizer, which the namespace controller removes only after all contained resources are gone. Reading the namespace YAML shows whether that finalizer is still set, confirming that resource cleanup has not completed and pointing the investigation at the objects inside the namespace.

Why this answer

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.

Exam trap

The trap here is treating the namespace phase as the thing to fix, when the phase is merely a symptom of a finalizer that waits on leftover objects.

Practice this question →

21

MCQmedium

An administrator needs to drain a worker node safely for hardware maintenance, but some pods have local emptyDir storage that would be permanently deleted. Which flag must be added to the drain command to allow eviction of these pods?

A.--allow-local-volumes

B.--ignore-daemonsets=false

C.--delete-emptydir-data

D.--force-local-storage

AnswerC

Without this flag, kubectl drain aborts on pods using emptyDir volumes, since eviction destroys their local data. Adding --delete-emptydir-data acknowledges that loss and permits eviction, satisfying the maintenance requirement while leaving other pods safely rescheduled.

Why this answer

The --delete-emptydir-data flag explicitly tells kubectl/oc drain that it is acceptable to evict pods that use emptyDir volumes, which are node-local and will be permanently lost. Without this flag, drain refuses to proceed and reports an error listing pods with local storage. This is the documented way to acknowledge and accept the data loss during maintenance.

Exam trap

EX280 often tests the exact flag name for draining nodes with local storage, and candidates confuse it with non-existent flags like --allow-local-volumes or --force-local-storage.

How to eliminate wrong answers

Option A is wrong because --allow-local-volumes is not a valid drain flag; it does not exist in kubectl or oc. Option B is wrong because --ignore-daemonsets is a boolean flag (used to skip DaemonSet pods) and setting it to false does not permit eviction of pods with emptyDir storage. Option D is wrong because --force-local-storage is not a real drain option; the correct flag is --delete-emptydir-data.

Practice this question →

22

MCQmedium

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?

A.oc get clusterversion

B.oc adm upgrade status

C.oc get clusteroperators

D.oc version

AnswerA

`oc get clusterversion` reads the ClusterVersion resource, whose status reports the CVO's current payload version and conditions, including any operator blocking progress. This directly satisfies the stem's requirement to check CVO status and payload version during the stalled upgrade.

Why this answer

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

Exam trap

EX280 often tests the confusion between 'oc get clusterversion' (the CVO's ClusterVersion resource, showing overall upgrade status and payload version) and 'oc get clusteroperators' (individual operator status). Candidates who pick the latter miss that the question asks specifically about the CVO's status and payload version.

How to eliminate wrong answers

Option B is wrong because 'oc adm upgrade status' is not a valid oc command in OCP 4.x — upgrade status is obtained via 'oc get clusterversion' or 'oc adm upgrade' (which shows available updates). Option C is wrong because 'oc get clusteroperators' lists the individual ClusterOperators (kube-apiserver, network, storage, etc.) and their versions, but it does not show the CVO's own status or the overall payload version. Option D is wrong because 'oc version' shows the client and server versions of oc and the Kubernetes API, not the ClusterVersion resource or CVO status.

Practice this question →

23

MCQmedium

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?

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

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

C.oc get pod -n app-prod <pod-name> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

D.oc exec -n app-prod <pod-name> -- cat /var/log/containers/<pod-name>.log

AnswerC

The pod's status includes containerStatuses with lastState.terminated, which records the exit code and reason for the previous container instance. Using jsonpath to extract that field gives a precise, machine-readable answer. An exit code of 137 typically indicates SIGKILL, often from an OOM kill, while other codes point to application-level failures, making this the most direct diagnostic.

Why this answer

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.

Exam trap

The trap here is assuming that viewing previous logs or describe output reveals the container's exit code, when the exit code is only reliably available in the pod's status under lastState.terminated.

Practice this question →

24

Multi-Selecthard

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)

Select 3 answers

A.etcdctl snapshot restore

B.etcdctl defrag

C.etcdctl endpoint status

D.etcdctl member list

E.etcdctl endpoint health

AnswersC, D, E

etcdctl endpoint status queries each endpoint, returning the member ID, raft term, raft index, leader, and database size. Comparing raft indexes and leaders across endpoints reveals lagging followers and identifies which member holds leadership, exposing quorum or synchronisation problems.

Why this answer

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.

Exam trap

EX280 often tests whether candidates confuse diagnostic commands (endpoint status/health, member list) with maintenance commands (defrag, snapshot restore) that are destructive or non-diagnostic.

Practice this question →

25

Multi-Selecthard

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)

Select 3 answers

A.oc describe node <node-name>

B.oc adm top nodes

C.oc get events --namespace=default

D.oc logs deployment/cluster-version-operator

E.oc debug node/<node-name> -- chroot /host top

AnswersA, B, E

`oc describe node <node-name>` reports the node's allocated resources, capacity, and per-pod CPU and memory requests and limits, plus current usage percentages. This directly exposes which workloads are consuming the node's capacity, satisfying the stem's requirement to investigate resource bottlenecks on the affected node.

Why this answer

Option A, `oc describe node <node-name>`, 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/<node-name> -- 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.

Exam trap

EX280 often tests whether candidates know the difference between cluster-level and node-level troubleshooting commands — the trap is selecting namespace-scoped commands like `oc get events` or unrelated operator logs instead of node-specific diagnostic tools.

Practice this question →

26

MCQmedium

An application team reports that their application cannot connect to an external database due to a firewall blocking port 3306. The administrator wants to test network connectivity from inside a running application pod to the external database host. Which tool can they run using 'oc exec'?

A.oc network test db.example.com 3306

B.oc exec <pod-name> -- nc -zv db.example.com 3306

C.oc adm port-forward pod/<pod-name> 3306:3306

D.oc debug pod/<pod-name> -- test-connection

AnswerB

The nc utility with -z performs a zero-I/O scan and -v reports the result, testing whether TCP port 3306 on the external host accepts connections. Running it via oc exec inside the pod verifies connectivity from the application's actual network context.

Why this answer

The correct answer is B because `oc exec` allows running arbitrary commands inside a running container, and `nc` (netcat) with the `-zv` flags is a standard tool for testing TCP connectivity to a specific host and port. The `-z` flag performs a scan without sending data, and `-v` provides verbose output, making it ideal for verifying whether port 3306 is reachable from the pod's network namespace. This directly addresses the application team's issue by simulating the connection attempt from the same environment.

Exam trap

EX280 often tests the difference between valid `oc` subcommands and fabricated ones, so candidates must know that `oc exec` is the correct way to run commands inside pods, and that tools like `nc` are commonly used for connectivity tests, while options like `oc network test` or `oc debug -- test-connection` are invalid.

How to eliminate wrong answers

Option A is wrong because `oc network test` is not a valid OpenShift CLI command; there is no such subcommand for network testing. Option C is wrong because `oc adm port-forward` forwards a local port to a pod's port, which is used to access pod services from the local machine, not to test outbound connectivity from the pod to an external host. Option D is wrong because `oc debug` is used to launch a debug pod or execute commands in a copy of a pod, but `test-connection` is not a valid subcommand or tool; it would not perform a network connectivity test.

Practice this question →

27

MCQhard

The cluster monitoring stack is failing because Prometheus pods in the openshift-monitoring namespace are crashing due to disk space exhaustion on the Prometheus PersistentVolume. How can the administrator inspect the current disk usage inside the Prometheus container?

A.oc exec -n openshift-monitoring prometheus-k8s-0 -c prometheus -- df -h

B.oc debug node/<node-name> -- df -h

C.oc logs -n openshift-monitoring deployment/prometheus-adapter

D.oc adm top volume

AnswerA

Disk exhaustion is inside the container's filesystem, so the check must run within that container. `oc exec` targets the prometheus-k8s-0 pod and its prometheus container, running `df -h` to report filesystem usage, directly satisfying the need to inspect the Prometheus container's disk consumption.

Why this answer

The Prometheus pods run in the openshift-monitoring namespace, and to inspect disk usage inside a specific container you must exec into that container. Option A uses `oc exec` with the correct pod name (prometheus-k8s-0), namespace, and container (-c prometheus) to run `df -h`, which directly shows filesystem usage on the mounted PersistentVolume. This is the only option that targets the actual container's filesystem rather than the node or unrelated resources.

Exam trap

EX280 often tests whether candidates know to exec into the specific container rather than debug the node or check logs, so the trap is choosing node-level commands that don't inspect the container's filesystem.

How to eliminate wrong answers

Option B is wrong because `oc debug node/<node-name>` opens a debug pod on the node and runs `df -h` against the node's filesystem, not the Prometheus container's mounted PV, so it won't reveal the container-level disk exhaustion. Option C is wrong because `oc logs` on the prometheus-adapter deployment retrieves application logs from a different component (the metrics adapter), not filesystem usage of the Prometheus container. Option D is wrong because `oc adm top volume` is not a valid OpenShift command for inspecting volume disk usage inside a container; it does not exist for this purpose.

Practice this question →

28

MCQmedium

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?

A.Exit code 0 with restartPolicy Always means the container finished its work; the administrator should switch the workload to a Job.

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

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

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

AnswerA

With restartPolicy Always, any container exit, including a clean code 0, triggers a restart because the policy treats the process as a long-running service. A container that exits 0 by design is misconfigured as a Deployment; converting it to a Job, whose restartPolicy is OnFailure or Never, matches the intended run-to-completion behaviour and stops the restart loop.

Why this answer

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.

Exam trap

The trap here is reading exit code 0 as 'no problem' and hunting for a probe or memory issue, when the restartPolicy alone explains the loop.

Practice this question →

29

MCQeasy

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?

A.oc logs api-server-xyz --tail=50 -f

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

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

D.oc tail api-server-xyz -n 50

AnswerA

The --tail=50 flag limits output to the final fifty lines, while -f follows the stream so new entries appear as they are written. Combined in oc logs against api-server-xyz, this satisfies both requirements of the question in a single command.

Why this answer

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

Exam trap

EX280 often tests whether candidates confuse the correct flag name (--tail) with plausible alternatives like --lines, or invent non-existent subcommands like 'oc tail'.

How to eliminate wrong answers

Option B is wrong because 'oc describe pod' shows metadata, events, and status — it does not stream container logs, and --lines is not a valid describe flag. Option C is wrong because --lines is not a valid oc logs flag; the correct flag is --tail, and while --follow is valid, the combination with --lines fails. Option D is wrong because 'oc tail' is not a real subcommand — tailing is achieved via 'oc logs -f'.

Practice this question →

30

MCQhard

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?

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

B.journalctl -u coredns

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

D.oc logs -n openshift-dns -l dns.operator.openshift.io/daemonset-dns=default

AnswerD

Querying the CoreDNS pods directly via the `dns.operator.openshift.io/daemonset-dns=default` label selector exposes the CoreDNS server logs, which record upstream forwarding failures and loop detection messages. This satisfies the stem's need to diagnose resolution errors at their source, unlike node or operator logs.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know that OpenShift 4.x replaced kube-dns with CoreDNS in the openshift-dns namespace — many still reach for kube-system or systemd commands from older documentation.

How to eliminate wrong answers

Option A is wrong because kube-dns was the DNS add-on in older Kubernetes/OpenShift 3.x; OpenShift 4.x uses CoreDNS in openshift-dns, and there is no kube-dns deployment in kube-system. Option B is wrong because CoreDNS is not a systemd unit on the host — it runs as a containerized DaemonSet, so journalctl -u coredns will not show its logs. Option C is wrong because the network-operator manages cluster networking configuration but does not emit CoreDNS resolution logs; its logs are about operator reconciliation, not DNS query failures.

Practice this question →

31

Multi-Selecteasy

An administrator is investigating pod crash loops in a namespace. Which TWO commands are most useful for gathering initial diagnostic data about the crashing pods? (Choose TWO)

Select 2 answers

A.oc describe pod <pod-name>

B.oc logs <pod-name> --previous

C.oc adm must-gather

D.oc rsh <pod-name>

E.oc debug node/<node-name>

AnswersA, B

oc describe pod reports container states, restart counts, exit codes and recent events such as image pull or scheduling failures. These details expose why a pod is crash-looping, making it a primary first-step diagnostic command.

Why this answer

Option A, `oc describe pod <pod-name>`, is correct because it surfaces the pod's status conditions, container states (including CrashLoopBackOff and last termination reason/exit code), restart counts, and recent events from the namespace, which is exactly the initial diagnostic data needed for a crash-looping pod. Option B, `oc logs <pod-name> --previous`, is correct because the `--previous` flag retrieves the logs from the prior container instance, capturing the output right before the crash that triggered the restart, which is essential when the current container is not running or is repeatedly restarting. Option C, `oc adm must-gather`, is not appropriate here because it collects a broad cluster-wide diagnostic bundle and is far too heavy for initial pod-level triage.

Option D, `oc rsh <pod-name>`, does not belong because a crash-looping pod typically has no running container to exec into, so the remote shell would fail. Option E, `oc debug node/<node-name>`, is not correct because it targets node-level debugging rather than gathering initial data about the crashing pods themselves.

Exam trap

EX280 often tests whether candidates know that 'oc rsh' and 'oc exec' fail on non-running containers — reaching for a shell into a CrashLoopBackOff pod instead of using '--previous' logs and 'describe' is the classic wrong turn.

Practice this question →

32

Multi-Selecteasy

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

Select 2 answers

A.oc describe node <node-name>

B.oc get nodes

C.oc get clusterversion

D.oc get routes

E.oc adm top volume

AnswersA, B

`oc describe node <node-name>` reports each node's current state, including Ready condition, capacity, allocatable resources and active taints, satisfying the requirement to verify health and readiness across the cluster. It surfaces scheduling-relevant conditions such as MemoryPressure and DiskPressure, letting the administrator confirm whether nodes can accept workloads.

Why this answer

Option A, `oc describe node <node-name>`, 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.

Exam trap

EX280 often tests the confusion between cluster-level status commands (clusterversion, routes) and node-level health commands — candidates pick commands that sound administrative but do not actually report node readiness.

Practice this question →

33

MCQhard

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?

A.The default Kubernetes events in the default namespace.

B.The global clusterversion object status conditions.

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

D.The status field of the specific Custom Resource instance (e.g., 'oc get <cr-kind> <cr-name> -o yaml').

AnswerD

Operator controllers write reconciliation outcomes, including errors, into the status subresource of the Custom Resource they manage. Reading the CR's status field via oc get with YAML output exposes those condition messages directly, unlike pod logs, which may have rotated or omit CR-specific detail.

Why this answer

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 <cr-kind> <cr-name> -o yaml'. This reflects the controller's own view of the operand's health and any reconciliation failures.

Exam trap

EX280 often tests whether candidates look at generic cluster events or node logs instead of the CR's own status subresource, which is where operator controllers actually publish reconciliation errors.

How to eliminate wrong answers

Option A is wrong because default Kubernetes events in the default namespace are ephemeral, namespace-scoped, and usually do not capture operator-specific reconciliation errors for a CR in another namespace. Option B is wrong because the clusterversion object reflects cluster version operator state, not arbitrary operator CR status. Option C is wrong because /var/log/messages on master nodes is a node-level system log and does not reliably contain operator controller reconciliation messages for a specific CR.

Practice this question →

34

MCQmedium

An administrator notices that a Deployment named 'webapp' in the namespace 'production' is not reaching its desired replica count. Running 'oc get deployment webapp -n production' shows READY 2/3 but no events appear on the Deployment itself. The administrator wants to determine why the third ReplicaSet pod cannot be scheduled. Which command best reveals the scheduling failure reason?

A.oc rollout status deployment/webapp -n production

B.oc describe pod -n production -l app=webapp

C.oc get deployment webapp -n production -o yaml

D.oc logs deployment/webapp -n production --tail=50

AnswerB

Describing the pods selected by the Deployment's label displays the PodScheduled condition and Events such as 'Insufficient cpu' or '0/6 nodes available', which state precisely why the ReplicaSet could not place a pod. The Deployment controller reports replica shortfall but delegates scheduling detail to the ReplicaSet and its pods, so inspecting the pod objects is the correct diagnostic path.

Why this answer

The Deployment controller only records aggregate replica counts; the actual scheduling decision is made for the pod object by the scheduler, and its reasoning is written to the pod's status conditions and Events. Describing the pods matched by the Deployment's selector surfaces messages such as taint toleration mismatches, insufficient CPU, or unsatisfied node affinity, which directly explain the missing replica.

Exam trap

The trap here is assuming the Deployment object itself records why a replica was not created, when the scheduler's reason only exists on the pod and its events.

Practice this question →

35

MCQeasy

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

A.oc ip pod <pod-name>

B.oc get pod <pod-name> -o wide

C.oc describe pod <pod-name> --network

D.oc get network-attachment-definitions

AnswerB

The -o wide output format adds the pod IP and hosting node columns to the default listing, so a single command reveals the assigned address and node without describing the pod or querying endpoints separately. This satisfies the requirement to check IP and network status quickly.

Why this answer

The command `oc get pod <pod-name> -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.

Exam trap

EX280 often tests the difference between `oc get pod -o wide` and `oc describe pod` for retrieving pod IPs, and candidates may incorrectly assume that `oc describe` requires a `--network` flag or that a dedicated `oc ip` command exists.

How to eliminate wrong answers

Option A is wrong because `oc ip pod <pod-name>` is not a valid OpenShift command; there is no `oc ip` subcommand. Option C is wrong because `oc describe pod <pod-name> --network` is invalid syntax; `oc describe` does not accept a `--network` flag, and while `oc describe pod` shows the IP, the extra flag causes an error. Option D is wrong because `oc get network-attachment-definitions` lists NetworkAttachmentDefinition objects (used for multus CNI), not pod IP addresses or network status.

Practice this question →

36

Multi-Selectmedium

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

Select 3 answers

A.oc get machineset

B.oc logs -n openshift-dns -l dns.operator.openshift.io/daemonset-dns=default

C.oc get clusteroperator dns

D.oc describe ingresscontroller default

E.Running an interactive debug pod to test DNS lookup using 'nslookup' or 'dig'.

AnswersB, C, E

Inspecting the CoreDNS pods' logs via that label selector reveals query failures, upstream timeouts, or malformed responses recorded by the DNS operator's daemonset. This directly satisfies the troubleshooting requirement by exposing why resolution fails inside the application namespace, rather than merely confirming that DNS pods exist.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know the specific DNS operator resources and labels, tricking them into checking unrelated networking components like Ingress or MachineSets.

Practice this question →

37

MCQhard

An OpenShift cluster administrator notices that API requests are taking an excessively long time to complete. They suspect etcd database bloat due to excessive ConfigMap creations. Which etcd maintenance command can be run inside an etcd pod to reclaim storage space after compaction?

A.etcdctl prune-storage

B.oc adm etcd-clean

C.etcdctl defrag

D.etcdctl compact --vacuum

AnswerC

Defrag reclaims the physical disk space that compaction only logically frees, so running etcdctl defrag inside the etcd pod shrinks the bloated database file. Compaction alone leaves the storage allocated, making defrag the required maintenance step for the excessive ConfigMap growth described.

Why this answer

After etcd compaction removes superseded revisions, the on-disk database file still contains the freed space until defragmentation. Running `etcdctl defrag` inside the etcd pod rewrites the data file and reclaims that storage, reducing the database size and improving API latency caused by bloat. This is the correct maintenance command to run after compaction.

Exam trap

EX280 often tests whether candidates know that compaction and defragmentation are distinct steps — compaction frees logical revisions, but only defrag reclaims physical disk space.

How to eliminate wrong answers

Option A is wrong because `etcdctl prune-storage` is not a real etcdctl subcommand — it does not exist. Option B is wrong because `oc adm etcd-clean` is not a valid OpenShift command; there is no such subcommand. Option D is wrong because `etcdctl compact --vacuum` is not a valid combination — compaction and defragmentation are separate operations; `compact` only marks revisions for removal, and the `--vacuum` flag is not an etcdctl option.

Practice this question →

38

Multi-Selecthard

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)

Select 3 answers

A.oc logs -n openshift-machine-config-operator daemonset/machine-config-daemon

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

C.oc get machineconfig -l machineconfiguration.openshift.io/role=<role>

D.oc adm upgrade cancel

E.oc describe machineconfigpool <pool-name>

AnswersA, C, E

The machine-config-daemon DaemonSet runs on every node and applies rendered MachineConfigs. Its logs expose failures such as failed reboots, file writes or drain operations, revealing why nodes cannot reach the updated configuration and why the MachineConfigPool reports degraded.

Why this answer

Option E is correct because `oc describe machineconfigpool <pool-name>` 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=<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.

Exam trap

The trap is assuming that scaling operators or canceling upgrades would help diagnose a degraded pool, when in fact those actions are irrelevant to root cause analysis.

Practice this question →

39

MCQeasy

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

A.oc get routes

B.oc get pod <pod-name> -o json

C.oc adm diagnostics

D.oc describe pod <pod-name>

AnswerD

oc describe pod reports container statuses, including liveness probe failures with their exit codes, events and restart counts, giving the fastest diagnostic view. Logs show application output rather than probe mechanics, and oc get pod shows only status, so describe is the appropriate first check.

Why this answer

The `oc describe pod <pod-name>` 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.

Exam trap

EX280 often tests troubleshooting commands, so the trap is choosing commands that show configuration or cluster-wide diagnostics instead of the pod's runtime events.

How to eliminate wrong answers

Option A is wrong because `oc get routes` lists OpenShift routes, which are unrelated to pod liveness probes. Option B is wrong because `oc get pod <pod-name> -o json` outputs the pod's full JSON definition, which includes probe configuration but not the runtime failure events; it's less convenient for quick diagnosis. Option C is wrong because `oc adm diagnostics` runs cluster-wide diagnostics, which is overkill and not targeted at a specific pod's liveness probe failure.

Practice this question →

40

MCQhard

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?

A./run/log/journal

B./var/lib/kubelet/pods

C./var/crash

D./var/log/audit/audit.log

AnswerC

On CoreOS worker nodes, kdump writes the vmcore and associated crash metadata to /var/crash on the node's filesystem. Administrators inspect that directory, or use oc debug to access the node, to retrieve the kernel panic logs.

Why this answer

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.

Exam trap

EX280 often tests knowledge of filesystem locations on CoreOS, so the trap is confusing journal logs or pod directories with the kdump crash dump location.

How to eliminate wrong answers

Option A is wrong because /run/log/journal is a volatile directory for systemd journal logs, not for kernel crash dumps. Option B is wrong because /var/lib/kubelet/pods contains pod-related data and volumes, not kernel crash logs. Option D is wrong because /var/log/audit/audit.log is the audit log for the audit daemon, unrelated to kernel panics.

Practice this question →

41

Multi-Selectmedium

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

Select 3 answers

A.oc get subscription <operator-name>

B.oc get installplan

C.oc get routes

D.oc get pv

E.oc get csv

AnswersA, B, E

The Subscription records the operator's desired channel, approval strategy, and installed CSV reference, plus any resolution or install-plan errors. Inspecting it reveals whether OLM failed during dependency resolution or upgrade, making it the primary diagnostic resource for a failing installation.

Why this answer

Option A, `oc get subscription <operator-name>`, 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.

Exam trap

EX280 often tests OLM troubleshooting by including unrelated OpenShift resources — the trap is selecting routes or PVs, which are not part of the OLM resource chain (Subscription → InstallPlan → CSV).

Practice this question →

42

MCQhard

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?

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

B.oc adm inspect router

C.oc get validatingwebhookconfigurations

D.oc describe ingresscontroller default -n openshift-ingress-operator

AnswerD

`oc describe` surfaces the operator's status conditions and events on the IngressController object, exposing the validation error text the operator recorded. This satisfies the stem's need to inspect the exact schema failure, since the operator writes reconciliation and admission errors into those conditions rather than only logging them.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know to inspect the custom resource's status via describe rather than checking logs of the deployed component, so the trap is looking at router logs instead of operator status.

How to eliminate wrong answers

Option A is wrong because `oc logs` on the router-default deployment shows logs from the router pods themselves, not the Ingress Operator's validation logic; the router may not even be deployed if validation fails. Option B is wrong because `oc adm inspect router` is not a valid command; `oc adm inspect` requires a resource type and name, and 'router' is not a standard resource. Option C is wrong because `oc get validatingwebhookconfigurations` lists webhook configurations but does not show the specific validation error for the IngressController resource.

Practice this question →

43

Multi-Selectmedium

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)

Select 3 answers

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

B.oc logs -n openshift-kube-apiserver pod/kube-apiserver-<node-name>

C.oc get namespaces

D.oc describe clusteroperator authentication

E.oc logs -n openshift-authentication deployment/oauth-openshift

AnswersB, D, E

The kube-apiserver pod log records authentication and token-exchange failures, including OIDC and webhook errors, on the control-plane node. This satisfies the stem's requirement for a source of relevant error logs and status information during token exchange diagnosis.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know the specific namespaces and resource names for OpenShift's auth components — picking generic operators like ingress-operator or unrelated commands like 'oc get namespaces' instead of the oauth-openshift deployment, kube-apiserver pod, and authentication ClusterOperator.

Practice this question →

44

MCQeasy

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

A.oc adm cluster-status

B.oc get nodes

C.oc get pods --all-namespaces

D.oc get clusteroperators

AnswerD

`oc get clusteroperators` queries the ClusterOperator resources directly, listing each operator with its AVAILABLE, PROGRESSING and DEGRADED status columns. This satisfies the stem's requirement for a summary confirming all required operators are available and not degraded after installation, without inspecting individual pods or namespaces.

Why this answer

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.

Exam trap

EX280 often tests the confusion between node-level and operator-level health checks, tempting candidates to choose `oc get nodes` or `oc get pods --all-namespaces` when the question specifically asks about cluster operators.

How to eliminate wrong answers

Option A is wrong because `oc adm cluster-status` is not a valid OpenShift command; the correct administrative diagnostic is `oc adm top` or `oc adm must-gather`, and no such cluster-status subcommand exists. Option B is wrong because `oc get nodes` only shows node readiness and roles, not the status of cluster operators, so it cannot confirm operator availability or degradation. Option C is wrong because `oc get pods --all-namespaces` lists individual pods but does not aggregate operator-level health; a pod can be running while its operator is degraded, and the output is too granular to provide the required summary.

Practice this question →

45

MCQeasy

An administrator wants to check the detailed configuration and current status of a specific Route named 'my-app-route'. Which command provides this?

A.oc get route my-app-route --status

B.oc describe route my-app-route

C.oc show route my-app-route

D.oc adm route-status my-app-route

AnswerB

oc describe route renders the Route's specification plus status fields such as admitted, host and router references, giving detailed configuration and current state. This satisfies the requirement to check a specific named Route's detailed configuration and status.

Why this answer

The `oc describe route my-app-route` command provides detailed configuration and current status of a specific Route, including host, path, TLS settings, and the router's admission status. It is the standard way to inspect a single OpenShift resource in depth.

Exam trap

EX280 often tests whether candidates know the correct oc subcommands — `describe` is for detailed inspection, while `get` is for summary, and invalid commands like `show` or `adm route-status` are distractors.

How to eliminate wrong answers

Option A is wrong because `oc get route my-app-route --status` is not a valid flag combination for detailed status; `oc get` returns summary information, and `--status` is not a standard flag for routes. Option C is wrong because `oc show` is not a valid oc command. Option D is wrong because `oc adm route-status` is not a valid subcommand; `oc adm` has different administrative commands, and route status is not one of them.

Practice this question →

46

MCQmedium

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?

A./var/lib/etcd/cert

B./etc/origin/node/certificates

C./var/lib/kubelet/pki/

D./etc/kubernetes/pki

AnswerC

On OpenShift worker nodes, the kubelet's client certificates and keys reside under /var/lib/kubelet/pki/, which an oc debug session can inspect directly. This path holds the credentials used for kubelet-to-API-server authentication, matching the certificate expiration troubleshooting scenario.

Why this answer

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.

Exam trap

EX280 often tests whether candidates confuse control plane PKI paths (/etc/kubernetes/pki, /var/lib/etcd) with worker kubelet certificate paths (/var/lib/kubelet/pki).

How to eliminate wrong answers

Option A is wrong because /var/lib/etcd/cert relates to etcd certificates on control plane nodes, not kubelet client certs on workers. Option B is wrong because /etc/origin/node/certificates is a legacy OpenShift 3 path and not the standard location for kubelet client certificates in OpenShift 4. Option D is wrong because /etc/kubernetes/pki holds control plane PKI (API server, etcd, controller-manager) on masters, not worker kubelet client certs.

Practice this question →

47

MCQhard

An administrator notices that the `openshift-apiserver` cluster operator reports `Available=True` but `Progressing=True` with the message `APIServerDeploymentProgressing: deployment/openshift-apiserver: 1/3 pods ready`. The administrator wants to determine which specific pod is not ready and why. Which command provides the most direct diagnostic information about the individual pod's readiness?

A.oc get clusteroperator openshift-apiserver -o yaml

B.oc get pods -n openshift-apiserver -o wide

C.oc describe pod -n openshift-apiserver <pod-name>

D.oc logs -n openshift-apiserver <pod-name> --tail=50

AnswerC

oc describe pod displays detailed status including container states, readiness probe results, events, and conditions. For a pod that is not ready, it shows whether the readiness probe is failing, if the container is crashing, or if there are scheduling issues, making it the most direct way to diagnose the specific pod's unready state.

Why this answer

When a cluster operator reports a deployment progressing with unready pods, the next step is to inspect the affected pod directly. The oc describe pod output includes the pod's conditions, container statuses, and recent events, which together explain why the pod is not Ready, such as a failing readiness probe or an image pull error. Higher-level operator status and pod lists lack this granularity.

Exam trap

The trap here is focusing on the cluster operator's YAML or a simple pod list, which confirms the symptom but does not reveal the specific cause of the pod's unreadiness.

Practice this question →

48

MCQhard

An administrator is troubleshooting a certificate signing request (CSR) that is stuck in the Pending state for a newly added worker node. Which command should they use to approve the pending CSR?

A.oc cluster-version approve-csr <csr-name>

B.oc adm certificate approve <csr-name>

C.oc patch csr <csr-name> --type=json -p='[{"op": "replace", "path": "/status/conditions", "value": "Approved"}]'

D.oc approve csr <csr-name>

AnswerB

The CSR remains Pending until an administrator explicitly approves it; worker node CSRs are not auto-approved by default. The `oc adm certificate approve` subcommand is the cluster-admin action that transitions the request to Approved, allowing the kubelet to receive its signed certificate and join the node.

Why this answer

`oc adm certificate approve <csr-name>` is the documented OpenShift command to approve a pending CSR, which triggers the signer controller to issue the node client certificate. It is the standard administrative action for unblocking node bootstrap. The command is idempotent and safe to re-run.

Exam trap

EX280 often tests whether candidates know the exact syntax `oc adm certificate approve` — the trap is picking a plausible but non-existent `oc approve csr` or a manual JSON patch of the status subresource.

How to eliminate wrong answers

Option A is wrong because `oc cluster-version` is not a valid command — the correct resource is `clusterversion`, and it has no `approve-csr` subcommand. Option C is wrong because directly patching the CSR status conditions bypasses the approval controller and is not the supported workflow; the CSR status is managed by the signer, and manual patches can leave the CSR in an inconsistent state. Option D is wrong because `oc approve` is not a top-level command — approval is under `oc adm certificate approve`.

Practice this question →

49

MCQhard

The OpenShift SDN (or OVN-Kubernetes) network plugin reports a failure. The administrator needs to inspect the iptables rules on a worker node to verify packet mangling and NAT configurations. How can they view the host's iptables rules?

A.oc logs daemonset/iptables-analyzer

B.oc adm diagnostics iptables

C.oc debug node/<node-name> -- chroot /host iptables-save

D.oc exec deployment/router-default -- iptables -L

AnswerC

Host iptables rules live in the node's network namespace, not the container's. `oc debug node/<node-name>` starts a privileged pod on that node, and `chroot /host` enters the host root filesystem so `iptables-save` reads the actual host NAT and mangling rules.

Why this answer

The `oc debug node/<node-name>` command creates a privileged debug pod that runs on the target node and mounts the host's root filesystem at /host. Using `chroot /host` switches the process root into the host's filesystem, allowing the administrator to run the host's own `iptables-save` binary against the host's netfilter tables. This is the only option that actually inspects the node's kernel-level iptables rules rather than pod-level or non-existent resources.

Exam trap

EX280 often tests whether candidates know that node-level inspection requires `oc debug node/<name>` plus `chroot /host`, not `oc exec` into a workload pod — the trap is picking a pod-scoped command that shows the wrong network namespace.

How to eliminate wrong answers

Option A is wrong because there is no DaemonSet named 'iptables-analyzer' in OpenShift, and even if one existed, `oc logs` would only show container stdout, not iptables rules. Option B is wrong because `oc adm diagnostics` does not have an 'iptables' subcommand — it runs predefined cluster health checks, not arbitrary host commands. Option D is wrong because the router-default deployment runs in a pod with its own network namespace, so `iptables -L` there shows only the pod's rules, not the host's NAT/mangle tables used by the SDN plugin.

Practice this question →

50

MCQmedium

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?

A.oc get svc my-service

B.oc get endpoints my-service

C.oc describe ingress

D.oc get routes my-route

AnswerB

Endpoints objects hold the ready pod IPs and ports backing a Service, populated by the endpoints controller. Reading them confirms whether selector matching succeeded, distinguishing a 502 caused by empty endpoints from one caused by ingress or application faults.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know that 'oc get svc' shows the Service definition but not the backing pod IPs — the Endpoints object is the authoritative source for verifying selector-to-pod matching.

How to eliminate wrong answers

Option A is wrong because 'oc get svc my-service' shows the Service's ClusterIP, ports, and selector, but not the actual pod IPs backing it — it will not reveal whether endpoints were populated. Option C is wrong because 'oc describe ingress' shows ingress rules, TLS settings, and backend references, but not the live endpoint IPs of the Service. Option D is wrong because 'oc get routes my-route' shows the OpenShift Route hostname and target Service, but not the pod-level endpoints that determine whether traffic can reach a backend.

Practice this question →

51

Multi-Selecthard

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)

Select 3 answers

A.Reboot all control plane nodes simultaneously.

B.Check cluster-wide events related to the operator namespace.

C.Check the logs of the operator deployment in its respective openshift-* namespace.

D.Inspect the status conditions in the operator's Custom Resource (e.g., oc get <cr> -o yaml).

E.Delete all persistent volumes in the cluster.

AnswersB, C, D

Cluster-wide events expose reconciliation failures such as failed API calls, RBAC denials, or resource conflicts affecting the operator's namespace, directly revealing why the loop stalls in Progressing. Filtering events by the operator namespace surfaces the specific blocking condition the stem describes, without requiring deeper pod-level inspection first.

Why this answer

Option B is correct because cluster-wide events (e.g., oc get events -n openshift-<operator>) 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 <cr> -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.

Exam trap

EX280 often tests whether candidates choose safe, read-only diagnostic commands (events, logs, CR status) over destructive actions like rebooting nodes or deleting PVs, which are never valid troubleshooting steps.

Practice this question →

52

MCQhard

An administrator runs 'oc debug node/worker-1' and gets a shell in the debug pod, but when they try to run 'crictl ps' to list running containers on the node, the command is not found. They confirm the node's kubelet is healthy and workloads are running. What is the correct explanation and fix?

A.crictl has been deprecated in favor of 'oc adm node-logs', so the administrator should use that command for container inspection instead.

B.The debug pod uses a minimal image without crictl; they must add '--image=registry.access.redhat.com/ubi9/ubi' to install it manually.

C.The debug pod must be started with 'chroot /host' executed inside it, because the host binaries are mounted at /host but the shell starts in the container root.

D.The administrator lacks the cluster-admin role, so crictl is hidden by RBAC; granting cluster-admin will make the binary visible.

AnswerC

'oc debug node/<name>' mounts the host root filesystem at /host inside the debug pod but leaves the shell in the container's filesystem, where node binaries such as crictl are absent. Running 'chroot /host' switches the process root to the host filesystem, after which crictl and other node tools resolve. This is the documented workflow for node-level troubleshooting on OpenShift.

Why this answer

'oc debug node' intentionally isolates the administrator: the host filesystem is bind-mounted at /host rather than made the process root, so host-only binaries are not on PATH. Entering the host namespace with 'chroot /host' makes crictl, journalctl, and other node utilities resolvable, which is the supported method for inspecting CRI containers on a node.

Exam trap

The trap here is believing that a debug shell on a node automatically runs in the host's filesystem, when it actually starts in the container root with the host mounted at /host.

Practice this question →

53

MCQhard

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?

A.oc describe machineconfigpool worker

B.oc logs -n openshift-machine-config-operator daemonset/machine-config-daemon

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

D.journalctl -u kubelet -e

AnswerB

The Machine Config Daemon runs as a DaemonSet pod on each node, and its container logs record exactly why it failed to write system files during a rendered-worker update. Querying the daemonset in the openshift-machine-config-operator namespace surfaces the per-node error, satisfying the need to diagnose the degraded MachineConfigPool.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know that 'oc describe machineconfigpool' shows status but not root cause — the actual failure reason lives in the Machine Config Daemon logs, not in the pool description or CVO logs.

How to eliminate wrong answers

Option A is wrong because 'oc describe machineconfigpool worker' only shows status conditions (Degraded, Updating) and node counts — it does not reveal why the MCD failed to write files. Option C is wrong because the Cluster Version Operator logs track cluster version upgrades, not per-node MachineConfig application failures. Option D is wrong because kubelet journal logs show pod lifecycle and container runtime issues, not the MCD's file-application errors during a MachineConfig rollout.

Practice this question →

54

Multi-Selectmedium

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)

Select 3 answers

A.oc get storageclass

B.oc describe node <node-name>

C.Journalctl logs for the kubelet service on the affected node.

D.oc get ingresscontroller

E.oc get events --field-selector reason=Evicted

AnswersB, C, E

Describing the node surfaces the cordoned and drained state plus conditions, taints and recent events recorded against the node object itself. That reveals whether the kubelet reported NotReady, disk or memory pressure, or an eviction taint applied by the node lifecycle controller.

Why this answer

Option B, `oc describe node <node-name>`, 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.

Exam trap

EX280 often tests whether candidates know to check node conditions, kubelet logs, and Evicted events — not storage classes or ingress controllers, which are unrelated to node eviction.

Practice this question →

55

MCQmedium

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?

A.oc describe pod <pod-name>

B.oc top pod <pod-name> --containers

C.oc get pod <pod-name> -o yaml

D.oc adm diagnostics

AnswerA

`oc describe pod` reports the container's configured memory limit and requests from the pod spec, plus recent events including OOMKilled terminations. It satisfies the need to see the limit that was exceeded, though historical usage immediately before the crash requires metrics tooling rather than describe output alone.

Why this answer

'oc describe pod <pod-name>' 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.

Exam trap

EX280 often tests whether candidates confuse 'oc describe pod' (shows limits, last state, OOMKilled reason) with 'oc top pod' (shows only live usage) — the trap is picking 'oc top' because it mentions memory.

How to eliminate wrong answers

Option B is wrong because 'oc top pod --containers' shows only current live memory/CPU usage — it cannot show historical usage before the crash or the configured limit. Option C is wrong because 'oc get pod -o yaml' shows the manifest (including limits) but not the last state, exit reason, or historical usage — it lacks the runtime diagnostic detail. Option D is wrong because 'oc adm diagnostics' runs cluster-wide health checks and does not drill into a specific pod's OOM event or memory configuration.

Practice this question →

56

MCQhard

An OpenShift cluster administrator receives an alert that etcd disk fsync durations are excessively high. Which performance metric is the etcd diagnostic tool measuring when evaluating disk latency?

A.The network round trip time between etcd follower and leader nodes.

B.The time taken for etcd to commit WAL (Write-Ahead Log) entries to persistent storage via fsync.

C.The time taken by the Kubernetes API server to serialize JSON objects.

D.The garbage collection duration of expired etcd keys.

AnswerB

The etcd diagnostic tool measures fsync latency: the duration for etcd to commit Write-Ahead Log entries to persistent storage. Elevated values indicate slow disk writes, directly explaining the excessively high fsync durations reported in the alert.

Why this answer

The etcd diagnostic tool measures disk fsync latency — the time for etcd to commit Write-Ahead Log (WAL) entries to persistent storage via fsync — because etcd's performance is bound by disk I/O on the WAL. High fsync durations directly cause slow etcd writes, leader election instability, and API server timeouts, which is why the alert fires.

Exam trap

EX280 often tests whether candidates confuse etcd disk fsync latency with network peer latency or API server performance, leading them to pick the network or serialization option.

How to eliminate wrong answers

Option A is wrong because network round-trip time between etcd peers is measured separately (peer latency) and is not what fsync duration refers to. Option C is wrong because API server JSON serialization is a control-plane CPU concern, unrelated to etcd disk fsync. Option D is wrong because etcd garbage collection (compaction and defragmentation) is a maintenance operation, not the fsync latency metric the diagnostic tool reports.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Troubleshooting And Diagnostics questions.

Start 20-question session