Red Hat Certified OpenShift Administrator (EX280, OpenShift Container Platform 4.14+) (EX280) EX280 Questions 226–300 | Page 4/6

226

Multi-Selectmedium

Which THREE of the following components are part of the standard OpenShift Ingress architecture? (Choose THREE)

Select 3 answers

A.IngressController Custom Resource

B.HAProxy-based router pods

C.ClusterNetwork operator

D.Ingress Operator

E.EgressFirewall controller

AnswersA, B, D

The IngressController Custom Resource defines and configures the ingress operator's managed router deployment, specifying replicas, node placement and endpoint publishing strategy. It is a core declarative component of the standard OpenShift Ingress architecture, satisfying the stem's requirement for an architectural element rather than a client or workload object.

Why this answer

Option A (IngressController Custom Resource) is correct because the Ingress Operator manages one or more IngressController custom resources that define how the OpenShift router is deployed and configured, including replicas, node placement, and endpoint publishing strategy. Option B (HAProxy-based router pods) is correct because the default OpenShift ingress data plane is implemented by router pods running HAProxy, which terminate and route external HTTP/HTTPS traffic to Services based on Routes and Ingress objects. Option D (Ingress Operator) is correct because it is the cluster operator responsible for deploying, configuring, and reconciling the IngressController resources and their backing router deployments.

Option C (ClusterNetwork operator) does not belong because it manages the cluster's pod network (OVN-Kubernetes/CNI, network plugin configuration), not the ingress routing layer. Option E (EgressFirewall controller) does not belong because it enforces egress traffic policies for namespaces, which is unrelated to the standard ingress architecture.

Exam trap

The trap is including network-related operators like ClusterNetwork or EgressFirewall because they sound infrastructure-related, but ingress architecture is specifically about the IngressController, router pods, and Ingress Operator.

Full explanation →

227

Multi-Selectmedium

An administrator wants to configure automated remediation for worker nodes that become unresponsive or experience hardware failure. Which TWO configurations or resources are required for a MachineHealthCheck to function properly? (Choose TWO)

Select 2 answers

A.A replica count specifying how many remediation pods to run.

B.Unhealthy conditions specifying the node status condition and timeout duration.

C.Match labels pointing to the target MachineSet or machine pool.

D.A ContainerRuntimeConfig specifying reboot parameters.

E.An OperatorGroup defining the namespace for the health check.

AnswersB, C

Unhealthy conditions define which node status conditions, such as Ready being Unknown, and the timeout duration before a node is deemed unhealthy. Without this threshold, the MachineHealthCheck cannot distinguish a failed node from a transient blip, so remediation never triggers.

Why this answer

Option B is correct because a MachineHealthCheck must define unhealthyConditions, which specify the node status condition type (for example Ready) and a timeout duration that determines how long the condition must persist before the node is considered unhealthy and remediation is triggered. Option C is correct because a MachineHealthCheck uses a selector with matchLabels to identify the target MachineSet or machine pool whose machines it will monitor and remediate. Option A is incorrect because MachineHealthCheck does not use a replica count for remediation pods; remediation is performed by deleting and recreating the unhealthy Machine via its MachineSet.

Option D is incorrect because ContainerRuntimeConfig is used to configure container runtime settings like pidsLimit or logLevel, not node health remediation. Option E is incorrect because an OperatorGroup defines the namespaces an Operator watches and is unrelated to MachineHealthCheck configuration.

Exam trap

EX280 often tests the confusion between MachineHealthCheck and other node-management resources, so candidates may pick unrelated options like ContainerRuntimeConfig or OperatorGroup, which serve entirely different purposes.

Full explanation →

228

Multi-Selecteasy

Which TWO tools or protocols can an administrator use to verify internal cluster DNS resolution from a pod? (Choose TWO)

Select 2 answers

A.ping

B.nslookup

C.ifconfig

D.top

E.dig

AnswersB, E

Running nslookup inside a pod queries the cluster DNS service directly, confirming that CoreDNS resolves internal service names to ClusterIP addresses. It satisfies the stem's requirement to verify internal cluster DNS resolution from a pod, testing the pod's configured resolver path end to end.

Why this answer

nslookup (B) is correct because it is a DNS query utility that can be run from inside a pod to resolve cluster service names against the cluster DNS server (CoreDNS/kube-dns) and confirm the returned A/AAAA records. dig (E) is also correct because it performs direct DNS lookups and shows detailed query/response data, including the resolver used and answer records, making it ideal for verifying internal cluster DNS resolution. ping (A) only tests ICMP reachability and name-to-address resolution incidentally, so it does not specifically validate DNS query behavior. ifconfig (C) merely displays network interface configuration and addresses, and top (D) shows process/resource usage, neither of which queries DNS.

Exam trap

EX280 often tests whether candidates confuse network troubleshooting tools (ping, ifconfig) with DNS-specific query tools (dig, nslookup), so the trap is selecting ping because it 'tests connectivity' when the question specifically asks about DNS resolution verification.

Full explanation →

229

MCQmedium

An administrator notices that a worker node is in a 'NotReady' state due to a storage failure. The administrator successfully replaces the underlying physical machine and wants to clear the old node object from the OpenShift 4.14 cluster. Which command should be used?

A.oc adm cordon worker-old --purge

B.oc patch machine worker-old --type=merge -p '{"spec":{"deleted":true}}'

C.oc remove node-status worker-old

D.oc delete node worker-old

AnswerD

Deleting the Node object removes the stale worker registration and its associated resources, letting the replacement machine rejoin cleanly. The node must first be drained or the machine powered off, since oc delete node acts on the cluster-scoped Node API object.

Why this answer

To remove a node object from an OpenShift cluster, the correct command is `oc delete node <node-name>`. This deletes the Node resource from the cluster, and if the node is managed by a MachineSet, the Machine object may also be deleted or replaced. In this scenario, the administrator has already replaced the physical machine, so deleting the old node object is appropriate.

Exam trap

EX280 often tests the correct command for node removal, tricking candidates into using cordon or drain instead of delete, or inventing non-existent commands like `oc remove`.

How to eliminate wrong answers

Option A is wrong because `oc adm cordon` only marks the node as unschedulable; it does not delete it, and `--purge` is not a valid flag for cordon. Option B is wrong because patching a Machine object with `deleted: true` is not a standard way to remove a node; Machine deletion is handled by the Machine API, but the command syntax is incorrect. Option C is wrong because `oc remove node-status` is not a valid command; there is no such subcommand.

Full explanation →

230

MCQeasy

You want to trigger a new build automatically whenever the base image in an ImageStream changes. What must be enabled in the BuildConfig?

A.Continuous Deployment trigger

B.WebHook trigger

C.ConfigChange trigger

D.ImageChange trigger

AnswerD

An ImageChange trigger watches the referenced ImageStream tag and starts a new build automatically when the base image updates. Enabling it in the BuildConfig satisfies the stem's requirement to trigger builds whenever the base image in the ImageStream changes.

Why this answer

The ImageChange trigger in a BuildConfig watches a specified ImageStream tag and starts a new build whenever that tag's image digest changes. This is the mechanism used to rebuild an application automatically when its base image (e.g., a builder image or a parent image) is updated. Configuring an ImageChange trigger with the base ImageStream as the source enables this behavior.

Exam trap

EX280 often tests the difference between BuildConfig triggers (ImageChange, ConfigChange, WebHook) and DeploymentConfig triggers, so candidates must not confuse a deployment trigger with a build trigger.

How to eliminate wrong answers

Option A is wrong because 'Continuous Deployment trigger' is not a BuildConfig trigger type; deployment triggers exist on DeploymentConfigs, not BuildConfigs. Option B is wrong because a WebHook trigger requires an external HTTP call (GitHub, GitLab, generic) to start a build, not an ImageStream change. Option C is wrong because a ConfigChange trigger starts a build only when the BuildConfig itself is modified, not when a base image changes.

Full explanation →

231

MCQhard

An administrator needs to ensure that no pod in the 'secure-zone' namespace can run with root privileges or use host networking. Which mechanism natively enforces this across all pods in the namespace?

A.Setting container securityContext in every deployment manually

B.Assigning a restrictive SecurityContextConstraints (SCC) policy to the service accounts running the pods

C.Configuring a NetworkPolicy to block root network namespaces

D.ResourceQuota limits on security capabilities

AnswerB

SCCs are the native OpenShift admission mechanism that validates pod security context against assigned policy before creation. A restrictive SCC bound to the namespace's service accounts blocks root UID, privileged mode and hostNetwork cluster-wide within that namespace.

Why this answer

SecurityContextConstraints (SCCs) are OpenShift's native cluster-level policy objects that control pod security settings such as running as root, host networking, and volume types. Assigning a restrictive SCC to the service accounts used by pods in the namespace enforces these restrictions across all pods.

Exam trap

EX280 often tests the misconception that NetworkPolicy or ResourceQuota can enforce pod security, when only SCCs (or Pod Security Admission in newer versions) control root and host networking.

How to eliminate wrong answers

Option A is wrong because manually setting securityContext in each deployment is not a namespace-wide enforcement mechanism and can be bypassed or forgotten. Option C is wrong because NetworkPolicy controls network traffic, not pod security contexts or host networking privileges. Option D is wrong because ResourceQuota limits resource consumption (CPU, memory, object counts), not security capabilities.

Full explanation →

232

Multi-Selecthard

An administrator is planning an OpenShift 4.14 cluster upgrade and wants to ensure that specific safety checks and conditions are met before proceeding. Which THREE conditions must be true for an upgrade to proceed smoothly? (Choose THREE)

Select 3 answers

A.All MachineConfigPools must be fully updated and not in a degraded state.

B.The cluster must be switched to the 'nightly' channel for all production upgrades.

C.All user-created namespaces must be temporarily deleted prior to upgrade.

D.The target version must be part of a valid, recommended update path from the current version.

E.All core cluster operators must report healthy status without being degraded.

AnswersA, D, E

MachineConfigPools must be fully updated and not degraded, because the Cluster Version Operator blocks upgrades while any pool is still rolling out or has failed nodes. This prevents the upgrade from compounding an existing configuration drift or unhealthy node state.

Why this answer

Option A is correct because OpenShift's Cluster Version Operator will not begin an upgrade while any MachineConfigPool is still updating or degraded; each pool must report Updated=True and Degraded=False so that node configuration rollouts complete cleanly. Option D is correct because upgrades must follow a supported path in the Cincinnati update graph — the target version must be a recommended or valid next hop from the current version, otherwise the CVO blocks the update. Option E is correct because all cluster operators (including the Cluster Version Operator itself) must report Available=True and Degraded=False; a degraded operator halts the upgrade to prevent further damage.

Option B is wrong because 'nightly' channels are for pre-release testing, not production upgrades, which should use stable/eus channels. Option C is wrong because user namespaces and workloads are not deleted before an upgrade; OpenShift upgrades are designed to preserve tenant workloads.

Exam trap

EX280 often tests the misconception that any newer version can be upgraded to directly, or that nightly channels are acceptable for production, when in fact OpenShift enforces valid update paths and stable channels for production.

Full explanation →

233

MCQmedium

What is the purpose of the 'postCommit' hook in a BuildConfig?

A.To notify an external system

B.To run tests on the image

C.To push the image to an external registry

D.To restart the Deployment

AnswerB

The postCommit hook executes commands inside a temporary container built from the freshly produced image, after the build completes. It satisfies the stem's purpose by running tests, such as integration or unit checks, against the actual image output, verifying the artefact before it is pushed or deployed.

Why this answer

The 'postCommit' hook in an OpenShift BuildConfig is designed to execute a command inside a temporary container created from the newly built image, immediately after the build completes and the image is committed. This is specifically intended for running tests, such as unit tests or integration tests, to validate the image's functionality before it is pushed or deployed. It does not notify external systems, push images, or restart deployments; those are handled by other mechanisms like webhooks, push secrets, or deployment triggers.

Exam trap

EX280 often tests the distinction between build hooks and other build lifecycle events, and candidates may confuse postCommit with post-build actions like pushing or notifying, leading them to select options that describe those actions instead of testing.

How to eliminate wrong answers

Option A is wrong because notifying an external system is typically done via build webhooks or custom notifications, not the postCommit hook. Option C is wrong because pushing the image to an external registry is controlled by the build's output configuration and push secrets, not the postCommit hook. Option D is wrong because restarting a Deployment is handled by image change triggers or manual rollout commands, not by the postCommit hook.

Full explanation →

234

MCQeasy

Which component in OpenShift 4.14 serves as the API entry point for managing MachineAPI resources like Machines and MachineSets?

A.Cluster Version Operator

B.Machine Config Operator

C.Operator Lifecycle Manager

D.Machine API Operator

AnswerD

The Machine API Operator manages the Machine and MachineSet custom resources and their controllers, exposing them through the cluster's API for lifecycle operations. It is the component that reconciles these MachineAPI objects, distinguishing it from the Cluster Baremetal Operator or Machine Config Operator, which handle node provisioning and configuration instead.

Why this answer

The Machine API Operator is the component that manages the lifecycle of MachineAPI resources such as Machines, MachineSets, and MachineHealthChecks. It deploys and reconciles the machine-api controllers and CRDs, making it the API entry point for cluster node provisioning in OpenShift 4.

Exam trap

EX280 often tests the confusion between the Machine API Operator (manages Machine/MachineSet resources) and the Machine Config Operator (manages node OS configuration), so candidates pick MCO when the question asks about MachineAPI resources.

How to eliminate wrong answers

Option A is wrong because the Cluster Version Operator manages cluster upgrades and release image reconciliation, not MachineAPI resources. Option B is wrong because the Machine Config Operator applies OS-level configuration (Ignition, kubelet, systemd) to nodes; it does not manage Machine or MachineSet objects. Option C is wrong because Operator Lifecycle Manager handles installation and upgrades of operators via Subscriptions and InstallPlans, not the MachineAPI.

Full explanation →

235

MCQhard

A cluster administrator has created a VolumeSnapshotClass and a VolumeSnapshot object targeting an active PVC. However, the VolumeSnapshot status never shows ready to use, and the underlying storage provider logs indicate snapshot creation failed due to missing cluster permissions. Which core OpenShift operator is primarily responsible for managing volume snapshot controllers and CRDs in OpenShift 4.14?

A.The Ingress Operator

B.The Cluster Storage Operator

C.The Authentication Operator

D.The Machine Config Operator

AnswerB

The Cluster Storage Operator installs and manages the CSI drivers, VolumeSnapshotClass and VolumeSnapshot CRDs, and their snapshot controllers across the cluster. Missing cluster permissions for snapshot creation therefore trace back to this operator's RBAC and controller management, not the CSI driver alone.

Why this answer

The Cluster Storage Operator is responsible for deploying and managing the CSI drivers, snapshot controllers, and associated CRDs (VolumeSnapshotClass, VolumeSnapshot, VolumeSnapshotContent) in OpenShift 4.x. When snapshot creation fails due to missing cluster permissions, the Cluster Storage Operator's deployed controller is the component that requires the RBAC to create snapshots via the CSI driver.

Exam trap

EX280 often tests confusion between storage operators and other cluster operators, tricking candidates into selecting the Machine Config Operator because it sounds infrastructure-related.

How to eliminate wrong answers

Option A is wrong because the Ingress Operator manages router and ingress controller components, not storage snapshot controllers. Option C is wrong because the Authentication Operator handles OAuth and identity providers, unrelated to volume snapshots. Option D is wrong because the Machine Config Operator manages node configuration and OS-level updates, not CSI snapshot CRDs or controllers.

Full explanation →

236

MCQeasy

Which command allows an administrator to view all currently configured SecurityContextConstraints in an OpenShift cluster?

A.oc describe scc-cluster

B.oc get securitycontextconstraints

C.oc get scc --namespaced

D.oc get policies -n openshift-config

AnswerB

`oc get securitycontextconstraints` queries the cluster's SCC API resource directly, returning every SecurityContextConstraints object currently defined. It satisfies the stem's requirement to view all configured SCCs without filtering or describing a single instance. The plural resource name ensures the full cluster-wide list is displayed.

Why this answer

SecurityContextConstraints (SCCs) are cluster-scoped resources in OpenShift, so they are queried with the standard 'oc get' verb using the resource name 'securitycontextconstraints' (or its short form 'scc'). The command 'oc get securitycontextconstraints' returns the list of all SCCs currently defined in the cluster, such as restricted, anyuid, hostaccess, and privileged. Because SCCs are not namespaced, no -n flag is required or meaningful.

Exam trap

EX280 often tests whether candidates confuse cluster-scoped resources (SCCs, PVs, nodes, clusterroles) with namespaced ones, tricking them into adding -n or --namespaced flags that don't apply.

How to eliminate wrong answers

Option A is wrong because 'scc-cluster' is not a valid resource type or SCC name — 'oc describe' requires an existing resource, and no SCC called 'scc-cluster' exists by default. Option C is wrong because SCCs are cluster-scoped resources and do not support the '--namespaced' flag; that flag would produce an error or be ignored. Option D is wrong because 'policies' is not the resource type for SCCs, and SCCs do not live in the openshift-config namespace — they are cluster-scoped.

Full explanation →

237

MCQhard

An OpenShift administrator needs to restrict developers so they cannot delete any PersistentVolumeClaims in the 'finance-prod' namespace, even though they have the 'admin' role. How can this override be achieved?

A.Add a negative annotation to the user's account object.

B.Configure a LimitRange object with delete blocks.

C.Create a DenyRoleBinding specifying delete verb exclusion for persistentvolumeclaims.

D.Create a custom Role that omits the 'delete' verb for persistentvolumeclaims, remove the 'admin' role binding, and bind this custom Role instead.

AnswerD

Replacing the built-in 'admin' ClusterRole binding with a custom Role that omits the delete verb on persistentvolumeclaims directly removes the permission, since OpenShift RBAC is additive and no other binding grants it. This satisfies the requirement that developers cannot delete PVCs in finance-prod despite previously holding admin.

Why this answer

To prevent deletion of PVCs despite the 'admin' role, you must remove the role binding that grants the admin role and instead bind a custom Role that includes all necessary permissions except the 'delete' verb for persistentvolumeclaims. This effectively overrides the default admin permissions by not granting delete rights.

Exam trap

EX280 often tests the misconception that RBAC supports deny rules or negative permissions; candidates may look for a DenyRoleBinding or annotation, but OpenShift only allows additive permissions.

How to eliminate wrong answers

Option A is wrong because there is no such thing as a negative annotation on a user account to deny specific verbs; OpenShift RBAC is additive and does not support deny rules. Option B is wrong because LimitRange objects enforce resource constraints, not API access controls. Option C is wrong because there is no DenyRoleBinding object in Kubernetes/OpenShift; RBAC only allows allow rules, and you cannot specify verb exclusions in a binding.

Full explanation →

238

Multi-Selecteasy

Which TWO tasks are typically performed by an OpenShift cluster administrator when managing worker node lifecycles? (Choose TWO)

Select 2 answers

A.Directly editing etcd data files on control plane nodes.

B.Manually compiling custom Linux kernel binaries on every node via SSH.

C.Writing custom source code for the Kubernetes API server.

D.Cordoning and draining nodes for operating system maintenance.

E.Applying labels to nodes to control MachineConfigPool membership.

AnswersD, E

Cordoning marks the node unschedulable so no new pods land there, while draining evicts existing workloads gracefully. Together they let the administrator safely take a worker offline for OS patching or upgrades without disrupting running applications.

Why this answer

Option D is correct because cordoning a node marks it as unschedulable (kubectl cordon) and draining it evicts running pods (kubectl drain) so the node can safely undergo OS patching, reboots, or other maintenance without disrupting workloads. Option E is correct because node labels are the mechanism that determines which nodes belong to a given MachineConfigPool, allowing the administrator to target specific MachineConfig updates to defined groups of worker nodes. Option A is not a typical administrator task, since etcd data files on control plane nodes are managed by the etcd operator and should not be edited directly.

Option B is incorrect because OpenShift manages the OS via immutable RHCOS and MachineConfig, not by manually compiling kernels over SSH. Option C is incorrect because writing Kubernetes API server source code is upstream development work, not cluster administration.

Exam trap

EX280 often tests the misconception that administrators manually manage nodes via SSH or edit control plane components, when in reality OpenShift uses declarative management through MachineConfigs and the MCO, and node lifecycle tasks like cordoning/draining and labeling are the correct administrative actions.

Full explanation →

239

MCQeasy

Which service account is used by default for pods that do not specify a service account in their manifest?

A.builder

B.default

C.system

D.deployer

AnswerB

Pods without a serviceAccountName field are automatically assigned the 'default' service account in their namespace. OpenShift creates this account in every namespace, granting it minimal permissions, so the pod authenticates to the API with that identity unless the manifest specifies otherwise.

Why this answer

Every namespace in Kubernetes/OpenShift is automatically provisioned with a ServiceAccount named 'default'. When a pod manifest omits the spec.serviceAccountName (or spec.serviceAccount) field, the admission controller assigns this 'default' ServiceAccount to the pod. OpenShift additionally creates 'builder' and 'deployer' ServiceAccounts per namespace for build and deployment controllers, but these are never auto-assigned to arbitrary pods.

Exam trap

EX280 often tests whether candidates confuse OpenShift's auto-created per-namespace ServiceAccounts (builder, deployer, default) with the one actually assigned when a pod omits the field — the answer is always 'default', not builder or deployer.

How to eliminate wrong answers

Option A is wrong because 'builder' is a per-namespace ServiceAccount used by OpenShift BuildConfig pods to run builds, not the fallback for generic workloads. Option C is wrong because 'system' is not a ServiceAccount name — 'system:serviceaccount:<ns>:<name>' is the identity format used in RBAC bindings, not a default account. Option D is wrong because 'deployer' is a per-namespace ServiceAccount used by DeploymentConfig rollout pods, not the default for pods that omit the field.

Full explanation →

240

MCQmedium

An administrator created a Route but external clients receive a 503 Service Unavailable error when attempting to access it. Upon checking the endpoints of the Service referenced by the Route, the administrator discovers there are zero endpoints listed. What is the most likely cause?

A.The Route YAML has an invalid TLS certificate format.

B.The Ingress controller pods have crashed across all worker nodes.

C.The cluster DNS operator is degraded.

D.The Service selector labels do not match any active Pod labels.

AnswerD

A Service with zero endpoints means its selector matches no running Pod labels, so the router has no backend to forward to and returns 503; correcting the selector or Pod labels restores endpoints and traffic.

Why this answer

A Service with zero endpoints means its label selector matched no running Pods. The Service's Endpoints object is populated by the endpoints controller, which continuously watches for Pods whose labels match the Service's spec.selector. If the selector labels don't match any active Pod labels, the endpoint list stays empty, and the router/Ingress controller has no backend to forward traffic to, returning 503 Service Unavailable.

Exam trap

EX280 often tests the distinction between Route-level failures (TLS, hostname) and Service-level failures (selector mismatch, readiness), so candidates must trace the 503 back to the empty Endpoints object rather than blaming the router or DNS.

How to eliminate wrong answers

Option A is wrong because an invalid TLS certificate on the Route would cause TLS handshake failures or certificate warnings, not a 503 with zero Service endpoints. Option B is wrong because crashed Ingress controller pods would affect all Routes cluster-wide and would not explain a Service with zero endpoints. Option C is wrong because a degraded DNS operator would cause name resolution failures, not empty Service endpoints.

Full explanation →

241

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.

Full explanation →

242

Multi-Selecteasy

An administrator is preparing to perform maintenance on worker nodes in an OpenShift 4.14 cluster. Which TWO commands or actions are part of the standard workflow to safely prepare a node for maintenance? (Choose TWO)

Select 2 answers

A.Run 'oc delete node <node-name> --force' immediately before stopping services.

B.Run 'oc adm cordon <node-name>' to mark the node as unschedulable.

C.Stop the kubelet service directly via systemctl without cordoning.

D.Run 'oc adm drain <node-name> --delete-emptydir-data --ignore-daemonsets' to evict existing pods.

E.Scale the MachineConfigPool replicas to zero.

AnswersB, D

Cordoning sets the node's spec.unschedulable field to true, so the scheduler places no new pods there while existing workloads keep running. This satisfies the requirement to stop new scheduling before draining, preventing rescheduling onto a node about to undergo maintenance.

Why this answer

Option B is correct because 'oc adm cordon <node-name>' marks the node as unschedulable, preventing the scheduler from placing new pods on it while existing workloads continue running, which is the required first step before maintenance. Option D is correct because 'oc adm drain <node-name> --delete-emptydir-data --ignore-daemonsets' safely evicts the node's pods; --ignore-daemonsets is needed since DaemonSet pods cannot be evicted, and --delete-emptydir-data allows removal of pods using emptyDir volumes. Together, cordon then drain is the standard OpenShift 4.14 workflow to prepare a worker node for maintenance.

Option A is wrong because force-deleting the Node object does not gracefully evict pods and can leave workloads in an inconsistent state. Option C is wrong because stopping kubelet without cordoning or draining leaves pods abruptly terminated and the node still marked schedulable. Option E is wrong because scaling a MachineConfigPool to zero replicas is not a node-maintenance procedure and would disrupt the pool's managed nodes.

Exam trap

EX280 often tests whether candidates confuse the destructive 'oc delete node --force' with the graceful cordon-then-drain workflow, or forget that DaemonSet pods require --ignore-daemonsets to allow drain to complete.

Full explanation →

243

MCQhard

An administrator configures an OAuth provider with user mapping method 'lookup'. What does this mapping method do when a user authenticates for the first time?

A.It rejects all login attempts unless the user is member of the 'system:masters' group.

B.It requires that a User object already exists and is pre-associated with the identity; otherwise, login fails.

C.It automatically creates a new User object and links it to the incoming Identity.

D.It maps all incoming users to a single shared service account.

AnswerB

The 'lookup' mapping method performs no provisioning: it searches for an existing User object already linked to the incoming identity and authenticates against it. If no pre-associated User exists, authentication fails, satisfying the stem's first-login scenario where no automatic account creation occurs.

Why this answer

The 'lookup' mapping method in OpenShift's OAuth configuration requires that a User object already exists and is pre-associated with the incoming Identity. When a user authenticates for the first time, the OAuth server checks if an Identity exists for the provider's user ID; if not, it attempts to find a User with that identity. If no such User exists, login fails.

This is in contrast to the 'claim' method, which dynamically creates User and Identity objects based on claims from the identity provider.

Exam trap

EX280 often tests the distinction between OAuth mapping methods, particularly confusing 'lookup' with 'claim', where 'claim' auto-creates users while 'lookup' requires pre-existing User objects.

How to eliminate wrong answers

Option A is wrong because 'lookup' does not enforce membership in 'system:masters'; that group is for cluster administrators and is unrelated to the mapping method. Option C is wrong because automatic creation of a new User object and linking it to the Identity is the behavior of the 'claim' mapping method, not 'lookup'. Option D is wrong because mapping all users to a single shared service account is not a supported mapping method; it would be a severe security risk and is not how OpenShift OAuth works.

Full explanation →

244

MCQeasy

An administrator wants to check the status of all cluster operators, specifically verifying that the Network and DNS operators are healthy. Which command should be run?

A.oc get clusteroperators

B.oc get operators --cluster

C.oc describe operators

D.oc adm check health

AnswerA

oc get clusteroperators lists every cluster operator with its availability, progress and degraded status columns, letting the administrator confirm whether the Network and DNS operators report healthy. It queries the operator state directly without needing per-operator inspection commands.

Why this answer

The `oc get clusteroperators` command lists all ClusterOperators in an OpenShift cluster, showing their AVAILABLE, PROGRESSING, DEGRADED, and other status conditions. This is the standard way to verify the health of core operators like the Network operator (network.operator.openshift.io) and DNS operator (dns.operator/default). Administrators use this command to quickly assess whether any operator is degraded or unavailable.

Exam trap

EX280 often tests the exact resource name and command syntax for cluster-wide health checks, and candidates may confuse `oc get clusteroperators` with non-existent commands like `oc adm check health` or `oc get operators`.

How to eliminate wrong answers

Option B is wrong because `oc get operators --cluster` is not a valid oc command; the correct resource is `clusteroperators` (or `co`). Option C is wrong because `oc describe operators` targets a non-existent resource type and would fail; `oc describe clusteroperator <name>` is the correct form for detailed output. Option D is wrong because `oc adm check health` does not exist as a command in OpenShift; health checks are performed via `oc get clusteroperators` or `oc adm top` for resource usage.

Full explanation →

245

MCQeasy

What is the primary difference between PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs)?

A.PVs represent actual cluster storage resources, while PVCs represent user requests for storage.

B.PVs only support block mode, while PVCs only support filesystem mode.

C.PVs are created by developers, while PVCs are created by cluster administrators.

D.PVs are namespace-scoped, while PVCs are cluster-scoped.

AnswerA

A PersistentVolume is the cluster-scoped, provisioned storage object itself, whereas a PersistentVolumeClaim is a namespaced request that binds to a matching PV. This satisfies the stem's demand for the primary difference: PVs supply capacity, PVCs consume it, decoupling pod specifications from the underlying storage implementation.

Why this answer

PersistentVolumes (PVs) are cluster-level storage objects that represent the actual backing storage (NFS, iSCSI, cloud disk, etc.) provisioned by an admin or dynamically by a StorageClass. PersistentVolumeClaims (PVCs) are namespace-scoped requests from a user/pod for a certain size and access mode, which the control plane binds to a matching PV. This separation of 'supply' (PV) from 'demand' (PVC) is the core abstraction in Kubernetes/OpenShift storage.

Exam trap

EX280 often tests the direction of the PV/PVC relationship — candidates confuse which object is the 'supply' (cluster-scoped PV) versus the 'request' (namespace-scoped PVC), or assume one is admin-only and the other developer-only without realizing dynamic provisioning blurs that line.

How to eliminate wrong answers

Option B is wrong because both PVs and PVCs support Filesystem and Block volume modes (set via volumeMode), not a block-only vs filesystem-only split. Option C is wrong because it reverses the roles: cluster administrators typically create PVs (or StorageClasses for dynamic provisioning), while developers/users create PVCs. Option D is wrong because it inverts the scopes: PVs are cluster-scoped, while PVCs are namespace-scoped.

Full explanation →

246

MCQmedium

An administrator needs to configure a Route that handles encrypted communication both from the client to the router AND from the router to the backend pod. Which termination type is required?

A.reencrypt

B.passthrough

C.edge

D.secure-tunnel

AnswerA

Reencrypt termination decrypts at the router, then re-encrypts traffic to the backend pod using a separate certificate, satisfying the requirement for encryption on both the client-to-router and router-to-backend legs. Edge and passthrough terminate only one leg, leaving the backend connection unencrypted.

Why this answer

The reencrypt termination type allows the router to decrypt incoming TLS traffic and then re-encrypt it before forwarding to the backend pod, enabling end-to-end encryption with separate certificates for the client-to-router and router-to-pod legs. This satisfies the requirement for encrypted communication both from client to router and router to backend. Edge termination only encrypts client-to-router, while passthrough does not decrypt at the router at all.

Exam trap

EX280 often tests the confusion between edge and reencrypt, where candidates might think edge encrypts both legs, but only reencrypt provides encryption from router to pod.

How to eliminate wrong answers

Option B is wrong because passthrough forwards encrypted traffic directly to the pod without decryption at the router, so the router cannot re-encrypt or manage certificates, and it does not provide separate encryption for the router-to-pod leg. Option C is wrong because edge termination decrypts at the router and sends plain HTTP to the backend, so the router-to-pod leg is not encrypted. Option D is wrong because 'secure-tunnel' is not a valid OpenShift Route termination type; the valid types are edge, passthrough, and reencrypt.

Full explanation →

247

MCQhard

A team maintains a StatefulSet named `orders` with three replicas in the `sales` namespace. Each replica must receive its own 20Gi PersistentVolumeClaim that survives Pod restarts and rescheduling, and the storage backend supports the ReadWriteOnce access mode. The administrator needs to define the storage requirement so that every replica automatically gets an independent, stable PVC bound before the Pod starts. Which approach should the administrator use?

A.Define the volume inline in the StatefulSet Pod template using `emptyDir: {medium: Memory}` and set `sizeLimit: 20Gi` so each replica receives its own isolated 20Gi scratch volume.

B.Add a `volumeClaimTemplates` entry in the StatefulSet spec defining a 20Gi claim with the required access mode and StorageClass, and mount it with a `volumeMounts` reference matching the template name.

C.Create three separate PersistentVolumeClaims manually with names `orders-0`, `orders-1`, and `orders-2`, then add three distinct volume entries to the Pod template, each referencing one of those claim names.

D.Create a single standalone PersistentVolumeClaim named `orders-data` in the `sales` namespace and reference it from each replica using a volume entry with `persistentVolumeClaim.claimName: orders-data`.

AnswerB

The `volumeClaimTemplates` field instructs the StatefulSet controller to generate one PVC per replica, named with the pattern `<template-name>-<statefulset-name>-<ordinal>`. Each replica therefore receives a dedicated 20Gi claim bound before the Pod is scheduled, and the claim persists across restarts and rescheduling, satisfying the independent and stable storage requirement.

Why this answer

StatefulSets provide per-replica stable storage through `volumeClaimTemplates`, which the controller expands into one PVC per ordinal. This guarantees each replica gets its own 20Gi ReadWriteOnce claim bound before the Pod starts, and the claim persists across restarts and rescheduling. Standalone claims, inline emptyDir volumes, or manually named claims cannot deliver the independent, automatically provisioned identity-based storage the scenario requires.

Exam trap

The trap here is assuming that any PVC referenced in the Pod template gives each replica its own volume, when only `volumeClaimTemplates` generates distinct claims per ordinal.

Full explanation →

248

MCQmedium

A cluster administrator wants to create a VolumeSnapshot of a database PVC. Which API group must the VolumeSnapshotClass belong to?

A.snapshot.storage.k8s.io

B.storage.k8s.io

C.csi.storage.k8s.io

D.volumesnapshot.openshift.io

AnswerA

VolumeSnapshotClass resources are defined in the snapshot.storage.k8s.io API group, which the external-snapshotter project provides. This satisfies the stem's requirement for snapshotting a database PVC, since the CSI snapshot CRDs (VolumeSnapshot, VolumeSnapshotClass, VolumeSnapshotContent) all live in that group, not in storage.k8s.io or v1.

Why this answer

VolumeSnapshotClass resources are part of the Kubernetes CSI snapshot API group 'snapshot.storage.k8s.io'. This API group defines the VolumeSnapshot, VolumeSnapshotContent, and VolumeSnapshotClass custom resources. Therefore, the VolumeSnapshotClass must belong to this API group to be recognized by the CSI snapshot controller.

Exam trap

EX280 often tests the correct API group for custom resources. Candidates might confuse 'snapshot.storage.k8s.io' with 'storage.k8s.io' or 'csi.storage.k8s.io', but only the former is used for VolumeSnapshotClass.

How to eliminate wrong answers

Option B is wrong because 'storage.k8s.io' is the API group for StorageClass, VolumeAttachment, and CSIDriver, but not for VolumeSnapshotClass. Option C is wrong because 'csi.storage.k8s.io' is used for CSI driver-specific resources like CSINode, but not for snapshot classes. Option D is wrong because 'volumesnapshot.openshift.io' is not a standard API group; OpenShift uses the upstream Kubernetes snapshot API group.

Full explanation →

249

MCQmedium

A developer wants to ensure that a pod's temporary storage does not exceed 2Gi and that the pod is terminated or throttled if it exceeds this limit. Where should this ephemeral storage limit be declared?

A.In the container's spec.resources.limits under 'ephemeral-storage'.

B.In the emptyDir volume specification under 'sizeLimit'.

C.In the StorageClass under 'parameters.ephemeralLimit'.

D.In the persistentVolumeClaim under 'spec.ephemeral'.

AnswerA

Ephemeral storage is governed by the container-level resources.limits field, where ephemeral-storage requests and limits are declared alongside CPU and memory. Placing the 2Gi limit there satisfies the stem's requirement to cap and evict pods exceeding that threshold.

Why this answer

Ephemeral storage limits are declared in the container's spec.resources.limits under the 'ephemeral-storage' key, just like CPU and memory. This causes the kubelet to enforce the limit by evicting the pod when local ephemeral storage usage exceeds the configured value. The limit applies to the container's writable layer, emptyDir volumes, and logs, making it the correct place for a 2Gi cap.

Exam trap

EX280 often tests the distinction between emptyDir sizeLimit and container ephemeral-storage limits, tricking candidates into choosing the volume-level cap when the question asks for pod termination on exceeding the limit.

How to eliminate wrong answers

Option B is wrong because emptyDir's sizeLimit only caps that specific volume's size and does not terminate or throttle the pod when exceeded — it just prevents further writes to that volume. Option C is wrong because StorageClass parameters are for dynamic provisioning of persistent volumes and have no 'ephemeralLimit' parameter. Option D is wrong because PVCs do not have a 'spec.ephemeral' field; ephemeral storage is a container resource, not a PVC attribute.

Full explanation →

250

Multi-Selectmedium

An administrator is configuring a new StorageClass in OpenShift Container Platform 4.14. Which TWO parameters or fields are valid and commonly used specifications within a StorageClass manifest? (Choose TWO)

Select 2 answers

A.podSecurityContext

B.nodeAffinityRules

C.reclaimPolicy

D.maximumSnapshotLimit

E.volumeBindingMode

AnswersC, E

ReclaimPolicy is a valid StorageClass field controlling volume behaviour after PVC deletion, accepting Delete or Retain. It satisfies the stem's requirement for commonly used specifications within a StorageClass manifest, governing whether underlying storage is automatically removed or preserved for manual reclamation.

Why this answer

Option C (reclaimPolicy) is correct because a StorageClass manifest supports the reclaimPolicy field, which determines what happens to a PersistentVolume after its PersistentVolumeClaim is deleted—valid values are Delete and Retain, with Delete being the default for dynamically provisioned volumes. Option E (volumeBindingMode) is correct because it is a standard StorageClass field that controls when volume binding and dynamic provisioning occur, with valid values Immediate and WaitForFirstConsumer, the latter being essential for topology-aware scheduling. The other options are not StorageClass fields: podSecurityContext (A) is a Pod/container security setting, nodeAffinityRules (B) is not a valid StorageClass parameter (node affinity belongs to PersistentVolume nodeAffinity or Pod scheduling), and maximumSnapshotLimit (D) is not a recognized StorageClass specification in OpenShift 4.14.

Exam trap

EX280 often tests whether candidates can distinguish StorageClass fields from Pod-level or PV-level fields, since similarly named constructs like nodeAffinity and securityContext appear in other Kubernetes objects.

Full explanation →

251

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.

Full explanation →

252

MCQmedium

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

A.oc get nodes -o wide

B.oc describe clusteroperators

C.oc adm upgrade

D.oc get clusterversion version -o yaml

AnswerC

This command displays the current cluster version, available updates, and any upgrade conditions or blockers. It is the standard tool to assess upgrade readiness and see recommended updates. It directly provides the information needed to verify that the cluster is in a healthy state before initiating an upgrade, making it the correct first step.

Why this answer

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

This command directly surfaces that information.

Exam trap

The trap here is confusing general cluster inspection commands with the specific upgrade status command that reports available updates and blockers.

Full explanation →

253

MCQeasy

Which namespace contains the Machine Config Operator (MCO) and its associated daemon pods in OpenShift 4.14?

A.openshift-machine-config-operator

B.openshift-infra

C.openshift-machine-api

D.openshift-cluster-version

AnswerA

The Machine Config Operator and its machine-config-daemon pods run in the openshift-machine-config-operator namespace, the dedicated system namespace OpenShift 4.14 creates for MCO components. Other namespaces, such as openshift-config or default, do not host these operator pods.

Why this answer

The Machine Config Operator (MCO) in OpenShift 4.14 runs in the `openshift-machine-config-operator` namespace. This namespace hosts the MCO deployment and its associated daemon pods (machine-config-daemon) that apply machine configurations to nodes. The other namespaces serve different cluster functions.

Exam trap

EX280 often tests namespace locations of core operators, and candidates may confuse `openshift-machine-config-operator` with `openshift-machine-api` due to similar naming.

How to eliminate wrong answers

Option B is wrong because `openshift-infra` is a legacy namespace used in OpenShift 3 for infrastructure components, not for MCO in OpenShift 4. Option C is wrong because `openshift-machine-api` contains the Machine API Operator and related components for cluster machine management, not the MCO. Option D is wrong because `openshift-cluster-version` hosts the Cluster Version Operator (CVO) which manages cluster updates, not the MCO.

Full explanation →

254

MCQmedium

An administrator installed an Operator via OperatorHub and selected a specific update channel. Later, the administrator wants to switch the Subscription to a different update channel. How should this be performed?

A.Edit the Subscription custom resource and modify the 'spec.channel' field to the new channel.

B.Delete the Operator's CSV and reinstall the Operator from scratch via the CLI.

C.Modify the OperatorGroup target namespace to force a channel renegotiation.

D.Patch the ClusterServiceVersion directly with the new channel identifier.

AnswerA

Update channels are declared in the Subscription custom resource's spec.channel field. Editing that field to the new channel value causes the Operator Lifecycle Manager to reconcile and begin serving updates from the selected channel, without reinstalling the Operator.

Why this answer

To switch an Operator's update channel, you edit the Subscription custom resource and change the spec.channel field to the desired channel name. The Operator Lifecycle Manager (OLM) then reconciles the Subscription and upgrades/downgrades the Operator to the latest version available in that channel. This is the supported and non-disruptive method.

Exam trap

EX280 often tests the misconception that you must reinstall an Operator to change its update channel, when in fact editing the Subscription's spec.channel is sufficient.

How to eliminate wrong answers

Option B is wrong because deleting the CSV and reinstalling from scratch is disruptive, unnecessary, and does not preserve the Subscription; it also may leave residual resources. Option C is wrong because modifying the OperatorGroup target namespace does not affect channel selection; OperatorGroup defines the namespaces the Operator watches, not the update channel. Option D is wrong because patching the CSV directly with a channel identifier is not how OLM works; the CSV does not have a channel field, and manual edits can break the Operator's lifecycle management.

Full explanation →

255

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.

Full explanation →

256

MCQeasy

How do you view the currently active OAuth identity providers in an OpenShift cluster?

A.oc get identityproviders

B.oc describe auth

C.oc get oauth cluster -o yaml

D.oc get configmap oauth -n openshift-config

AnswerC

The oauth cluster resource is a singleton holding the cluster-wide OAuth configuration, including the identityProviders list. Retrieving it as YAML with oc get oauth cluster -o yaml shows every currently active identity provider and its settings.

Why this answer

The OAuth server configuration in OpenShift is stored in a cluster-scoped custom resource named 'cluster' of type 'oauth.config.openshift.io'. Running `oc get oauth cluster -o yaml` retrieves this resource and displays the full configuration, including the `spec.identityProviders` list that defines the currently active identity providers. This is the canonical way to inspect which identity providers are configured and their order of precedence.

Exam trap

EX280 often tests whether candidates know that OAuth configuration is stored in a cluster-scoped custom resource called 'oauth' (not a ConfigMap or a resource named 'identityproviders'), and that the correct command to view it is `oc get oauth cluster -o yaml`.

How to eliminate wrong answers

Option A is wrong because there is no resource type called 'identityproviders' in OpenShift; identity providers are defined within the OAuth cluster resource, not as standalone objects. Option B is wrong because 'auth' is not a valid OpenShift resource type; the correct resource is 'oauth' (oauth.config.openshift.io), and 'describe' would not show the full YAML configuration anyway. Option D is wrong because the OAuth configuration is not stored in a ConfigMap named 'oauth' in the openshift-config namespace; it is a custom resource, and while some configuration may be in ConfigMaps, the active identity providers are part of the OAuth cluster resource.

Full explanation →

257

Multi-Selectmedium

Which THREE components are involved in TLS termination for routes?

Select 3 answers

A.Secret

B.Route

C.IngressController

D.Service

E.ConfigMap

AnswersA, B, C

The Secret holds the TLS certificate and private key consumed during handshake. It must be of type kubernetes.io/tls and referenced by the Route, supplying the cryptographic material the IngressController presents to clients, satisfying the scenario's requirement for certificate storage.

Why this answer

In OpenShift, TLS termination for routes requires a Secret (option A) that holds the TLS certificate and private key, which the router uses to serve HTTPS. The Route (option B) is the object where you configure TLS termination (e.g., spec.tls.termination: edge, passthrough, or reencrypt) and reference the certificate. The IngressController (option C) is the router component that actually performs TLS termination and enforces the route's TLS settings.

A Service (option D) only provides internal load balancing to pods and does not handle TLS certificates or termination. A ConfigMap (option E) stores non-sensitive configuration data and is not used to hold TLS certificates or keys for route termination.

Exam trap

EX280 often tests the confusion between components that store TLS material (Secret) and those that define routing (Route) or manage the router (IngressController), leading candidates to incorrectly include Service or ConfigMap.

Full explanation →

258

Multi-Selecthard

An administrator is managing operator subscriptions and wants to ensure that an operator is automatically updated when new versions are released in the channel. Which THREE conditions or configuration settings must be satisfied? (Choose THREE)

Select 3 answers

A.The OperatorGroup must correctly encompass the target namespace scope.

B.A healthy CatalogSource must be available providing the operator manifests.

C.The Subscription must have 'spec.installPlanApproval: Automatic' configured.

D.The Cluster Version Operator must have auto-upgrade enabled for third-party operators.

E.The global pull secret must be deleted so OLM can fetch unauthenticated updates.

AnswersA, B, C

The OperatorGroup defines which namespaces the subscription's operator watches; if its scope excludes the target namespace, the operator cannot be installed there, so automatic channel updates never apply. Correctly encompassing the target namespace is therefore a prerequisite for the update mechanism to function.

Why this answer

Option A is correct because the OperatorGroup defines the set of target namespaces (its spec.targetNamespaces or the namespace it resides in) that the operator's CSV will be deployed to, and OLM will not resolve or upgrade a Subscription whose OperatorGroup scope does not cover the intended namespace. Option B is correct because OLM resolves available operator versions from the package manifests served by a CatalogSource; if that CatalogSource is unhealthy or missing, no new bundles are discovered and no upgrade can be triggered. Option C is correct because spec.installPlanApproval: Automatic on the Subscription causes OLM to automatically approve the generated InstallPlan when a newer bundle appears in the channel, which is exactly what enables unattended updates.

Option D is not correct because the Cluster Version Operator manages OpenShift platform components, not third-party OLM operators, and has no auto-upgrade setting governing them. Option E is not correct because deleting the global pull secret would break image pulls from authenticated registries; OLM uses the existing pull secrets and does not require unauthenticated catalog access.

Exam trap

EX280 often tests the OLM update chain — candidates pick plausible-sounding but incorrect options like CVO auto-upgrade or pull secret manipulation, missing that the three real prerequisites are OperatorGroup scope, CatalogSource health, and Automatic InstallPlan approval.

Full explanation →

259

Multi-Selectmedium

Which TWO of the following are valid ways to trigger a build in OpenShift?

Select 2 answers

A.Restarting the OpenShift cluster

B.Sending a HTTP POST to the webhook URL

C.Executing 'oc start-build'

D.Updating a ConfigMap

E.Changing a Namespace

AnswersB, C

Webhook triggers let external systems start builds without cluster credentials: a POST to the build config's webhook URL fires the build server-side. This satisfies the stem's requirement for a valid trigger mechanism, alongside the GitHub, GitLab and generic webhook variants OpenShift exposes.

Why this answer

Option B is correct because OpenShift BuildConfigs can expose generic, GitHub, or GitLab webhook endpoints, and issuing an HTTP POST to that webhook URL (e.g., via curl) triggers a new build of the associated BuildConfig. Option C is correct because the 'oc start-build' command is the standard CLI method to manually start a build, either by BuildConfig name (with options like --from-build, --follow, or --from-dir) or by referencing an existing build. Restarting the OpenShift cluster (A) is an administrative action that does not initiate builds, updating a ConfigMap (D) only changes configuration data and does not by itself start a build, and changing a Namespace (E) is a context/scope operation with no build-triggering semantics.

Exam trap

EX280 often tests the distinction between valid build triggers and unrelated cluster operations, so candidates may mistakenly think that restarting the cluster or modifying resources like ConfigMaps or Namespaces can trigger builds.

Full explanation →

260

Multi-Selectmedium

An administrator is configuring a DeploymentConfig in OpenShift and wants to set up automated triggers for new rollouts. Which TWO trigger types are natively supported in a DeploymentConfig spec? (Choose two.)

Select 2 answers

A.PeriodicTrigger

B.ConfigChange

C.WebhookTrigger

D.GitTrigger

E.ImageChange

AnswersB, E

ConfigChange is a native DeploymentConfig trigger type that rolls out a new revision when the DC template changes.

Why this answer

DeploymentConfigs support ConfigChange (triggering when the DeploymentConfig template changes) and ImageChange (triggering when a referenced ImageStream tag updates).

Full explanation →

261

Multi-Selecthard

Which THREE actions can be performed using the oc rollout subcommand in OpenShift? (Choose three.)

Select 3 answers

A.Pausing a rollout to make multiple configuration updates

B.Triggering a direct source build from a local directory

C.Viewing the revision history of a deployment

D.Checking the current status of an ongoing rollout

E.Scaling the number of replicas up or down

AnswersA, C, D

The oc rollout pause command halts a deployment rollout, allowing several configuration changes to be applied before resuming, so updates deploy together rather than triggering separate rollouts. This satisfies the stem's requirement for an action available through the oc rollout subcommand.

Why this answer

Option A is correct because `oc rollout pause` suspends a deployment rollout so you can apply multiple configuration changes before resuming with `oc rollout resume`, preventing intermediate rollouts. Option C is correct because `oc rollout history` displays the revision history of a deployment or deployment config, including revision numbers and change causes. Option D is correct because `oc rollout status` reports the current status of an ongoing rollout, waiting until it completes or fails.

Option B is not part of `oc rollout`; direct source builds from a local directory are performed with `oc start-build --from-dir` or `oc new-build`. Option E is not part of `oc rollout`; scaling replicas is done with `oc scale` (or `oc scale dc/deployment`).

Exam trap

EX280 often tests the distinction between `oc rollout` and other `oc` subcommands like `oc scale` and `oc start-build`, so candidates must remember that `oc rollout` is exclusively for managing rollout lifecycle, not for scaling or building.

Full explanation →

262

Multi-Selecthard

Which THREE actions can be performed when managing Route objects in OpenShift? (Choose THREE)

Select 3 answers

A.Attaching a container storage volume directly inside the Route spec

B.Allocating a direct BGP peering session from the Route object

C.Specifying TLS termination as edge, passthrough, or reencrypt

D.Defining a custom hostname for external access

E.Configuring path-based routing under spec.path

AnswersC, D, E

The route's spec.tls.termination field accepts edge, passthrough, or reencrypt, controlling where TLS is decrypted. This satisfies the stem because termination mode selection is a genuine Route management action, determining whether the router or the pod handles encryption.

Why this answer

Option C is correct because a Route's spec.tls.termination field accepts exactly edge, passthrough, or reencrypt, controlling where TLS is decrypted (at the router for edge, not at all for passthrough, and at the router then re-encrypted to the backend for reencrypt). Option D is correct because spec.host lets you define the externally reachable hostname (e.g., app.example.com) that the router uses to match incoming requests. Option E is correct because spec.path allows path-based routing, so a single hostname can direct /api to one Service and /web to another.

Option A is wrong because storage volumes belong to Pods/Deployments via PersistentVolumeClaims, not to Route specs, which only handle HTTP(S) ingress. Option B is wrong because BGP peering is a networking concern handled by the cluster's SDN/OVN or MetalLB, not by Route objects, which are HAProxy-based ingress definitions.

Exam trap

EX280 often tests the specific capabilities of Route objects versus other OpenShift resources. Candidates might incorrectly assume Routes can manage storage or network peering, but Routes are strictly for HTTP/HTTPS ingress with TLS and path-based routing features.

Full explanation →

263

MCQmedium

You are configuring an OAuth identity provider in OpenShift using the HTPasswdPasswordIdentityProvider method. Where must the generated htpasswd user credentials file be stored so the cluster authentication operator can read it?

A.In the 'openshift-authentication' namespace as a ConfigMap

B.In the target user's project namespace as a Secret

C.In the 'openshift-config' namespace as a Secret

D.On the master node filesystem at '/etc/origin/master/htpasswd'

AnswerC

The OAuth authentication operator reads identity provider configuration only from the openshift-config namespace, so the htpasswd file must exist there as a Secret. Storing it elsewhere, such as openshift-config-managed or a user project, prevents the operator from resolving the HTPasswd identity provider.

Why this answer

In OpenShift 4, the OAuth configuration is defined in the cluster-scoped OAuth custom resource, and any referenced identity provider secrets must live in the openshift-config namespace. The authentication operator watches this namespace and mounts the referenced Secret into the openshift-authentication pods. Therefore, the htpasswd file must be uploaded as a Secret in openshift-config and referenced via the htpasswd.fileData.name field.

Exam trap

EX280 often tests the OpenShift 3 vs OpenShift 4 configuration model, so candidates who remember the old /etc/origin/master/htpasswd path or assume any namespace works will pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because openshift-authentication is where the OAuth server pods run, not where identity provider secrets are stored; ConfigMaps are also not used for htpasswd data. Option B is wrong because user project namespaces are not watched by the authentication operator and cannot supply cluster-wide identity provider credentials. Option D is wrong because /etc/origin/master/htpasswd is the OpenShift 3.x path on master nodes; OpenShift 4 is operator-managed and does not use that filesystem location.

Full explanation →

264

Multi-Selectmedium

Which TWO methods can an administrator use to troubleshoot why a pod cannot connect to a remote Service? (Choose TWO)

Select 2 answers

A.Verifying that the target service has valid endpoints pointing to running pods.

B.Using nc or curl from inside a debug pod to test connectivity to the service IP and port.

C.Restarting the cluster storage provider pods.

D.Deleting all persistent volume claims.

E.Modifying the global MachineConfig pool.

AnswersA, B

A Service without valid endpoints, caused by a mismatched selector or unready pods, silently drops traffic. Checking endpoints confirms whether the Service actually maps to running pod IPs, satisfying the requirement to verify the target before deeper network diagnosis.

Why this answer

Option A is correct because a Service only forwards traffic to pods that match its selector and are Ready, so checking that the Service has valid Endpoints (via kubectl get endpoints or kubectl describe svc) confirms whether the Service is actually backed by running pods and is essential to diagnosing connectivity failures. Option B is correct because running nc or curl from inside a debug pod directly tests L3/L4 reachability to the Service ClusterIP and port, helping isolate whether the problem is DNS, network policy, kube-proxy, or the application itself. Options C, D, and E are unrelated to Service connectivity troubleshooting: restarting storage provider pods addresses storage/CSI issues, deleting PVCs affects persistent volume binding, and modifying a MachineConfig pool changes node-level configuration, none of which diagnose why a pod cannot reach a remote Service.

Exam trap

EX280 often tests troubleshooting methodology, and candidates may choose actions that are unrelated to networking, like restarting storage pods or deleting PVCs, instead of focusing on Service endpoints and connectivity tests.

Full explanation →

265

Multi-Selecteasy

Which TWO actions can an administrator perform using the 'oc adm' command set related to cluster management? (Choose TWO)

Select 2 answers

A.Write custom container Dockerfiles on cluster nodes.

B.Initiate and manage cluster upgrades.

C.Manage user project request limits directly.

D.Cordon or drain cluster nodes for maintenance.

E.Create application deployments directly without YAML files.

AnswersB, D

The `oc adm upgrade` subcommand initiates and monitors cluster version upgrades, satisfying the stem's cluster-management constraint. It queries and applies available OpenShift release channels, letting administrators approve or schedule upgrades directly. This is a genuine administrative action within the `oc adm` command set, unlike workload-level operations.

Why this answer

Option B is correct because the 'oc adm upgrade' subcommand (e.g., 'oc adm upgrade --to=<version>') lets administrators initiate, monitor, and manage OpenShift cluster upgrades, including viewing available update channels and approving upgrades. Option D is correct because 'oc adm cordon <node>' and 'oc adm drain <node>' are administrative commands used to mark nodes unschedulable and evict workloads for maintenance. Option A is incorrect because Dockerfiles are authored in a build context and built with tools like 'docker build' or 'oc new-build', not via 'oc adm' on cluster nodes.

Option C is incorrect because project request limits are managed through ClusterResourceQuota or the project request template, not directly via 'oc adm'. Option E is incorrect because application deployments are created with 'oc new-app' or 'oc create', not through the 'oc adm' administrative command set.

Exam trap

EX280 often tests the boundary between 'oc' (developer) and 'oc adm' (administrator) commands, tricking candidates into selecting developer tasks like 'oc new-app' as if they were administrative 'oc adm' operations.

Full explanation →

266

Multi-Selectmedium

An administrator wants to check the status of Machine API provisioning and verify that all machines are in a running state. Which TWO commands or resource inspections should the administrator perform? (Choose TWO)

Select 2 answers

A.Run 'oc adm machine-status'.

B.Run 'oc get clusteroperators --machines'.

C.Run 'oc get machines -A' to list all provisioned machines across namespaces.

D.Run 'oc get machinesets -A' to check replica counts and desired states.

E.Run 'oc get machineconfigpools --machines'.

AnswersC, D

Running `oc get machines -A` queries the Machine API's Machine resources cluster-wide, listing every provisioned machine and its current phase across all namespaces. This directly satisfies the stem's requirement to verify that all machines are in a running state, since the PHASE column reveals whether each machine reports Running.

Why this answer

Option C is correct because 'oc get machines -A' lists all Machine objects across all namespaces, letting the administrator inspect each machine's PHASE (e.g., Running, Provisioned, Provisioning) to confirm they are in a running state. Option D is correct because 'oc get machinesets -A' shows each MachineSet's DESIRED, CURRENT, and READY replica counts, which verifies that the desired number of machines has been provisioned and is healthy. Option A is wrong because 'oc adm machine-status' is not a valid oc adm subcommand.

Option B is wrong because 'oc get clusteroperators' does not accept a '--machines' flag and reports ClusterOperator status, not Machine API provisioning. Option E is wrong because 'oc get machineconfigpools' does not accept a '--machines' flag and reports MachineConfigPool node configuration status, not Machine provisioning state.

Exam trap

EX280 often tests whether candidates know the actual 'oc' commands and resource names for Machine API inspection, so made-up commands like 'oc adm machine-status' or invalid flags like '--machines' are common distractors.

Full explanation →

267

Multi-Selectmedium

An administrator must grant a service account permission to create and manage PersistentVolumeClaims in the project 'analytics', while allowing it to view but not modify PersistentVolumes cluster-wide. Which two actions satisfy these requirements? (Choose two.)

Select 2 answers

A.Bind the 'edit' ClusterRole to the service account using a ClusterRoleBinding.

B.Bind the 'cluster-reader' ClusterRole to the service account using a ClusterRoleBinding.

C.Bind the 'edit' ClusterRole to the service account in the 'analytics' namespace using a RoleBinding.

D.Bind the 'view' ClusterRole to the service account in the 'analytics' namespace using a RoleBinding.

E.Create a ClusterRole granting get, list, and watch on persistentvolumes, and bind it to the service account with a ClusterRoleBinding.

AnswersC, E

The edit ClusterRole includes permissions to create, delete, and modify PersistentVolumeClaims within a namespace. Binding it with a RoleBinding scopes those rights to the analytics project, granting the service account full PVC management exactly as required, without extending any cluster-wide write access to PersistentVolumes.

Why this answer

PVCs are namespaced, so the edit ClusterRole bound via a RoleBinding in analytics grants create and manage rights scoped to that project. PersistentVolumes are cluster-scoped, so read-only access requires a ClusterRole with get, list, and watch bound by a ClusterRoleBinding. Together these satisfy management of claims and read-only visibility of volumes.

Exam trap

The trap here is assuming a namespaced RoleBinding can grant access to the cluster-scoped PersistentVolume resource, which requires a ClusterRoleBinding instead.

Full explanation →

268

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.

Full explanation →

269

MCQeasy

Which OpenShift resource defines the desired state of a containerized application, including replica count and image version?

A.Deployment

B.Pod

C.ImageStream

D.Service

AnswerA

A Deployment declares the desired state for a containerised application, specifying the replica count and container image version. The Deployment controller continuously reconciles actual cluster state against this declaration, recreating or updating pods to match, which satisfies the stem's requirement for defining desired state.

Why this answer

A Deployment in OpenShift defines the desired state of a containerized application, including the replica count, container image version, and update strategy. It manages ReplicaSets and Pods declaratively, ensuring the specified number of replicas and image version are maintained. This makes Deployment the correct resource for defining desired state including replicas and image version.

Exam trap

EX280 often tests the distinction between workload controllers (Deployment) and networking or image abstractions (Service, ImageStream) — candidates may incorrectly pick Pod or Service when asked about desired state including replicas and image version.

How to eliminate wrong answers

Option B is wrong because a Pod represents a single running instance of a container and does not define desired replica count or manage rolling updates. Option C is wrong because an ImageStream is an OpenShift abstraction for tracking container image tags and streams, not for defining application desired state or replica count. Option D is wrong because a Service provides a stable network endpoint for accessing Pods, not the desired state of the application deployment.

Full explanation →

270

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.

Full explanation →

271

Multi-Selecthard

Which THREE components are part of a Kustomize configuration?

Select 3 answers

A.kustomization.yaml

B.BuildConfigs

C.Resources

D.Helm Charts

E.Patches

AnswersA, C, E

The main entry point.

Why this answer

In Kustomize, the kustomization.yaml file (Option A) is the mandatory entry-point manifest that declares which resources, patches, and other directives Kustomize should process, so it is a core component of any Kustomize configuration. Resources (Option C) are the base Kubernetes manifests (Deployments, Services, ConfigMaps, etc.) listed under the resources field that Kustomize reads and composes. Patches (Option E) are the strategic-merge or JSON 6902 overlays declared under fields like patchesStrategicMerge and patches that customize those resources per environment.

BuildConfigs (Option B) are OpenShift build objects, not Kustomize components, and Helm Charts (Option D) belong to the Helm package manager, which Kustomize can reference only via a helmCharts generator but is not itself a Kustomize component.

Exam trap

EX280 often tests whether candidates confuse Kustomize with Helm — the trap is selecting Helm Charts as a Kustomize component when Kustomize is deliberately template-free and uses kustomization.yaml, resources, and patches.

Full explanation →

272

MCQmedium

An administrator notices that client source IP addresses are lost when traffic hits a Service of type NodePort, appearing instead as a node IP. Which field in the Service specification should be changed to 'Local' to preserve client source IPs?

A.externalTrafficPolicy: Local

B.publishNotReadyAddresses: true

C.sessionAffinity: ClientIP

D.ipFamilyPolicy: RequireDualStack

AnswerA

Setting `externalTrafficPolicy: Local` stops kube-proxy from masquerading traffic to other nodes, so only pods on the receiving node answer and the original client source IP survives. The default `Cluster` policy forwards across nodes and rewrites the source to a node IP, which is exactly the loss described.

Why this answer

externalTrafficPolicy: Local preserves the client source IP by only routing traffic to pods on the same node that received the request, avoiding the SNAT that occurs when kube-proxy forwards to a pod on another node. With the default Cluster policy, traffic can be forwarded to any node's pod, causing the source IP to be rewritten to the node's IP. Setting it to Local ensures the original client IP is retained for the backend pod.

Exam trap

EX280 often tests the misconception that sessionAffinity or other Service fields can preserve source IPs, when only externalTrafficPolicy: Local achieves this by preventing SNAT.

How to eliminate wrong answers

Option B is wrong because publishNotReadyAddresses controls whether DNS records include not-ready endpoints, not source IP preservation. Option C is wrong because sessionAffinity: ClientIP only ensures that requests from the same client IP stick to the same pod; it does not prevent SNAT or preserve the original source IP. Option D is wrong because ipFamilyPolicy: RequireDualStack configures dual-stack IP families for the Service, unrelated to source IP preservation.

Full explanation →

273

MCQmedium

A pod fails to start, and the event log shows a Multi-Attach error for volume 'pvc-xyz'. What is the root cause of this error?

A.A ReadWriteOnce volume is attempting to be attached to a second node while still attached to the first.

B.The PVC storage class has volumeBindingMode set to Immediate.

C.The storage backend has run out of physical disk capacity.

D.The CSI driver pod has crashed on the master node.

AnswerA

A ReadWriteOnce volume permits attachment to only one node at a time. When a second node tries to attach it while the first still holds it, the CSI driver reports Multi-Attach. This satisfies the stem's stated error condition.

Why this answer

The Multi-Attach error occurs when a ReadWriteOnce (RWO) volume is already attached to one node and a pod on another node tries to attach it. RWO volumes can only be attached to a single node at a time. This is common with block storage like AWS EBS or GCE PD.

Exam trap

The trap is confusing Multi-Attach with other volume errors, such as provisioning failures or capacity issues, when the root cause is the RWO access mode and node affinity.

How to eliminate wrong answers

Option B is wrong because volumeBindingMode Immediate affects when a volume is provisioned, not multi-attach errors. Option C is wrong because running out of disk capacity would cause a different error, such as 'no space left'. Option D is wrong because a crashed CSI driver would prevent any volume operations, not specifically cause a multi-attach error.

Full explanation →

274

MCQeasy

An administrator needs to create a passthrough Route that preserves client certificates and forwards encrypted traffic directly to the backend pod. Which spec configuration is required?

A.spec: tls: termination: passthrough

B.spec: tls: termination: reencrypt

C.spec: tls: termination: edge

D.spec: tls: insecureEdgeTerminationPolicy: Allow

AnswerA

Passthrough termination makes the router forward the TLS handshake untouched, so the backend pod terminates encryption and sees the client certificate directly. Edge or re-encrypt termination would decrypt at the router, breaking the requirement to preserve client certificates end to end.

Why this answer

A passthrough Route uses 'spec.tls.termination: passthrough', which tells the HAProxy router to forward the encrypted TLS connection directly to the backend pod without decrypting it. This preserves client certificates end-to-end and is required when the backend must handle TLS itself.

Exam trap

EX280 often tests whether candidates pick 'reencrypt' thinking it preserves client certs, when only 'passthrough' forwards the encrypted stream end-to-end without router termination.

How to eliminate wrong answers

Option B is wrong because 'reencrypt' terminates TLS at the router and re-encrypts to the backend, which breaks end-to-end client certificate preservation. Option C is wrong because 'edge' terminates TLS at the router and forwards plain HTTP to the backend, so client certificates never reach the pod. Option D is wrong because 'insecureEdgeTerminationPolicy' is a sub-field that controls HTTP fallback behavior for edge/reencrypt Routes, not a termination type, and it is meaningless for passthrough.

Full explanation →

275

MCQeasy

Which YAML key in a StorageClass definition specifies the CSI plugin responsible for provisioning the storage?

A.storagePlugin

B.plugin

C.driverName

D.provisioner

AnswerD

provisioner defines the driver plugin name (e.g., ebs.csi.aws.com).

Why this answer

The provisioner field in a StorageClass identifies the CSI driver (or in-tree provisioner) responsible for dynamically provisioning PersistentVolumes. For CSI-based storage, its value is the driver name registered by the CSI plugin, such as ebs.csi.aws.com or csi.ceph.com. Without a valid provisioner, the StorageClass cannot create PVs.

Exam trap

EX280 often tests exact YAML key names — candidates confuse provisioner with driverName because CSI terminology uses 'driver' elsewhere.

How to eliminate wrong answers

Option A is wrong because storagePlugin is not a valid StorageClass field in the storage.k8s.io/v1 API. Option B is wrong because plugin is not a recognized key; it resembles legacy or invented terminology. Option C is wrong because driverName is a field used inside CSI volume attributes or CSIDriver objects, not the top-level StorageClass key that names the provisioner.

Full explanation →

276

MCQhard

An administrator creates a StorageClass with volumeBindingMode: WaitForFirstConsumer. A user creates a PVC using this StorageClass. What will be the initial phase of the PVC?

A.Provisioning

B.Bound

C.Pending

D.Available

AnswerC

WaitForFirstConsumer defers provisioning until a pod using the PVC is scheduled, so no PersistentVolume is bound at creation. The PVC therefore sits in Pending, satisfying the stem's constraint that binding waits for a consumer, rather than immediately entering Bound as with Immediate mode.

Why this answer

When a StorageClass has volumeBindingMode: WaitForFirstConsumer, the PVC will remain in the Pending phase until a pod that uses it is scheduled. This is because the volume binding is delayed until the pod's scheduling requirements are known, allowing the volume to be provisioned in the same zone as the pod.

Exam trap

EX280 often tests the misconception that a PVC is immediately Bound when using WaitForFirstConsumer, when it actually stays Pending until a pod is scheduled.

How to eliminate wrong answers

Option A is wrong because 'Provisioning' is not a valid PVC phase; the phases are Pending, Bound, Lost, etc. Option B is wrong because the PVC cannot be Bound until a pod is scheduled and the volume is provisioned. Option D is wrong because 'Available' is a phase for PersistentVolumes, not PVCs.

Full explanation →

277

MCQeasy

How can you view the list of all SCCs available in the cluster?

A.oc get scc

B.oc show scc

C.oc describe scc

D.oc list scc

AnswerA

Running oc get scc queries the OpenShift API for the SecurityContextConstraints resource type, listing every SCC defined in the cluster. This directly satisfies the requirement to view all available SCCs, since SCCs are cluster-scoped objects retrieved through the standard oc get verb.

Why this answer

The correct command to view the list of all Security Context Constraints (SCCs) in an OpenShift cluster is oc get scc. This command retrieves and displays the SCC resources, which define the security contexts under which pods can run.

Exam trap

EX280 often tests basic oc command syntax, and candidates may confuse the verbs get, describe, and list, or invent non-existent commands like show.

How to eliminate wrong answers

Option B is wrong because oc show scc is not a valid oc command; the correct verb is get. Option C is wrong because oc describe scc requires a specific SCC name to provide detailed information, and without a name, it will not list all SCCs. Option D is wrong because oc list scc is not a valid oc command; the correct verb is get.

Full explanation →

278

MCQhard

An administrator configures a Pod with a volume type of hostPath. What is a key security risk or operational limitation of using hostPath in a production multi-tenant OpenShift cluster?

A.Pods using hostPath can access node filesystems, breaking container isolation and posing security risks.

B.hostPath volumes automatically expire and delete data after 24 hours.

C.hostPath requires an external CSI driver to be installed.

D.hostPath is incompatible with Linux nodes and only works on Windows worker nodes.

AnswerA

hostPath mounts a directory from the node's filesystem into the Pod, so a compromised container can read or modify node files and potentially escape isolation. This breaks the tenant boundary expected in a multi-tenant OpenShift cluster.

Why this answer

A hostPath volume mounts a directory or file from the node's filesystem directly into the pod. This breaks the container isolation boundary because the pod can read or write node-level files — including /etc, /var/lib/kubelet, or the container runtime socket — enabling privilege escalation, data exfiltration, or node compromise. In multi-tenant clusters this is a serious security risk.

Exam trap

EX280 often tests whether candidates recognize hostPath as a node-isolation break — the exam expects you to know it is blocked by the restricted SCC and is a multi-tenant security anti-pattern.

How to eliminate wrong answers

Option B is wrong because hostPath volumes have no expiration or TTL — data persists on the node until manually deleted, which is actually the opposite of the stated behavior. Option C is wrong because hostPath is a built-in Kubernetes volume type that requires no CSI driver; it is implemented directly by the kubelet. Option D is wrong because hostPath works on Linux nodes (it is the primary use case) and is not Windows-only — the claim inverts reality.

Full explanation →

279

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.

Full explanation →

280

MCQmedium

You are preparing to deploy an application to an OpenShift Container Platform 4.14 cluster. The application is defined across multiple Kubernetes manifests, and you need to ensure that a set of common labels and a namespace prefix are applied to all resources. You want to use Kustomize to manage this without writing custom scripts. Which of the following best describes how to achieve this using the oc CLI?

A.Run oc apply -f kustomization.yaml to apply the customized resources directly.

B.Run oc new-app --kustomize . to deploy the application from the Kustomize directory.

C.Use the oc kustomize command to generate the customized manifests, then pipe the output to oc apply -f -.

D.Create a kustomization.yaml file that references the base manifests, then run oc apply -k . to apply the customized resources.

AnswerD

The oc apply -k command is specifically designed to apply resources defined in a kustomization.yaml file. It processes the base manifests, applies any transformations such as common labels and name prefixes, and then submits the resulting resources to the cluster. This is the standard, declarative way to use Kustomize with OpenShift.

Why this answer

Kustomize is integrated into the oc CLI, and the oc apply -k command is the correct way to apply a kustomization directory. It reads the kustomization.yaml, applies transformations like common labels and name prefixes, and then applies the resulting resources to the cluster. This declarative approach is preferred over manual generation and piping.

Exam trap

The trap here is assuming that oc apply -f can process a kustomization.yaml file directly, but it cannot because that file is not a Kubernetes resource manifest.

Full explanation →

281

MCQeasy

An administrator needs to check the internal DNS resolution of a service named 'backend' within the 'production' namespace from a debug pod. Which DNS name is fully qualified and valid within the cluster?

A.backend.production.pod.cluster.local

B.backend.production.router.default.svc

C.svc.production.backend.cluster.local

D.backend.production.svc.cluster.local

AnswerD

backend.production.svc.cluster.local follows Kubernetes' cluster DNS schema: service, namespace, "svc", then the cluster domain. It satisfies the stem's requirement for a fully qualified name resolving the 'backend' service in the 'production' namespace from any debug pod, without relying on search-domain expansion.

Why this answer

In OpenShift/Kubernetes, the fully qualified domain name (FQDN) for a Service follows the pattern <service>.<namespace>.svc.cluster.local. For the service 'backend' in the 'production' namespace, the correct FQDN is backend.production.svc.cluster.local. This DNS name resolves to the ClusterIP of the service, allowing internal cluster communication.

Exam trap

EX280 often tests the exact ordering of the DNS components, and candidates may mistakenly put the namespace before the service name or use 'pod' instead of 'svc', leading to incorrect answers.

How to eliminate wrong answers

Option A is wrong because it uses 'pod.cluster.local' instead of 'svc.cluster.local'; pod DNS names are typically of the form <pod-ip>.<namespace>.pod.cluster.local and are not used for service resolution. Option B is wrong because it includes 'router.default.svc', which is not part of the standard service DNS hierarchy and suggests a route or ingress, not a service. Option C is wrong because it reverses the order of service and namespace; the correct order is service first, then namespace, then 'svc', then 'cluster.local'.

Full explanation →

282

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.

Full explanation →

283

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.

Full explanation →

284

MCQhard

An administrator is inspecting an OpenShift 4.14 cluster and notices that the MachineConfigPool for workers is in a degraded state because a MachineConfig failed to apply. Where should the administrator look to find the exact error encountered by the Machine Config Daemon on the affected nodes?

A.Review the OperatorHub catalog source logs in openshift-marketplace.

B.Check the logs of the machine-config-daemon pods in the openshift-machine-config-operator namespace.

C.Run 'oc adm node-logs --role=worker' to view kernel panic messages.

D.Inspect the Cluster Version Operator logs in openshift-cluster-version.

AnswerB

The Machine Config Daemon runs on each node and reports apply failures; its pod logs in the openshift-machine-config-operator namespace contain the precise error, such as a failed systemd unit or file write, that degraded the pool.

Why this answer

The Machine Config Daemon runs as a pod on each node in the openshift-machine-config-operator namespace and is responsible for applying rendered MachineConfigs and reporting errors back to the MCO. When a MachineConfig fails to apply and the pool goes degraded, the exact error (e.g., failed systemd unit, invalid Ignition, file conflict) is recorded in the machine-config-daemon pod logs on the affected node.

Exam trap

EX280 often tests whether candidates know that MachineConfig apply errors live in the machine-config-daemon pod logs in openshift-machine-config-operator, not in CVO or OperatorHub logs.

How to eliminate wrong answers

Option A is wrong because OperatorHub catalog source logs in openshift-marketplace relate to OLM operator installation, not to MachineConfig application. Option C is wrong because 'oc adm node-logs --role=worker' retrieves node journal logs (useful for kernel/systemd issues) but does not surface the MCD's structured apply errors, and kernel panics are not the typical failure mode for a bad MachineConfig. Option D is wrong because the Cluster Version Operator logs in openshift-cluster-version track cluster upgrades, not per-node MachineConfig application failures.

Full explanation →

285

MCQmedium

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

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

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

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

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

AnswerD

This snippet correctly sets the provisioner to csi.example.com, enables allowVolumeExpansion, and includes the parameter type: fast. The apiVersion and kind are appropriate for a StorageClass. This definition will allow dynamic provisioning using the specified CSI driver and permit expansion of PVCs created from this class.

Why this answer

A StorageClass for a CSI driver must set the provisioner field to the CSI driver name. The allowVolumeExpansion field enables PVC expansion, and parameters pass driver-specific settings. The correct snippet includes these without extraneous fields that could alter behavior or are not requested.

Exam trap

The trap here is using kubernetes.io/csi as the provisioner and specifying the driver in parameters, which is incorrect for CSI-based StorageClasses.

Full explanation →

286

Multi-Selecthard

Which TWO of the following actions occur when a user is deleted from an OpenShift cluster using 'oc delete user <username>'? (Choose TWO)

Select 2 answers

A.The User resource object is removed from the cluster database.

B.External identity provider records are automatically deleted from LDAP or OIDC servers.

C.All namespaces owned or created by the user are permanently deleted.

D.The user's active OAuth access and refresh tokens are revoked.

E.All RoleBindings and ClusterRoleBindings referencing the user are automatically deleted.

AnswersA, D

Deleting a User resource removes only that object from etcd; the identity provider entry and any Identity objects linked to it remain untouched. This satisfies the stem's constraint that the action targets the cluster's User object specifically, since `oc delete user` never reaches external identity stores or automatically prunes associated Identity records.

Why this answer

Option A is correct because 'oc delete user <username>' removes the User resource object itself from etcd, the cluster's backing datastore, so the user no longer exists as an OpenShift API object. Option D is correct because deleting the User triggers revocation of that user's OAuth access tokens and refresh tokens, invalidating existing sessions so the identity can no longer authenticate. Option B is wrong because OpenShift does not write back to external identity providers; LDAP or OIDC records are managed outside the cluster and are untouched.

Option C is wrong because namespaces are independent resources and are not garbage-collected when a user is deleted. Option E is wrong because RoleBindings and ClusterRoleBindings are not automatically removed; they may remain and reference a now-nonexistent user until manually cleaned up.

Exam trap

EX280 often tests the misconception that deleting a User cascades to external IdP accounts, namespaces, or RBAC bindings — candidates must remember that User deletion only removes the cluster-side User object and its OAuth tokens.

Full explanation →

287

MCQeasy

Which command is used to start a new build from an existing BuildConfig named 'frontend'?

A.oc trigger-build frontend

B.oc run-build frontend

C.oc start-build frontend

D.oc build frontend

AnswerC

The oc start-build command triggers a new build from an existing BuildConfig, referencing it by name. This satisfies the requirement to initiate a build from the 'frontend' BuildConfig without supplying source or binary input manually.

Why this answer

oc start-build frontend is the correct command to trigger a new build from an existing BuildConfig named 'frontend'. It creates a new Build object, which the build controller then executes according to the BuildConfig's strategy (Source, Docker, or Custom).

Exam trap

EX280 often tests whether candidates invent plausible-sounding but nonexistent oc subcommands (trigger-build, run-build, build), so they pick a wrong verb instead of the real start-build.

How to eliminate wrong answers

Option A is wrong because oc trigger-build is not a valid oc subcommand; there is no such verb in the OpenShift CLI. Option B is wrong because oc run-build does not exist; oc run is for creating pods/deployments from images, not builds. Option D is wrong because oc build is not a valid subcommand either; the correct verb is start-build.

Full explanation →

288

Multi-Selecthard

Which THREE of the following are required when configuring an OIDC identity provider?

Select 3 answers

A.Client Secret reference

B.Htpasswd file path

C.Client ID

D.LDAP bind password

E.Issuer URL

AnswersA, C, E

A client secret reference is mandatory because the OpenID Connect authorisation code flow requires the relying party to authenticate itself to the token endpoint. Red Hat OpenShift, through its OAuth configuration, stores this as a Kubernetes Secret and references it, satisfying the provider's confidential-client credential requirement during code exchange.

Why this answer

When configuring an OIDC identity provider, the Client ID (C) is required because it uniquely identifies the relying party/application to the OpenID Provider during the authorization code flow. The Client Secret reference (A) is also required so the application can authenticate itself to the token endpoint and securely exchange the authorization code for tokens. The Issuer URL (E) is required because it identifies the OpenID Provider's metadata document (typically at /.well-known/openid-configuration), enabling discovery of endpoints such as authorization_endpoint, token_endpoint, and jwks_uri.

The Htpasswd file path (B) is not part of OIDC; it belongs to HTTP Basic authentication using a local password file. The LDAP bind password (D) is also unrelated to OIDC, as it is used for LDAP directory authentication, not for OpenID Connect token exchange.

Exam trap

EX280 often tests the confusion between identity provider types, tricking candidates into selecting LDAP or HTPasswd fields (bind password, htpasswd path) that belong to entirely different provider configurations.

Full explanation →

289

MCQmedium

A developer is using Kustomize to manage environment overlays (dev and prod) for an OpenShift application. Where should the common base resources be referenced in the prod/kustomization.yaml file?

A.Under the includes: key

B.Under the bases: key

C.Under the resources: key

D.Under the overlays: key

AnswerC

Kustomize overlays compose a base by listing its directory path under the resources: field in prod/kustomization.yaml. This pulls the shared base manifests into the prod build, letting the overlay apply prod-specific patches, replicas and image tags without duplicating common resources.

Why this answer

In modern Kustomize (v3+ and the version bundled with OpenShift's `oc kustomize`), overlays reference their base directory using the `resources:` field in kustomization.yaml. The prod overlay lists `../../base` (or the base path) under `resources:`, which causes Kustomize to compose the base manifests with the prod-specific patches and transformations. This is the canonical way to build a layered configuration.

Exam trap

EX280 often tests the deprecated `bases:` vs current `resources:` distinction — candidates who learned Kustomize before v3 pick `bases:` because it was historically correct.

How to eliminate wrong answers

Option A is wrong because `includes:` is not a valid Kustomize field — it does not exist in the kustomization.yaml schema. Option B is wrong because `bases:` was deprecated in Kustomize v2.1.0 and removed in v3; while older OpenShift documentation used it, current `oc kustomize` rejects or warns on it, and the exam expects the modern field. Option D is wrong because `overlays:` is not a kustomization.yaml key — overlays are directories that reference bases, not a field you declare inside a kustomization file.

Full explanation →

290

MCQeasy

An administrator needs to provision a new user named 'sarah' using the HTPasswd identity provider. After updating the htpasswd file and secret, Sarah logs in successfully. What command should the administrator run to verify that OpenShift has successfully created the corresponding User object for Sarah?

A.oc get account sarah

B.oc get user sarah

C.oc get identity htp:sarah

D.oc describe htpasswd-user sarah

AnswerB

Running `oc get user sarah` queries the cluster's User resource directly, confirming that the HTPasswd identity provider's successful login triggered automatic User object creation. This satisfies the stem's verification requirement precisely, since the User object is the artefact OpenShift generates on first authentication, not the Identity or Secret.

Why this answer

When an HTPasswd identity provider authenticates a user for the first time, OpenShift automatically creates a User object whose name matches the username supplied in the htpasswd file. The correct command to confirm this is `oc get user sarah`, which queries the cluster-scoped User resource. This verifies that the identity provider successfully mapped the login to a User object.

Exam trap

EX280 often tests the distinction between Identity and User objects in OpenShift's authentication model, causing candidates to pick `oc get identity` when the question specifically asks about the User object.

How to eliminate wrong answers

Option A is wrong because 'account' is not a valid OpenShift resource type — there is no `oc get account` command. Option C is wrong because `oc get identity htp:sarah` would list the Identity object (named with the provider prefix 'htp:'), not the User object the question asks about. Option D is wrong because 'htpasswd-user' is not a real OpenShift resource kind, so the command would fail.

Full explanation →

291

Multi-Selectmedium

An administrator needs to identify worker nodes that require attention during an upgrade or maintenance. Which TWO conditions or states on a node object indicate potential issues or special maintenance states? (Choose TWO)

Select 2 answers

A.Running=Normal

B.SchedulingDisabled

C.Active=True

D.Schedulable=True

E.NotReady

AnswersB, E

SchedulingDisabled marks a node cordoned by an administrator, meaning no new pods are scheduled onto it. This directly signals a special maintenance state, letting the administrator identify nodes deliberately drained or reserved before an upgrade proceeds.

Why this answer

Option B (SchedulingDisabled) is correct because this condition on a node object indicates the node has been cordoned (via `oc adm cordon` or `kubectl cordon`), meaning it is marked unschedulable and will not accept new pods, which is a special maintenance state administrators must track during upgrades. Option E (NotReady) is correct because the Ready condition set to NotReady (or Unknown) means the node's kubelet is not reporting healthy status to the control plane, signaling a potential problem requiring attention. Options A (Running=Normal) and C (Active=True) are not valid node conditions in OpenShift/Kubernetes node status, so they do not indicate anything meaningful.

Option D (Schedulable=True) is the normal, healthy state indicating the node can accept pods, so it does not represent an issue or special maintenance state.

Exam trap

EX280 often tests whether candidates can distinguish normal healthy states (Schedulable=True, Ready=True) from maintenance/issue states (SchedulingDisabled, NotReady), so picking 'Schedulable=True' as an issue is the common mistake.

Full explanation →

292

Multi-Selecthard

An administrator is troubleshooting a storage performance issue on an OpenShift cluster using Container Storage Interface (CSI) drivers. Which THREE actions or diagnostic commands are effective for investigating CSI driver health and provisioner issues? (Choose THREE)

Select 3 answers

A.Verify the CSI driver configuration by checking the CSIDriver and CSINode cluster resources.

B.Inspect events on the pending PersistentVolumeClaim using oc describe pvc <pvc-name>.

C.Modify the kubelet configuration file on control plane nodes to increase storage timeout values.

D.Run systemctl restart csi-driver on every worker node to force reconnection to the storage array.

E.Check the logs of the external CSI provisioner deployment running in the driver's namespace.

AnswersA, B, E

Checking CSIDriver and CSINode resources confirms whether the driver is registered and whether its node plugins are present on each node, directly satisfying the stem's need to investigate CSI driver health. Missing CSINode entries reveal node-plugin registration failures that block provisioning, isolating the fault before deeper provisioner log analysis.

Why this answer

Option A is correct because the CSIDriver and CSINode cluster resources define how the CSI driver is registered and which nodes it is available on; inspecting them with oc get csidriver and oc get csinode (or oc describe) reveals misconfigurations such as missing node registration or incorrect attach/detach behavior that cause provisioning failures. Option B is correct because oc describe pvc <pvc-name> surfaces Kubernetes events on the pending PVC, including provisioner errors, topology/volume binding failures, and storage class issues, which are the fastest way to identify why a volume is not being dynamically provisioned. Option E is correct because the external CSI provisioner (typically the csi-provisioner sidecar in the driver controller deployment) emits logs that show gRPC errors, storage backend API failures, and leader-election or RBAC problems directly tied to provisioning issues.

Option C is not correct because kubelet storage timeout values are not the standard diagnostic or remediation for CSI provisioner problems, and modifying control plane kubelet config does not address CSI controller-side provisioning. Option D is not correct because there is no systemctl unit named csi-driver on worker nodes; CSI drivers run as DaemonSets/Deployments in OpenShift, so restarting pods via oc rollout restart or oc delete pod is the proper approach.

Exam trap

EX280 often tests the difference between valid diagnostic commands and invalid or harmful actions, and candidates may choose options that seem plausible but involve unsupported or risky procedures like modifying kubelet configs or restarting systemd services.

Full explanation →

293

MCQeasy

Where do you define the default image pull secrets for all service accounts in a namespace?

A.In the ClusterOperator configuration

B.In the Namespace metadata

C.By linking the secret to the 'default' service account

D.In the project configuration object

AnswerC

Linking the image pull secret to the namespace's 'default' service account makes OpenShift use those credentials for pods that specify no service account, since every pod defaults to it. This satisfies the requirement of defining pull secrets for all service accounts in the namespace.

Why this answer

Default image pull secrets for all service accounts in a namespace are defined by linking the secret to the 'default' service account. When a pod is created without specifying a service account, it uses the 'default' service account, and any image pull secrets attached to that service account are automatically used.

Exam trap

EX280 often tests the misconception that image pull secrets can be set at the namespace level, when they are actually linked to service accounts.

How to eliminate wrong answers

Option A is wrong because ClusterOperator configuration manages cluster-wide operators, not image pull secrets. Option B is wrong because Namespace metadata does not include image pull secrets. Option D is wrong because the project configuration object (if it exists) does not control image pull secrets.

Full explanation →

294

MCQeasy

An administrator needs to configure re-encrypt TLS termination on a Route. In addition to the router certificate, what other certificate component must typically be provided in the route configuration?

A.The destination CA certificate to validate the backend pod's TLS certificate

B.A base64 encoded kubeconfig file for the ingress operator

C.An identity provider public key for JSON Web Token validation

D.A client certificate for mutual TLS authentication against the OAuth server

AnswerA

Re-encrypt termination means the router decrypts and then re-encrypts traffic to the backend, so it must trust the pod's serving certificate. Supplying the destination CA certificate lets the router validate that backend certificate, which passthrough and edge termination do not require.

Why this answer

In re-encrypt TLS termination, the router decrypts incoming traffic and then re-encrypts it before forwarding to the backend pod. To validate the backend pod's certificate during this second TLS handshake, the router must trust the CA that signed the pod's certificate. Therefore, the destination CA certificate is required in the Route configuration, in addition to the router's own certificate.

Exam trap

EX280 often tests the misconception that re-encrypt termination only requires the router certificate, confusing it with edge termination where the backend is unencrypted.

How to eliminate wrong answers

Option B is wrong because a kubeconfig file is used for cluster authentication and authorization, not for TLS termination on a Route. Option C is wrong because an identity provider public key is used for validating JSON Web Tokens in OAuth/OIDC flows, which is unrelated to re-encrypt TLS. Option D is wrong because a client certificate for mutual TLS against an OAuth server is used for API authentication, not for securing traffic between the router and backend pods.

Full explanation →

295

Multi-Selecthard

Which THREE of the following fields are required when defining a custom Role or ClusterRole resource YAML? (Choose THREE)

Select 3 answers

A.namespace

B.apiVersion

C.subjects

D.rules

E.kind

AnswersB, D, E

Every Role or ClusterRole manifest requires apiVersion to select the correct RBAC API group and version, here rbac.authorization.k8s.io/v1. Without it, the API server cannot decode the resource, so the field is mandatory alongside kind and metadata.

Why this answer

Option B (apiVersion) is required because every Kubernetes manifest must declare the API group/version, and for RBAC roles this is rbac.authorization.k8s.io/v1. Option E (kind) is required because the manifest must specify whether the object is a Role or a ClusterRole. Option D (rules) is required because rules define the actual permissions (apiGroups, resources, verbs) that the Role or ClusterRole grants.

Option A (namespace) is not required: a Role's namespace is set in metadata.namespace (or defaults to the current context), and a ClusterRole is cluster-scoped and has no namespace at all. Option C (subjects) is not required for a Role or ClusterRole; subjects belong to a RoleBinding or ClusterRoleBinding, which associates the role with users, groups, or service accounts.

Exam trap

EX280 often tests whether candidates confuse Role/ClusterRole fields with RoleBinding/ClusterRoleBinding fields — the trap is including 'subjects' in a Role definition or expecting a 'namespace' field in the spec.

Full explanation →

296

MCQmedium

An OpenShift administrator needs to allow users to expand the storage capacity of existing PersistentVolumeClaims without restarting their applications. Which action must be taken first to enable this capability?

A.Restart the csi-provisioner controller deployment in the openshift-cluster-storage-operator namespace.

B.Edit the StorageClass to set allowVolumeExpansion: true.

C.Add the expansion-enabled annotation directly to each active Pod object.

D.Convert all existing static PersistentVolumes into dynamically provisioned volumes.

AnswerB

Setting allowVolumeExpansion: true on the StorageClass is the prerequisite that permits CSI resizing of bound PVCs. Without it, the API rejects expansion requests outright, so applications keep running while the PVC spec's resources.requests.storage is increased.

Why this answer

Online volume expansion in Kubernetes/OpenShift is gated by the StorageClass field allowVolumeExpansion. Until that field is set to true on the StorageClass backing the PVC, the API server will reject any attempt to increase the PVC's requested storage, so it must be enabled first.

Exam trap

EX280 often tests whether candidates know that allowVolumeExpansion is a StorageClass-level setting, not a PVC annotation or a controller restart, and that it must be enabled before any resize attempt.

How to eliminate wrong answers

Option A is wrong because restarting the csi-provisioner does not change the StorageClass policy — expansion remains blocked by the missing allowVolumeExpansion flag. Option C is wrong because Pods have no expansion-enabled annotation; expansion is a PVC/StorageClass concern, not a Pod annotation. Option D is wrong because converting static PVs to dynamic provisioning is unrelated to expansion capability and is not a prerequisite — expansion works on both statically and dynamically provisioned volumes as long as the driver and StorageClass allow it.

Full explanation →

297

MCQmedium

A cluster administrator needs to inspect the current bindings and capacities of all PersistentVolumes across the entire OpenShift cluster. Which CLI command should be used?

A.oc get pvc --all-namespaces

B.oc get pv

C.oc describe storage

D.oc get volume

AnswerB

oc get pv lists PersistentVolume objects cluster-wide, showing each volume's capacity, access modes, reclaim policy and current binding status. It satisfies the requirement to inspect bindings and capacities across the entire cluster without specifying a namespace, unlike project-scoped alternatives.

Why this answer

PersistentVolumes (PVs) are cluster-scoped resources in OpenShift/Kubernetes, so 'oc get pv' lists every PV in the cluster along with its capacity, access modes, reclaim policy, status, and claim binding. Because PVs are not namespaced, no --all-namespaces flag is needed or accepted. This single command gives the administrator the complete cluster-wide view of bindings and capacities requested.

Exam trap

EX280 often tests the distinction between cluster-scoped PVs and namespaced PVCs, tricking candidates into adding --all-namespaces to a PV query or confusing the two resource types.

How to eliminate wrong answers

Option A is wrong because 'oc get pvc --all-namespaces' lists PersistentVolumeClaims, which are namespaced requests for storage, not the PV objects themselves, so it does not show cluster-wide PV capacity or binding state. Option C is wrong because 'storage' is not a valid OpenShift resource type — there is no 'oc describe storage' command; storage is managed via PV, PVC, and StorageClass resources. Option D is wrong because 'volume' is not a top-level OpenShift resource kind; volumes exist only as pod spec fields or as PV/PVC objects, so 'oc get volume' returns an error.

Full explanation →

298

MCQmedium

During an S2I build, an administrator needs to pass sensitive build arguments, such as subscription keys, without hardcoding them into the BuildConfig or exposing them in the final image history. How should this be handled?

A.Storing them in an ImageStream annotation

B.Using build secrets mounted via the source secret or build strategy configuration

C.Defining them as plain environment variables in the BuildConfig spec

D.Injecting them via the Route host header

AnswerB

Build secrets can be securely mounted into the builder pod during the build process without being baked into the final image layers.

Why this answer

Build secrets in OpenShift are designed specifically for passing sensitive data like subscription keys, tokens, or credentials into an S2I build without embedding them in the BuildConfig or leaving them in the final image layers. When configured via the source secret (e.g., `sourceSecret` in the BuildConfig) or through the build strategy's `secrets` field, the secret is mounted into the build pod's filesystem at a temporary location and is not committed to the resulting image. This ensures the sensitive data is available only during the build process and is discarded afterward, satisfying both security and compliance requirements.

Exam trap

EX280 often tests the misconception that environment variables in a BuildConfig are secure because they are not visible in the OpenShift web console; in reality, they are stored in plaintext and can leak into image layers, whereas build secrets are the only supported method for ephemeral, non-persistent sensitive data injection.

How to eliminate wrong answers

Option A is wrong because ImageStream annotations are metadata fields used for descriptive or operational purposes (e.g., tags, descriptions) and are not designed to inject runtime or build-time secrets; they are visible to anyone with read access to the ImageStream and would expose the sensitive data. Option C is wrong because plain environment variables in the BuildConfig spec are stored in plaintext in the BuildConfig object and are also baked into the image history if used during the build, directly violating the requirement to avoid hardcoding and exposure. Option D is wrong because Route host headers are used for HTTP routing and TLS termination, not for passing build arguments; they have no mechanism to inject secrets into an S2I build and would be a severe security anti-pattern.

Full explanation →

299

MCQhard

A developer needs to expose a service via a route with re-encryption. What is required in the Route configuration?

A.Enable 'insecureEdgeTerminationPolicy: Allow'

B.Configure a ServiceMesh resource

C.Set 'termination: reencrypt' in the spec.tls section

D.Set 'termination: edge' and add a proxy

AnswerC

Setting termination to reencrypt makes the router decrypt incoming traffic with the edge certificate, then re-encrypt it with the pod's certificate before forwarding. This satisfies the re-encryption requirement, unlike passthrough or edge termination, which do not re-encrypt to the backend.

Why this answer

A re-encrypt route terminates TLS at the router and then re-encrypts traffic to the backend pod using a separate certificate. This is configured by setting termination: reencrypt in the route's spec.tls section, along with a destination CA certificate so the router can validate the backend's certificate. The reencrypt termination type is the defining configuration element.

Exam trap

EX280 often tests the confusion between edge and reencrypt termination, and candidates incorrectly select edge plus a proxy instead of setting termination: reencrypt.

How to eliminate wrong answers

Option A is wrong because insecureEdgeTerminationPolicy: Allow controls whether plain HTTP is allowed alongside HTTPS at the edge; it does not configure re-encryption. Option B is wrong because ServiceMesh is a separate Istio-based feature for mTLS and traffic management, not the mechanism for a standard OpenShift Route with re-encrypt termination. Option D is wrong because termination: edge terminates TLS at the router and forwards plain HTTP to the backend — it does not re-encrypt, and adding a proxy is not how re-encryption is achieved.

Full explanation →

300

Multi-Selecthard

Which THREE factors influence whether a pod requesting a storage volume can be successfully scheduled to a specific worker node when using topology-aware storage?

Select 3 answers

A.The cluster OAuth token expiration time

B.Volume accessibility constraints reported by the CSI driver

C.The number of container image layers in the pod spec

D.The volumeBindingMode set to WaitForFirstConsumer on the StorageClass

E.Node topology labels (such as failure-domain.beta.kubernetes.io/zone)

AnswersB, D, E

The CSI driver publishes topology keys describing which nodes can reach a given volume. The scheduler filters out nodes failing those accessibility constraints, so a pod cannot land on a worker that cannot attach the requested storage.

Why this answer

Option B is correct because topology-aware scheduling depends on the accessibility constraints the CSI driver reports through CSI topology keys (for example, via the CSINode object and CSIStorageCapacity), which tell the scheduler which nodes can actually reach the volume. Option D is correct because a StorageClass with volumeBindingMode: WaitForFirstConsumer delays PersistentVolume binding until the pod is scheduled, allowing the scheduler to co-locate the pod with the volume's topology instead of binding prematurely. Option E is correct because node topology labels such as topology.kubernetes.io/zone (or the older failure-domain.beta.kubernetes.io/zone) are the actual topology domains the scheduler matches against the volume's node affinity requirements.

Option A is not relevant because OAuth token expiration affects API authentication, not volume topology or scheduling decisions. Option C is not relevant because the number of image layers affects image pull time and storage, not whether a topology-constrained volume can be scheduled to a node.

Exam trap

EX280 often tests the misconception that storage scheduling is purely about capacity — candidates overlook that volumeBindingMode and CSI topology constraints are what actually gate node selection.

Full explanation →

Red Hat Certified OpenShift Administrator (EX280, OpenShift Container Platform 4.14+) (EX280) (EX280) — Questions 226–300