Red Hat Certified OpenShift Administrator (EX280, OpenShift Container Platform 4.14+) (EX280) EX280 Questions 301–375 | Page 5/6

301

MCQeasy

A developer wants to inspect the generated Kubernetes manifests from a Helm chart without actually installing the chart into the OpenShift cluster. Which Helm command should be used?

A.helm dry-run my-release my-chart

B.helm template my-release my-chart

C.helm show chart my-chart

D.helm inspect values my-chart

AnswerB

`helm template my-release my-chart` renders the chart's templates locally and prints the resulting Kubernetes manifests to stdout, contacting no cluster and creating no resources. This satisfies the stem's constraint of inspecting generated manifests without installing the chart, unlike `helm install`, which applies them to the cluster.

Why this answer

'helm template' renders a chart's templates locally and prints the resulting Kubernetes manifests to stdout without contacting the cluster or installing anything. It is the canonical command for inspecting what a chart would produce, and it accepts a release name and chart reference. This lets developers review, diff, or pipe the output before committing to an install.

Exam trap

EX280 often tests whether candidates confuse 'helm template' (renders manifests locally) with 'helm show' subcommands (display chart metadata or values) or with the --dry-run flag that must accompany install/upgrade.

How to eliminate wrong answers

Option A is wrong because 'helm dry-run' is not a standalone command — dry-run is a flag (--dry-run) used with 'helm install' or 'helm upgrade', not a subcommand. Option C is wrong because 'helm show chart' displays the chart's metadata (Chart.yaml contents) such as version and description, not the rendered manifests. Option D is wrong because 'helm inspect values' (now 'helm show values') prints the chart's default values.yaml, not the generated Kubernetes resources.

Full explanation →

302

MCQmedium

An administrator wants to check why a specific MachineConfigPool is taking a long time to complete an update. Which status condition on the MachineConfigPool indicates that nodes are currently being updated?

A.Updating=True

B.RollingOut=Running

C.Reconciling=Pending

D.Progressing=Active

AnswerA

Updating=True is the MachineConfigPool status condition that signals the pool's nodes are actively being reconfigured. It directly answers the stem's question about which condition shows an update in progress, distinguishing it from Updated, Degraded or RenderFailed.

Why this answer

The MachineConfigPool (MCP) status includes a condition of type 'Updating'. When this condition's status is 'True', it explicitly indicates that the pool is actively applying configuration changes to its nodes. This is the standard condition used by the Machine Config Operator (MCO) to signal that an update is in progress.

Therefore, option A is correct.

Exam trap

EX280 often tests the specific condition names and statuses in OpenShift resource statuses, and candidates may confuse generic Kubernetes conditions like 'Progressing' with the actual MCP conditions, leading them to select plausible but incorrect options.

How to eliminate wrong answers

Option B is wrong because 'RollingOut=Running' is not a valid condition type or status in the MachineConfigPool API; the MCP uses conditions like 'Updated', 'Updating', 'Degraded', and 'RenderDegraded'. Option C is wrong because 'Reconciling=Pending' is not a recognized condition; the MCP does not have a 'Reconciling' condition. Option D is wrong because 'Progressing=Active' is not a condition type used by the MCP; while 'Progressing' might appear in some Kubernetes resources, it is not part of the MCP status.

Full explanation →

303

Multi-Selecthard

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

Select 3 answers

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

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

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

D.oc adm upgrade cancel

E.oc describe machineconfigpool <pool-name>

AnswersA, C, E

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

Why this answer

Option E is correct because `oc describe machineconfigpool <pool-name>` shows the pool's status conditions, including Degraded, Updated, Updating, and the reason/message fields that identify why the pool is degraded. Option C is correct because listing MachineConfigs with the label `machineconfiguration.openshift.io/role=<role>` shows the rendered and role-specific configs applied to that pool, helping spot a bad or mismatched MachineConfig. Option A is correct because `oc logs -n openshift-machine-config-operator daemonset/machine-config-daemon` retrieves the Machine Config Daemon logs, where the actual node-level failure (e.g., failed systemd unit, file write, or reboot issue) is recorded.

Option B is wrong because scaling the cluster-version-operator deployment does not diagnose a degraded MachineConfigPool and is not a supported troubleshooting step. Option D is wrong because `oc adm upgrade cancel` only cancels an in-progress cluster upgrade and does not reveal the root cause of the MachineConfigPool degradation.

Exam trap

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

Full explanation →

304

Multi-Selecthard

Which THREE parameters or fields are valid when configuring a StorageClass object in OpenShift 4.14+?

Select 3 answers

A.containerRuntime

B.provisioner

C.volumeBindingMode

D.nodeSelector

E.reclaimPolicy

AnswersB, C, E

The provisioner field is mandatory in a StorageClass, naming the CSI driver plugin (for example ebs.csi.aws.com) that dynamically provisions PersistentVolumes. Without it, OpenShift cannot determine which storage backend to call, so the object is rejected.

Why this answer

Option B (provisioner) is correct because every StorageClass must specify the provisioner field, which identifies the volume plugin (e.g., kubernetes.io/aws-ebs, ebs.csi.aws.com, or kubernetes.io/no-provisioner) used to dynamically provision PersistentVolumes. Option C (volumeBindingMode) is correct because it is a valid StorageClass field that controls when volume binding and dynamic provisioning occur, with supported values Immediate and WaitForFirstConsumer. Option E (reclaimPolicy) is correct because StorageClass supports the reclaimPolicy field to define the default PersistentVolume reclaim behavior for dynamically provisioned volumes, with valid values Delete and Retain.

Option A (containerRuntime) is not a StorageClass parameter; it relates to container runtime configuration (e.g., CRI-O) and is not part of the storage.k8s.io/v1 StorageClass schema. Option D (nodeSelector) is not a StorageClass field; node selection for storage is handled via allowedTopologies or in PersistentVolume nodeAffinity, not a nodeSelector key on StorageClass.

Exam trap

EX280 often tests whether candidates confuse StorageClass fields with Pod scheduling fields (nodeSelector) or node-level runtime settings (containerRuntime), which are not part of the StorageClass API.

Full explanation →

305

MCQmedium

A platform administrator is auditing RBAC in the 'payments' namespace. They notice that the group 'contractors' can list and get secrets in that namespace, but the administrators never created a RoleBinding or ClusterRoleBinding granting those permissions. Which mechanism most likely granted this access?

A.The ServiceAccount of the kube-controller-manager reconciles missing RoleBindings by copying them from the 'default' namespace.

B.A ClusterRoleBinding to a default cluster role such as 'view' or 'edit' grants the group access across all namespaces, including 'payments'.

C.A RoleBinding was automatically created by the OpenShift OAuth server when the group first authenticated.

D.The 'system:authenticated' group is implicitly bound to 'cluster-admin' in every namespace for convenience.

AnswerB

ClusterRoleBindings apply cluster-wide, so binding the group 'contractors' to a default aggregated role like 'view' or 'edit' grants its permissions inside every project, including 'payments'. This explains how the group can list and get secrets without any namespace-scoped RoleBinding existing in that namespace.

Why this answer

Because ClusterRoleBindings are cluster-scoped, binding a group to an aggregated role such as 'view' or 'edit' gives that group the role's rules in every namespace. Auditing only namespace-scoped RoleBindings will miss this, which is why the group can read secrets in 'payments' without any local binding. Checking cluster-scoped bindings is essential during RBAC audits.

Exam trap

The trap here is assuming that missing RoleBindings in a namespace mean no access exists, while forgetting that ClusterRoleBindings silently grant the same permissions cluster-wide.

Full explanation →

306

MCQmedium

A developer reports that a Service in the project `webapp` is not exposing the expected endpoints, even though the Deployment shows all replicas Running. The administrator inspects the Service and sees the selector is `app: web-frontend`. Which command should the administrator run to verify whether the Pods actually carry the labels the Service selector expects?

A.oc get endpoints webapp -n webapp

B.oc get networkpolicy -n webapp

C.oc describe deployment webapp -n webapp

D.oc get pods -n webapp --show-labels

AnswerD

This command lists every Pod in the `webapp` namespace together with its full label set, letting the administrator compare the Pod labels against the Service selector `app: web-frontend`. If the labels differ, the Service has no matching endpoints, which explains the empty endpoint list. It is the direct, namespace-scoped way to confirm label alignment.

Why this answer

A Service selects backend Pods purely by label matching against its selector. When a Deployment is healthy but the Service has no endpoints, the most common cause is a mismatch between the Service selector and the labels applied to the Pod template. Listing Pods with their labels exposes that mismatch directly, allowing the administrator to correct either the selector or the Pod labels.

Exam trap

The trap here is assuming a healthy Deployment guarantees Service endpoints, when endpoint membership depends entirely on label selector agreement between the Service and the Pods.

Full explanation →

307

Multi-Selecteasy

Which THREE network-related objects are namespaced in OpenShift? (Choose THREE)

Select 3 answers

A.ClusterNetwork

B.IngressController

C.NetworkPolicy

D.Service

E.Route

AnswersC, D, E

NetworkPolicy objects are namespaced resources, scoped to a single project and applied only to pods within that namespace. This satisfies the question's requirement for namespaced network objects, unlike cluster-scoped resources such as nodes or ClusterNetwork.

Why this answer

NetworkPolicy (C) is namespaced because it is a Kubernetes resource scoped to a namespace, where its podSelector and ingress/egress rules apply only to pods within that namespace. Service (D) is namespaced since a Service is a namespaced Kubernetes object that provides a stable virtual IP and DNS name for pods in the same namespace. Route (E) is namespaced because OpenShift Routes are namespace-scoped resources that expose a Service from within that namespace to external clients.

ClusterNetwork (A) is cluster-scoped, as it defines the overall pod network CIDR configuration for the entire cluster. IngressController (B) is also cluster-scoped, since it configures the ingress controller operator for the whole OpenShift cluster rather than a single namespace.

Exam trap

EX280 often tests whether candidates can distinguish namespaced from cluster-scoped resources, so the trap is assuming that all network-related objects are namespaced and selecting ClusterNetwork or IngressController, which are actually cluster-scoped.

Full explanation →

308

Multi-Selectmedium

Which TWO of the following are valid deployment strategies supported by OpenShift?

Select 2 answers

A.Parallel

B.Sequential

C.Recreate

D.Rolling

E.Canary

AnswersC, D

Recreate terminates all existing pods before starting new ones, producing a brief outage but guaranteeing no version overlap. OpenShift supports it natively as a DeploymentConfig strategy, making it valid where simultaneous old and new pod versions cannot coexist.

Why this answer

Options D (Rolling) and C (Recreate) are the two deployment strategies natively supported by OpenShift's DeploymentConfig/Deployment resources. Rolling performs a gradual, zero-downtime replacement of pods using a rolling update with configurable maxUnavailable and maxSurge parameters, while Recreate terminates all existing pods before starting new ones, causing a brief outage but avoiding version overlap. Both are explicitly defined strategy types in OpenShift's deployment configuration API.

Options A (Parallel), B (Sequential), and E (Canary) are not built-in OpenShift deployment strategies; canary-style rollouts can be approximated via custom techniques or routes but are not a native strategy type.

Exam trap

EX280 often tests whether candidates confuse deployment strategies with release methodologies (canary, blue-green), so they incorrectly select Canary as a built-in strategy when it is only an external pattern.

Full explanation →

309

MCQeasy

Which component in OpenShift 4.14 coordinates the creation of certificates for cluster components and worker nodes?

A.Machine API Operator

B.Kubernetes CSR controller / OpenShift PKI operators

C.Cluster Autoscaler

D.Operator Lifecycle Manager (OLM)

AnswerB

The Kubernetes CSR controller and OpenShift PKI operators handle certificate signing requests, issuing and renewing certificates for cluster components and worker nodes. This satisfies the stem's requirement for the coordinating component, since the CSR controller approves and signs CSRs while the PKI operators manage the certificate authorities and rotation lifecycle.

Why this answer

In OpenShift 4.x, the Kubernetes CSR (Certificate Signing Request) controller works in tandem with OpenShift PKI operators to automate certificate issuance and rotation for cluster components and worker nodes. The CSR controller approves and signs CSRs submitted by kubelet and other components, while PKI operators manage the lifecycle of CA certificates and ensure trust distribution. This integrated mechanism eliminates manual certificate management, which was common in OpenShift 3.

Exam trap

EX280 often tests the distinction between operators responsible for infrastructure (Machine API, Cluster Autoscaler) and those handling security/PKI, causing candidates to confuse certificate management with node provisioning or operator lifecycle.

How to eliminate wrong answers

Option A is wrong because the Machine API Operator manages the lifecycle of machines (nodes) in the cluster, including provisioning and scaling, but it does not handle certificate creation or signing. Option C is wrong because the Cluster Autoscaler adjusts the number of nodes in a cluster based on workload demands; it has no role in certificate management. Option D is wrong because Operator Lifecycle Manager (OLM) manages the installation, upgrade, and lifecycle of Operators themselves, not the certificates for cluster components or nodes.

Full explanation →

310

MCQeasy

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

A.oc get routes

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

C.oc adm diagnostics

D.oc describe pod <pod-name>

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

311

MCQhard

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

A./run/log/journal

B./var/lib/kubelet/pods

C./var/crash

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

312

MCQmedium

When creating a custom SCC, what is the best practice for assigning it to users?

A.Bind the SCC to the 'cluster-admin' user

B.Bind the SCC to a specific service account in a specific namespace

C.Bind the SCC to the 'system:authenticated' group

D.Assign the SCC to the namespace object directly

AnswerB

Binding an SCC to a specific service account within a namespace follows least privilege, granting only that workload the required permissions. Cluster-wide or user-based grants would over-privilege unrelated pods, so scoping to the service account is the recommended practise.

Why this answer

Binding a custom SCC to a specific service account in a specific namespace follows the principle of least privilege and is the OpenShift best practice. SCCs are applied to service accounts (or users/groups) via RBAC role bindings, and scoping to a specific service account in a specific namespace ensures the elevated permissions are granted only where needed, minimizing the blast radius of a compromised pod.

Exam trap

EX280 often tests the misconception that SCCs can be assigned to namespaces or broad groups, when in fact best practice requires binding SCCs to specific service accounts via RBAC to enforce least privilege.

How to eliminate wrong answers

Option A is wrong because binding an SCC to the cluster-admin user grants cluster-wide elevated permissions to a human user, violating least privilege and creating a significant security risk — SCCs should be bound to service accounts that pods run as, not to administrative users. Option C is wrong because binding to the system:authenticated group applies the SCC to every authenticated user in the cluster, which is an extremely broad grant that effectively removes the security boundary the SCC is meant to enforce. Option D is wrong because SCCs cannot be assigned directly to a namespace object — SCCs are bound to subjects (users, groups, or service accounts) through RBAC, and the namespace is the scope of the service account, not the target of the SCC binding.

Full explanation →

313

Multi-Selectmedium

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

Select 3 answers

A.oc get subscription <operator-name>

B.oc get installplan

C.oc get routes

D.oc get pv

E.oc get csv

AnswersA, B, E

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

Why this answer

Option A, `oc get subscription <operator-name>`, is correct because the Subscription is the OLM resource that declares which operator and channel to install and records the resolution state, so its status reveals whether the operator was resolved and any resolution failures. Option B, `oc get installplan`, is correct because the InstallPlan is generated by OLM to enumerate the CSVs and approval requirements needed to install or upgrade an operator, and its status shows whether the plan is pending approval or has failed to execute. Option E, `oc get csv`, is correct because the ClusterServiceVersion represents the actual running operator deployment and its status/phase (e.g., Failed, Pending) exposes installation errors such as unmet dependencies or failed deployments.

Option C, `oc get routes`, is not relevant because Routes only expose services externally and are not part of the OLM installation pipeline. Option D, `oc get pv`, is not relevant because PersistentVolumes relate to storage provisioning and are not OLM installation resources unless a specific storage issue is already suspected.

Exam trap

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

Full explanation →

314

MCQhard

An application deployed in a secured namespace requires access to the Kubernetes API to query pod statuses. The administrator wants to follow the principle of least privilege. How should the administrator configure the ServiceAccount and RBAC?

A.Create a dedicated ServiceAccount, a Role granting get and list on pods, and a RoleBinding linking them in the namespace

B.Bind the cluster-admin ClusterRole to the default ServiceAccount in the namespace using a ClusterRoleBinding

C.Annotate the default ServiceAccount with rbac.authorization.k8s.io/authtype: reader

D.Grant the system:openshift:scc:restricted ClusterRole to the ServiceAccount using a RoleBinding

AnswerA

A dedicated ServiceAccount with a namespaced Role granting only get and list on pods, bound via RoleBinding, delivers exactly the API permissions required while honouring least privilege. ClusterRole or broader verbs would exceed the pod-status querying need.

Why this answer

Least privilege means granting only the permissions the application actually needs, scoped to the namespace where it runs. A dedicated ServiceAccount isolates the identity, a namespaced Role with get/list on pods grants exactly the required verbs, and a RoleBinding ties them together within the namespace. This avoids cluster-wide permissions and avoids reusing the default ServiceAccount.

Exam trap

EX280 often tests the misconception that the default ServiceAccount is 'safe' or that SCC roles grant API permissions — candidates must distinguish authentication/authorization (RBAC) from pod security admission (SCC).

How to eliminate wrong answers

Option B is wrong because binding cluster-admin via ClusterRoleBinding grants full cluster-wide control to the default ServiceAccount — the exact opposite of least privilege, and it also pollutes the shared default SA. Option C is wrong because there is no such annotation (rbac.authorization.k8s.io/authtype) — RBAC is granted through Roles/ClusterRoles and Bindings, never through annotations. Option D is wrong because system:openshift:scc:restricted is a SecurityContextConstraints role controlling pod security admission, not API access to pods; it does not grant get/list on pods.

Full explanation →

315

MCQhard

An administrator is configuring topology-aware storage provisioning. A StorageClass uses volumeBindingMode: WaitForFirstConsumer. When is the PersistentVolume actually created?

A.When the scheduler places the pod referencing the PVC onto a specific worker node.

B.When the PVC object is successfully created in the namespace.

C.When the user executes 'oc adm pv create'.

D.When the CSI driver operator starts up during cluster bootstrap.

AnswerA

With WaitForFirstConsumer, the scheduler delays binding until a pod using the PVC is placed, then provisions the PersistentVolume in the topology zone of that chosen worker node. This satisfies the topology-aware constraint, ensuring storage lands where the pod actually runs rather than being pre-bound to an arbitrary zone.

Why this answer

With volumeBindingMode: WaitForFirstConsumer, the PV is not provisioned when the PVC is created. Instead, the scheduler delays binding until a pod using the PVC is scheduled, so it can pick a node and provision the volume in the correct topology zone. The PV is created at that point, ensuring the volume lands in the same zone as the pod.

Exam trap

EX280 often tests whether candidates assume PVC creation immediately triggers PV provisioning, forgetting that WaitForFirstConsumer deliberately defers it until a pod is scheduled.

How to eliminate wrong answers

Option B is wrong because with WaitForFirstConsumer, PVC creation alone does not trigger provisioning — the PVC stays Pending until a consumer pod appears. Option C is wrong because 'oc adm pv create' is not how dynamic provisioning works; PVs are created by the CSI provisioner, not manually. Option D is wrong because CSI driver startup during bootstrap has nothing to do with when a specific PV is provisioned for a given PVC.

Full explanation →

316

MCQhard

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

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

B.oc adm inspect router

C.oc get validatingwebhookconfigurations

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

317

Multi-Selectmedium

Which THREE conditions must be met for a NetworkPolicy to successfully allow traffic from another pod? (Choose THREE)

Select 3 answers

A.The cluster must have exactly three worker nodes.

B.The physical switch port on the top-of-rack switch must be configured in trunk mode.

C.If an ingress policy is present, the connection must be explicitly permitted by at least one rule.

D.The target port and protocol specified in the NetworkPolicy must match the traffic.

E.The source pod must match the podSelector or namespaceSelector specified in the ingress rule.

AnswersC, D, E

Kubernetes NetworkPolicy is default-deny once any policy selects the target pod. If an ingress policy exists, every inbound connection must be explicitly permitted by at least one ingress rule; unmatched traffic is dropped regardless of other conditions.

Why this answer

Option C is correct because Kubernetes NetworkPolicy is default-deny for ingress once any policy selects the pod: if an ingress policy exists, the connection must be explicitly allowed by at least one ingress rule, otherwise the traffic is dropped. Option D is correct because the policy's ports and protocol fields (e.g., port: 6379, protocol: TCP) must match the actual destination port and L4 protocol of the traffic for the rule to permit it. Option E is correct because the ingress rule's from selectors — podSelector and/or namespaceSelector — must match the source pod's labels and namespace for the connection to be allowed.

Option A is wrong because NetworkPolicy enforcement is independent of the number of worker nodes; it depends on a CNI plugin that implements NetworkPolicy (e.g., Calico, Cilium), not cluster size. Option B is wrong because NetworkPolicy operates at the pod/CNI layer inside the cluster and does not require any top-of-rack switch port trunk configuration.

Exam trap

The trap is overthinking the infrastructure layer — candidates may pick physical switch or node-count options, but NetworkPolicy is purely a logical Kubernetes construct with three specific matching conditions.

Full explanation →

318

MCQmedium

An administrator needs to secure a Route with edge termination using a custom TLS certificate and private key. Which section of the Route manifest must contain these certificate details?

A.spec.endpoint.tls with base64 encoded string data

B.metadata.annotations containing openshift.io/tls-cert and openshift.io/tls-key

C.spec.tls.certificate, spec.tls.key, and spec.tls.caCertificate

D.status.ingress.tls for automatic cert-manager synchronization

AnswerC

Edge termination places the certificate and private key on the router, so they belong in the Route's spec.tls fields: certificate, key and caCertificate. It satisfies the custom TLS certificate requirement, unlike re-encrypt or passthrough termination, which handle certificates differently.

Why this answer

For edge termination, the Route's spec.tls section holds the certificate, key, and optional CA certificate as plain string fields (not base64). The router terminates TLS at the edge using these values, then forwards plain HTTP to the pods. The correct fields are spec.tls.certificate, spec.tls.key, and spec.tls.caCertificate.

Exam trap

EX280 often tests whether candidates mistakenly believe Route TLS fields are base64-encoded or stored in annotations, when they are actually plain string fields under spec.tls.

How to eliminate wrong answers

Option A is wrong because there is no spec.endpoint.tls section in a Route, and Route TLS fields are plain strings, not base64-encoded. Option B is wrong because TLS material is not supplied via annotations like openshift.io/tls-cert; those annotations do not exist for Route TLS. Option D is wrong because status.ingress.tls is a read-only status field populated by the router, not a place to configure certificates, and cert-manager does not sync into it.

Full explanation →

319

MCQeasy

A developer has built a container image and pushed it to an external registry. They now want to deploy this image as a new application in an OpenShift 4.14 project. Which oc command should they use to create a Deployment that runs the image and exposes it with a Service?

A.oc apply -f deployment.yaml --image=myregistry.com/myimage:latest

B.oc new-app --image-stream=myimage:latest

C.oc create deployment myapp --image=myregistry.com/myimage:latest

D.oc new-app --docker-image=myregistry.com/myimage:latest

AnswerD

The oc new-app command with --docker-image is used to create a new application from an external container image. It creates a Deployment (or DeploymentConfig) and a Service, and optionally a Route. This is the correct way to deploy an image from an external registry.

Why this answer

The oc new-app command is designed to quickly create applications from various sources, including external container images. Using the --docker-image flag allows specifying an image from an external registry, and new-app automatically creates the necessary Deployment and Service resources, and may create a Route if applicable.

Exam trap

The trap here is assuming that oc new-app requires an ImageStream, but it can directly use an external image with --docker-image.

Full explanation →

320

MCQeasy

Which resource represents the physical or cloud storage provisioned in the cluster by an administrator, independent of any user namespace claims?

A.StorageClass

B.PersistentVolumeClaim

C.PodVolume

D.PersistentVolume

AnswerD

A PersistentVolume is cluster-scoped storage provisioned by an administrator, existing independently of namespace-bound claims. This directly satisfies the stem's requirement: it represents the actual physical or cloud storage resource itself, not a user's request. PersistentVolumeClaims, by contrast, are namespaced and consume PersistentVolumes rather than defining the underlying provisioned storage.

Why this answer

A PersistentVolume (PV) is the cluster-scoped resource that represents actual storage provisioned by an administrator — an NFS export, EBS volume, or Ceph RBD image — and exists independently of any namespace. It is bound to a PersistentVolumeClaim (PVC) when a user requests storage, but the PV itself is not owned by or scoped to a user namespace.

Exam trap

The trap here is confusing the PV (admin-provisioned, cluster-scoped, the actual storage) with the PVC (user-requested, namespaced, the claim), since both contain 'Volume' and 'Persistent' in their names.

How to eliminate wrong answers

Option A is wrong because StorageClass is a template that describes how to dynamically provision PVs (provisioner, parameters, reclaim policy) — it does not represent actual provisioned storage. Option B is wrong because PersistentVolumeClaim is a namespaced user request for storage that gets bound to a PV; it is the consumer, not the provisioned resource. Option C is wrong because PodVolume is not a standalone Kubernetes API object — volumes are declared inline within a Pod spec (e.g., volumes: under spec), not as a separate cluster resource.

Full explanation →

321

MCQhard

How do you define a health check that verifies if your application is ready to start receiving traffic?

A.ReadinessProbe

B.StartupProbe

C.LivenessProbe

D.HealthProbe

AnswerA

A ReadinessProbe determines whether the container is prepared to accept traffic; failing it removes the pod from Service endpoints without restarting it. This matches the stem's requirement of verifying readiness to start receiving traffic, unlike a LivenessProbe, which restarts unhealthy containers.

Why this answer

A ReadinessProbe determines whether a container is ready to accept traffic. If the probe fails, the pod is removed from the Service's endpoints, so no traffic is routed to it until the probe succeeds. This directly matches the requirement of verifying readiness to receive traffic.

Exam trap

The trap is confusing readiness with liveness — candidates pick LivenessProbe because it sounds like a health check, but only ReadinessProbe controls whether traffic is sent to the pod.

How to eliminate wrong answers

Option B is wrong because a StartupProbe only checks whether the application has started; once it succeeds, it is disabled and does not gate ongoing traffic. Option C is wrong because a LivenessProbe detects whether a container is still running and triggers a restart on failure — it does not control traffic routing. Option D is wrong because 'HealthProbe' is not a Kubernetes probe type; the three valid types are liveness, readiness, and startup.

Full explanation →

322

MCQmedium

An administrator needs to modify the timeout values for the default OpenShift Ingress Controller (Router). Where should this change be applied?

A.Edit the proxy resource named 'cluster'.

B.Edit the ingresscontroller instance named 'default' in the 'openshift-ingress-operator' namespace.

C.Edit the endpoints resource in the 'openshift-ingress' namespace.

D.Modify the kube-apiserver configmap.

AnswerB

Editing the ingresscontroller custom resource named 'default' in the openshift-ingress-operator namespace is the supported method: the Ingress Operator reconciles this resource and propagates the timeout settings to the managed router deployment. Directly patching router pods or the router deployment would be overwritten, so the operator-managed CR satisfies the persistence constraint.

Why this answer

The OpenShift Ingress Controller (Router) is managed by the Ingress Operator. To change timeout values, you must modify the IngressController custom resource named 'default' in the 'openshift-ingress-operator' namespace. This is the supported method because the Operator reconciles the router deployment and its configuration based on this resource.

Directly editing the router's configmap or deployment is not persistent and will be overwritten by the Operator.

Exam trap

EX280 often tests the misconception that directly editing the router's configmap or deployment is the way to change router settings, but the correct approach is to modify the IngressController custom resource managed by the Operator.

How to eliminate wrong answers

Option A is wrong because the 'cluster' proxy resource is used to configure cluster-wide proxy settings for OpenShift components, not Ingress Controller timeouts. Option C is wrong because the endpoints resource in 'openshift-ingress' namespace lists the IP addresses of the router pods and does not control router configuration. Option D is wrong because the kube-apiserver configmap is used to configure the Kubernetes API server, not the Ingress Controller; modifying it would have no effect on router timeouts and could break the API server.

Full explanation →

323

Multi-Selectmedium

Which THREE of the following are valid parameters that can be specified in a LimitRange object specification? (Choose THREE)

Select 3 answers

A.max

B.replicas

C.defaultRequest

D.min

E.clusterWideAccess

AnswersA, C, D

`max` caps the maximum compute resources a container or pod may request or consume within the namespace, enforced by the LimitRange admission controller at creation time. It satisfies the stem's requirement for a valid LimitRange spec parameter, sitting alongside `min`, `maxLimitRequestRatio` and `defaultRequest`.

Why this answer

In a Kubernetes LimitRange spec, the max field (option A) sets the maximum compute resource limits (e.g., cpu, memory) that a container or Pod may request/limit within the namespace, so it is a valid parameter. The defaultRequest field (option C) specifies the default resource requests applied to containers that do not declare their own requests, making it a valid LimitRange parameter. The min field (option D) defines the minimum resource requests/limits a container or Pod must specify, and is also a valid LimitRange parameter.

Option B (replicas) is not part of LimitRange; replica counts belong to workload controllers such as Deployments or ReplicaSets. Option E (clusterWideAccess) is not a LimitRange field; it is unrelated to resource governance and resembles a storage or access setting rather than a LimitRange parameter.

Exam trap

EX280 often tests whether candidates confuse LimitRange fields (max, min, default, defaultRequest, maxLimitRequestRatio) with ResourceQuota fields (requests.cpu, limits.memory, pods, etc.) or workload fields like replicas.

Full explanation →

324

Multi-Selectmedium

Which TWO pieces of information are needed when defining a new Helm repository?

Select 2 answers

A.Chart version

B.Username

C.Namespace

D.Repository Name

E.Repository URL

AnswersD, E

Helm identifies each repository by a unique name, which becomes the prefix for charts installed from it (for example, bitnami/nginx). Without a distinct name, Helm cannot resolve or reference the repository, so it is mandatory alongside the URL.

Why this answer

When defining a new Helm repository, the two required pieces of information are the repository name (option D) and the repository URL (option E). The repository name (D) serves as the local alias used by Helm commands such as `helm repo add <name> <url>`, allowing you to reference the repo later (e.g., `helm install mychart <name>/<chart>`). The repository URL (E) is the actual endpoint where the `index.yaml` and chart packages are hosted, which Helm fetches to resolve and download charts.

A chart version (A) is not needed to define a repository; it is specified later when installing or pulling a specific chart. A username (B) is only required for private repositories that enforce authentication, not for defining a repository in general. A namespace (C) is a Kubernetes concept used at install time to scope resources, not part of a Helm repository definition.

Exam trap

EX280 often tests the distinction between repository definition and chart installation, so candidates may incorrectly think chart version is needed when adding a repo.

Full explanation →

325

MCQmedium

An administrator manages a Deployment named payments-api in the project finance-prod. During a maintenance window, changes to the pod template must be staged without any new pods being created. Once all edits are complete, a single rollout should start. Which oc command should the administrator run first?

A.oc rollout undo deployment/payments-api

B.oc rollout pause deployment/payments-api

C.oc rollout status deployment/payments-api

D.oc scale deployment/payments-api --replicas=0

AnswerB

This is correct because pausing a Deployment suspends the rollout controller so that staged pod-template edits are recorded in the Deployment spec but no new ReplicaSet is created and no pods are replaced. Subsequent changes accumulate until the Deployment is resumed, at which point a single rollout begins. This matches the requirement to stage multiple edits without triggering intermediate rollouts.

Why this answer

Pausing a Deployment suspends the rollout controller, so multiple pod-template edits accumulate in the Deployment spec without creating intermediate ReplicaSets or pods. When the Deployment is resumed with oc rollout resume, OpenShift performs a single rollout reflecting all staged changes. Reporting status, undoing a revision, or scaling to zero all fail to suppress rollout creation and therefore do not meet the staged-change requirement.

Exam trap

The trap here is confusing scaling a Deployment to zero replicas with pausing its rollout, when only pausing suppresses the creation of new ReplicaSets from pod-template edits.

Full explanation →

326

Multi-Selectmedium

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

Select 3 answers

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

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

C.oc get namespaces

D.oc describe clusteroperator authentication

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

AnswersB, D, E

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

Why this answer

Option B is correct because the kube-apiserver logs in the openshift-kube-apiserver namespace record authentication and token exchange activity, including OAuth token review and authentication errors, making them a primary source for diagnosing token exchange failures. Option D is correct because 'oc describe clusteroperator authentication' shows the status, conditions, and messages of the authentication ClusterOperator, which reveal whether the OAuth server and related authentication components are degraded or failing. Option E is correct because the oauth-openshift deployment in the openshift-authentication namespace runs the OpenShift OAuth server that issues and exchanges tokens, so its logs directly capture token exchange errors.

Option A is not relevant because the ingress-operator logs concern ingress controller management, not authentication token exchange. Option C is not relevant because listing namespaces only shows namespace existence and status, providing no authentication error details.

Exam trap

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

Full explanation →

327

MCQmedium

You need to inspect the effective permissions of a service account named 'cicd-bot' in the 'ci-cd' namespace to see if it can list deployments. Which command should you run?

A.oc auth can-i list deployments --as=system:serviceaccount:ci-cd:cicd-bot -n ci-cd

B.oc adm policy who-can get deployments -n ci-cd

C.oc describe serviceaccount cicd-bot -n ci-cd

D.oc get rolebindings --serviceaccount=cicd-bot

AnswerA

The --as flag performs user impersonation, letting you evaluate RBAC as the service account system:serviceaccount:ci-cd:cicd-bot. Combined with -n ci-cd, this tests whether that account can list deployments in its own namespace, satisfying the effective-permissions check.

Why this answer

`oc auth can-i` performs a SubjectAccessReview against the OpenShift API server, and the `--as=system:serviceaccount:<namespace>:<name>` flag impersonates the service account so the answer reflects that SA's effective RBAC permissions rather than the current user's. Adding `-n ci-cd` scopes the check to the ci-cd namespace, which is required because RoleBindings are namespace-scoped. This is the canonical way to verify whether a specific SA can perform a verb on a resource.

Exam trap

EX280 often tests whether candidates confuse inspecting a service account's metadata (`oc describe sa`) with actually evaluating its effective RBAC permissions — only `oc auth can-i --as=system:serviceaccount:...` performs a real authorization check.

How to eliminate wrong answers

Option B is wrong because `oc adm policy who-can get deployments` only lists which users/groups/SAs can perform the verb — it does not impersonate a specific service account, and it also asks about `get` rather than `list`, which are distinct RBAC verbs. Option C is wrong because `oc describe serviceaccount` only shows the SA's secrets, image pull secrets, and tokens — it does not enumerate the roles or permissions bound to the SA. Option D is wrong because `oc get rolebindings --serviceaccount=cicd-bot` is not a valid flag for that subcommand and would not resolve the effective permission anyway; rolebindings must be inspected individually and then correlated with roles.

Full explanation →

328

Multi-Selectmedium

Which TWO of the following can be used to troubleshoot a failing deployment?

Select 2 answers

A.oc rollout undo

B.oc describe deployment

C.oc logs

D.oc delete project

E.oc start-build

AnswersB, C

`oc describe deployment` surfaces the deployment's status conditions, replica counts, and the ReplicaSet and pod events behind a rollout failure, satisfying the need to pinpoint why pods never reached a ready state. It reports scheduling, image pull, and probe errors aggregated from the controller, giving the diagnostic detail a failing deployment requires.

Why this answer

Option B, `oc describe deployment`, is correct because it surfaces the deployment's status conditions, replica counts, events, and the underlying ReplicaSet/pod status, which is exactly what you need to diagnose why a rollout is failing. Option C, `oc logs`, is correct because retrieving container logs from the failing pods (or build/deployment logs) reveals application-level errors, crash reasons, and startup failures that explain the deployment failure. Option A, `oc rollout undo`, is a remediation command that reverts to a previous revision rather than a troubleshooting tool, so it does not help diagnose the failure.

Option D, `oc delete project`, destroys the namespace and all its resources, which is destructive and not a diagnostic step. Option E, `oc start-build`, triggers a new build and does not investigate why an existing deployment is failing.

Exam trap

EX280 often tests the distinction between troubleshooting commands and remediation or destructive commands, so candidates might mistakenly choose 'oc rollout undo' as a troubleshooting step when it is actually a fix.

Full explanation →

329

Multi-Selectmedium

Which TWO of the following are valid volume modes supported by PersistentVolumes and PersistentVolumeClaims in OpenShift?

Select 2 answers

A.Object

B.Block

C.Database

D.Filesystem

E.Stream

AnswersB, D

Block volume mode presents storage as a raw block device, bypassing a filesystem layer entirely. This satisfies the stem's requirement for valid PersistentVolume modes, since OpenShift supports both Filesystem and Block, with Block suited to databases and applications managing their own I/O directly.

Why this answer

In OpenShift/Kubernetes, the PersistentVolume spec.volumeMode field accepts exactly two values: Block and Filesystem. Option B (Block) is correct because a PV/PVC with volumeMode: Block exposes the volume as a raw block device with no filesystem, which is required for workloads like databases that manage their own storage layout. Option D (Filesystem) is correct because it is the default volumeMode, where the volume is formatted with a filesystem and mounted into a directory inside the pod.

Options A (Object), C (Database), and E (Stream) are not valid volumeMode values — they are not recognized by the Kubernetes/OpenShift API for PersistentVolumes or PersistentVolumeClaims, so they would be rejected.

Exam trap

EX280 often tests the exact enumeration of volumeMode values, baiting candidates with plausible-sounding but non-existent modes like Object, Stream, or Database.

Full explanation →

330

MCQmedium

An OpenShift 4.14 cluster administrator has installed an Operator from OperatorHub into a custom namespace using a Subscription. The administrator notices that the Operator pod is not being created. Upon checking the Subscription, the installation mode is set to AllNamespaces, but the Operator target namespace is restricted. Which Operator Lifecycle Manager (OLM) object should the administrator inspect to troubleshoot why the CSV (ClusterServiceVersion) is not installing?

A.Check the MachineConfigPool for paused reconciliation flags.

B.Review the ClusterVersion resource status for pending updates.

C.Inspect the OperatorGroup in the target namespace to ensure its targetNamespaces match or support the Subscription scope.

D.Inspect the KubeletConfig custom resource for validation errors.

AnswerC

The OperatorGroup defines which namespaces a CSV can target; a mismatch between its `targetNamespaces` and the Subscription's AllNamespaces scope blocks CSV resolution, so no Operator pod is created. Inspecting it in the target namespace reveals whether the group supports that scope, directly diagnosing the failed installation.

Why this answer

The OperatorGroup defines the target namespaces that an Operator can watch and install into. When a Subscription uses AllNamespaces mode but the OperatorGroup restricts targetNamespaces, OLM cannot reconcile the CSV into the desired scope, so the Operator pod never gets created. Inspecting the OperatorGroup in the target namespace reveals the mismatch.

Exam trap

EX280 often tests the misconception that Subscription alone controls Operator scope, when in fact the OperatorGroup's targetNamespaces must be compatible with the Subscription's install mode.

How to eliminate wrong answers

Option A is wrong because MachineConfigPool paused flags affect node configuration updates, not OLM Operator installation. Option B is wrong because ClusterVersion status tracks OpenShift platform updates, unrelated to Operator CSV reconciliation. Option D is wrong because KubeletConfig validation errors affect kubelet settings on nodes, not Operator Lifecycle Manager behavior.

Full explanation →

331

MCQhard

An application running in OpenShift requires scratch space that lives and dies strictly with the Pod lifecycle, but needs to be mounted from a high-performance cluster-managed storage backend rather than local ephemeral node storage. Which feature should an administrator configure?

A.HostPath volumes mapped to a local directory on the worker node

B.A standard dynamically provisioned PVC with reclaimPolicy set to Delete

C.emptyDir with medium: Memory

D.Generic ephemeral inline volumes via a volume template in the Pod specification

AnswerD

Generic ephemeral volumes let a Pod template request a cluster-managed backend, such as a CSI driver, whose lifecycle is tied to the Pod. This satisfies both constraints: scratch space dies with the Pod, yet storage comes from a high-performance cluster backend rather than node-local disk.

Why this answer

Generic ephemeral inline volumes allow a Pod to specify a volume template that dynamically provisions a PersistentVolumeClaim (PVC) for the Pod's lifetime. The resulting PVC and its backing PersistentVolume (PV) are automatically deleted when the Pod is deleted, satisfying the 'lives and dies with the Pod' requirement. Because the volume is backed by a cluster-managed StorageClass, it can use high-performance storage backends (e.g., NVMe, Ceph RBD) rather than local node storage.

This is the only option that combines Pod-lifecycle-bound ephemeral semantics with cluster-managed persistent storage.

Exam trap

EX280 often tests the distinction between Pod-lifecycle-bound ephemeral storage and cluster-managed persistent storage, tricking candidates into choosing emptyDir or a standard PVC when the requirement explicitly demands both ephemeral lifecycle and a high-performance cluster storage backend.

How to eliminate wrong answers

Option A is wrong because HostPath volumes bind to a directory on the node's filesystem, which is local ephemeral node storage, not a cluster-managed high-performance backend, and the data persists on the node after the Pod is deleted (unless manually cleaned). Option B is wrong because a standard dynamically provisioned PVC with reclaimPolicy Delete is a standalone resource that is not automatically deleted when the Pod is deleted; it must be explicitly removed, so it does not strictly live and die with the Pod lifecycle. Option C is wrong because emptyDir with medium: Memory uses node RAM as ephemeral storage, which is local to the node and not a cluster-managed storage backend, and it is limited by node memory.

Full explanation →

332

Multi-Selecthard

An administrator is securing routes in an OpenShift cluster. Which THREE TLS termination types are supported natively by OpenShift Routes? (Choose THREE)

Select 3 answers

A.Passthrough

B.Edge

C.Proxy

D.FullMesh

E.Re-encrypt

AnswersA, B, E

Passthrough termination forwards encrypted traffic straight to the pod without decrypting at the router, so the application handles TLS itself. It is one of the three termination types OpenShift Routes support natively, satisfying the stem's requirement alongside edge and re-encrypt.

Why this answer

OpenShift Routes natively support three TLS termination types: Edge, Passthrough, and Re-encrypt. Option A (Passthrough) is correct because the router forwards encrypted traffic directly to the pod without terminating TLS, letting the application handle the certificate. Option B (Edge) is correct because TLS is terminated at the router, which then forwards plain HTTP to the backend pods.

Option E (Re-encrypt) is correct because TLS is terminated at the router and a new TLS connection is established to the backend using a separate certificate. Option C (Proxy) is not a valid OpenShift Route termination type, and Option D (FullMesh) is not a supported termination type either; both are distractors not recognized by the Route API.

Exam trap

EX280 often tests the exact set of Route TLS termination types — candidates may invent or recall 'Proxy' or 'FullMesh' from other contexts (e.g., service mesh, load balancers) and select them. The exam expects you to know only edge, passthrough, and re-encrypt are valid.

Full explanation →

333

MCQmedium

An administrator configures a LoadBalancer service on an OpenShift cluster running on a cloud provider. However, the EXTERNAL-IP remains in a <pending> state indefinitely. What is the most likely reason?

A.The cluster is missing a valid Ingress controller deployment.

B.The cloud controller manager or cloud credentials operator is not configured to provision external load balancers.

C.The NetworkPolicy is blocking cloud provider traffic.

D.The NodePort range is exhausted.

AnswerB

Without a functioning cloud controller manager or properly configured cloud credentials operator, OpenShift cannot call the cloud provider's API to provision the external load balancer, so the EXTERNAL-IP stays `<pending>`. This directly satisfies the stem's cloud-provider constraint: the LoadBalancer service requires cloud integration to allocate an external address.

Why this answer

When a LoadBalancer service on a cloud provider remains in <pending> for EXTERNAL-IP, the most common cause is that the cloud controller manager (or the cloud credentials operator in OpenShift) is not properly configured to provision external load balancers. Without valid cloud credentials and a functioning CCM, OpenShift cannot create the underlying cloud LB resource, leaving the service without an external IP.

Exam trap

EX280 often tests the misconception that Ingress controllers or NetworkPolicies affect LoadBalancer service provisioning, when the real dependency is the cloud controller manager and cloud credentials operator.

How to eliminate wrong answers

Option A is wrong because a missing Ingress controller affects Route/Ingress functionality, not the provisioning of a LoadBalancer service's external IP — LoadBalancer services are handled by the cloud controller manager, not the Ingress controller. Option C is wrong because NetworkPolicy governs pod-to-pod traffic within the cluster and does not block the cloud provider's control-plane API calls needed to provision a load balancer. Option D is wrong because NodePort range exhaustion would cause a different error (service creation failure or port allocation error), not a perpetually pending EXTERNAL-IP.

Full explanation →

334

MCQeasy

Which field in a PersistentVolumeClaim specifies the minimum amount of storage space required by the workload?

A.spec.storageSize

B.spec.capacity.storage

C.spec.volumeSize

D.spec.resources.requests.storage

AnswerD

spec.resources.requests.storage declares the minimum storage the PVC demands, which the scheduler uses to bind a PersistentVolume with at least that capacity. This directly satisfies the stem's requirement for specifying minimum required space, unlike limits.storage, which caps usage rather than requesting capacity.

Why this answer

In a PVC, the requested storage size is specified under spec.resources.requests.storage, following the standard Kubernetes resource requirements schema. This value is matched against a PV's capacity during binding, and the resulting PV must be at least this size. It is the same pattern used for CPU and memory requests in pod specs.

Exam trap

EX280 often tests exact YAML paths — candidates confuse PVC request fields with PV capacity fields or invent keys like storageSize.

How to eliminate wrong answers

Option A is wrong because spec.storageSize is not a valid PVC field; it resembles a made-up shorthand. Option B is wrong because spec.capacity.storage belongs to a PersistentVolume's status/spec capacity, not a PVC request. Option C is wrong because spec.volumeSize is not a recognized Kubernetes API field.

Full explanation →

335

MCQeasy

Which OpenShift 4.14 command is used to uncordon a worker node and return it to a schedulable state after maintenance?

A.oc node enable

B.oc adm uncordon

C.oc adm schedulable

D.oc scale node

AnswerB

The oc adm uncordon command clears the unschedulable taint from a node, allowing the scheduler to place new pods on it again. This is the exact counterpart to oc adm cordon, which marked the worker unschedulable before maintenance began.

Why this answer

The correct command is `oc adm uncordon <node-name>`. This command removes the unschedulable taint from the node, allowing the scheduler to place new pods on it. It is the standard OpenShift/Kubernetes administrative command for reversing a cordon operation.

Exam trap

EX280 often tests the distinction between `oc adm cordon/uncordon` and other node management commands, and candidates may confuse `uncordon` with `drain` or invent non-existent commands like `oc node enable`.

How to eliminate wrong answers

Option A is wrong because `oc node enable` does not exist as a command in OpenShift; node management is done via `oc adm`. Option C is wrong because `oc adm schedulable` is not a valid subcommand; the correct subcommands are `cordon` and `uncordon`. Option D is wrong because `oc scale node` is not a valid command; scaling applies to resources like Deployments or ReplicationControllers, not nodes.

Full explanation →

336

Multi-Selecthard

An administrator needs to configure secure access to a private registry for both node image pulls and OLM operator deployments. Which THREE actions or resources are required across the cluster? (Choose THREE)

Select 3 answers

A.Update the global pull secret in openshift-config/pull-secret with registry credentials.

B.Ensure CA trust certificates are distributed to nodes via ConfigMaps and image config.

C.Modify the ClusterVersion spec to disable TLS verification globally.

D.Scale the Machine API operator to zero during credential updates.

E.Configure ImageContentSourcePolicy or ImageTagMirrorSet resources for image redirection.

AnswersA, B, E

Global pull secret enables nodes to pull images from authenticated registries.

Why this answer

Option A is correct because the global pull secret stored in the openshift-config namespace as pull-secret must contain the private registry credentials so that all nodes and the internal registry can authenticate when pulling images. Option B is correct because when the registry uses a custom or self-signed CA, the CA certificate must be distributed to nodes via a ConfigMap referenced in the cluster-wide image config (image.config.openshift.io/cluster) so that CRI-O and related components trust the registry's TLS certificate. Option E is correct because ImageContentSourcePolicy (or the newer ImageTagMirrorSet/ImageDigestMirrorSet) resources redirect image pulls from upstream references to the private registry mirror, which is required for both node image pulls and OLM operator deployments to resolve images correctly.

Option C is incorrect because disabling TLS verification globally via ClusterVersion is not a supported or secure practice and would undermine the secure access requirement. Option D is incorrect because scaling the Machine API operator to zero is unrelated to registry credential or trust configuration and would disrupt cluster machine management.

Exam trap

EX280 often tests the misconception that updating only the global pull secret is sufficient for private registry access, when in fact CA trust distribution and image mirror/redirection policies are equally required for both node pulls and OLM operator deployments.

Full explanation →

337

MCQeasy

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

A.oc adm cluster-status

B.oc get nodes

C.oc get pods --all-namespaces

D.oc get clusteroperators

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

338

MCQhard

An administrator needs to increase the size of an existing PVC bound to a gp3 storage class in an OpenShift cluster. What is the mandatory first step before editing the PVC spec?

A.Ensure allowVolumeExpansion: true is set on the corresponding StorageClass.

B.Manually update the underlying cloud provider disk size via the AWS console.

C.Delete the PV and recreate it with the new size.

D.Scale down all pods using the PVC to zero replicas.

AnswerA

Volume expansion only proceeds when the StorageClass permits it, so `allowVolumeExpansion: true` must be present on the gp3 StorageClass before the PVC spec can be edited. Without this field, the API server rejects the resize request, making it the mandatory prerequisite for this scenario.

Why this answer

Before a PVC can be expanded, the StorageClass that provisioned it must have 'allowVolumeExpansion: true' set. Without this field, the PVC's spec.resources.requests.storage cannot be increased — the API server will reject the edit or the resize will never complete. This is the mandatory first step.

Exam trap

EX280 often tests the misconception that you can simply edit the PVC size — candidates forget that the StorageClass must have allowVolumeExpansion: true, and that without it the edit is rejected or never completes. The exam expects you to know this is the mandatory first step.

How to eliminate wrong answers

Option B is wrong because manually resizing the underlying cloud disk bypasses Kubernetes' CSI resize workflow and can leave the PV/PVC status inconsistent; the correct path is to edit the PVC and let the CSI driver handle the resize. Option C is wrong because deleting and recreating the PV would destroy data and is not required — online expansion is supported for gp3 via the EBS CSI driver. Option D is wrong because scaling pods to zero is not a prerequisite for volume expansion; most CSI drivers support online expansion while pods are running, and even offline expansion does not require scaling to zero.

Full explanation →

339

MCQhard

When using OIDC for authentication, what does the 'issuer' field in the configuration represent?

A.The secret key for the OIDC provider

B.The client ID of the OpenShift cluster

C.The hostname of the OpenShift API

D.The URL of the OIDC provider

AnswerD

The issuer field holds the HTTPS URL identifying the OIDC provider, matching the `iss` claim in issued tokens. OpenShift uses it to discover endpoints via `/.well-known/openid-configuration` and to validate that tokens originate from the trusted identity source, satisfying the requirement to bind authentication to a specific provider.

Why this answer

In OpenShift's OIDC identity provider configuration, the 'issuer' field is the URL of the OIDC identity provider (IdP) that OpenShift will trust for authentication. OpenShift uses this URL to discover the provider's OIDC metadata via the /.well-known/openid-configuration endpoint, which supplies the authorization, token, and JWKS endpoints. The issuer value must exactly match the 'iss' claim in the tokens the IdP issues, otherwise token validation fails.

Exam trap

EX280 often tests whether candidates confuse the OIDC 'issuer' (the IdP's URL) with the client ID, client secret, or the cluster's own OAuth endpoint — all of which are separate configuration fields.

How to eliminate wrong answers

Option A is wrong because the secret key (client secret) is a separate credential configured alongside the client ID, not the issuer; the issuer is a URL, not a secret. Option B is wrong because the client ID identifies the OpenShift OAuth client registered with the IdP, not the IdP itself. Option C is wrong because the OpenShift API hostname is the OAuth server endpoint used by clients, not the identity provider's issuer URL.

Full explanation →

340

MCQeasy

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

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

B.oc describe route my-app-route

C.oc show route my-app-route

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

341

MCQhard

An administrator running OpenShift 4.14 wants to configure automatic approval for an Operator subscription updates using the Operator Lifecycle Manager. Which field and value in the Subscription resource must be set?

A.Set 'spec.installPlanApproval: Automatic'

B.Set 'spec.channel.autoApprove: yes'

C.Set 'spec.autoUpgrade: true'

D.Set 'spec.approvalStrategy: Immediate'

AnswerA

Setting `spec.installPlanApproval: Automatic` on the Subscription resource satisfies the stem's requirement for automatic approval of Operator updates. The Operator Lifecycle Manager reads this field and installs each new InstallPlan without manual intervention, whereas the default `Manual` value requires an administrator to approve every upgrade.

Why this answer

In OpenShift, the Subscription resource's spec.installPlanApproval field controls whether InstallPlans for an Operator update are approved automatically or manually. Setting it to 'Automatic' means OLM will automatically approve any InstallPlan that is generated for a new version in the subscribed channel, enabling seamless updates. This is the documented field and value for automatic approval in OLM.

Exam trap

EX280 often tests the exact field name and value for OLM subscription configuration, and candidates may confuse it with non-existent fields like autoUpgrade or approvalStrategy, or incorrectly assume that channel settings control approval.

How to eliminate wrong answers

Option B is wrong because 'spec.channel.autoApprove' does not exist; the channel field is a string specifying the update channel (e.g., 'stable'), not an object with an autoApprove property. Option C is wrong because 'spec.autoUpgrade' is not a valid field in the Subscription CRD; automatic upgrades are controlled via installPlanApproval, not a boolean autoUpgrade. Option D is wrong because 'spec.approvalStrategy' is not a field; the correct field is installPlanApproval, and its valid values are 'Automatic' or 'Manual', not 'Immediate'.

Full explanation →

342

MCQmedium

An administrator wants to prevent non-admin users from creating any new projects in the OpenShift cluster. How can this be accomplished?

A.Set the project request limit quota to zero globally.

B.Delete the 'cluster-admin' role from all users.

C.Delete the 'self-provisioner' ClusterRoleBinding attached to the 'system:authenticated' group.

D.Modify the OAuth configuration to reject all login requests.

AnswerC

Removing the self-provisioner ClusterRoleBinding from system:authenticated strips the cluster-wide permission that lets any authenticated user create projects, satisfying the constraint of blocking all non-admin project creation. Administrators retain access through their own bindings, so no legitimate admin capability is lost.

Why this answer

The ability for authenticated users to create projects is granted by the self-provisioner ClusterRole, which is bound to the system:authenticated group via a ClusterRoleBinding. Removing that binding revokes the self-provisioner capability cluster-wide, preventing non-admin users from creating new projects. This is the standard OpenShift method to disable self-provisioning.

Exam trap

EX280 often tests the specific ClusterRoleBinding that enables self-provisioning, and candidates may confuse it with quota or OAuth settings.

How to eliminate wrong answers

Option A is wrong because project request limits are not a global quota setting; quotas apply to resources within projects, not project creation itself. Option B is wrong because deleting the cluster-admin role from users does not specifically prevent project creation and would have broader, unintended consequences. Option D is wrong because modifying OAuth to reject logins would block all authentication, not just project creation, and is overly drastic.

Full explanation →

343

Multi-Selectmedium

Which TWO statements are true regarding Kustomize usage within OpenShift? (Choose two.)

Select 2 answers

A.Kustomize replaces the Kubernetes API server entirely during resource creation.

B.Kustomize is natively integrated into the oc command line tool using the -k flag.

C.Kustomize requires a centralized chart repository server similar to ChartMuseum.

D.Kustomize allows modifying base manifests using patches and name prefixes/suffixes.

E.Kustomize requires writing complex Go templates with conditional logic statements.

AnswersB, D

The oc client embeds Kustomize directly, so applying a directory containing a kustomization.yaml via the -k flag builds and deploys the rendered manifests. This native integration satisfies the statement that Kustomize works through oc without requiring separate kustomize binaries or plugins.

Why this answer

Option B is correct because OpenShift's oc CLI natively integrates Kustomize, allowing users to build and apply a kustomization directory directly with commands like 'oc apply -k <dir>' or 'oc kustomize <dir>', without needing a separate kustomize binary. Option D is correct because Kustomize's core purpose is declarative customization of base YAML manifests through kustomization.yaml features such as strategic-merge and JSON 6902 patches, plus namePrefix and nameSuffix transformers, which is exactly how OpenShift users overlay environment-specific changes. Option A is wrong because Kustomize is a client-side manifest rendering tool and never replaces or bypasses the Kubernetes API server; resources are still created via the API server.

Option C is wrong because Kustomize works with plain directories of YAML and requires no centralized chart repository like ChartMuseum (that concept belongs to Helm). Option E is wrong because Kustomize deliberately avoids Go templating and conditional logic, using declarative patches and overlays instead.

Exam trap

EX280 often tests the confusion between Kustomize and Helm, tricking candidates into selecting answers about chart repositories or Go templating that apply to Helm, not Kustomize.

Full explanation →

344

MCQeasy

Which object defines the parameters used by a storage provider to take snapshots of persistent volumes in OpenShift?

A.SnapshotterConfiguration

B.StorageClass

C.VolumeSnapshotContent

D.VolumeSnapshotClass

AnswerD

VolumeSnapshotClass supplies the driver and deletion-policy parameters a CSI storage provider needs when creating a VolumeSnapshot, satisfying the stem's requirement for the object defining snapshot parameters. Unlike VolumeSnapshot, which requests a specific snapshot, the class holds the reusable configuration the driver consumes.

Why this answer

VolumeSnapshotClass is the cluster-scoped object that defines the CSI driver and deletion policy used when taking snapshots of PersistentVolumes. It plays the same role for snapshots that a StorageClass plays for provisioning — it tells the snapshot controller which driver to invoke and how to handle the resulting VolumeSnapshotContent.

Exam trap

EX280 often tests the parallel between StorageClass (provisioning) and VolumeSnapshotClass (snapshotting), so candidates who pattern-match 'class defines parameters' to StorageClass pick the wrong object.

How to eliminate wrong answers

Option A is wrong because SnapshotterConfiguration is not a real Kubernetes/OpenShift API object — it is a fabricated name that sounds plausible but does not exist in the snapshot.storage.k8s.io API group. Option B is wrong because StorageClass defines how PersistentVolumes are dynamically provisioned (provisioner, reclaim policy, parameters), not how snapshots are taken. Option C is wrong because VolumeSnapshotContent represents the actual snapshot on the storage backend (the cluster-scoped counterpart to a VolumeSnapshot), not the class that parameterizes snapshot creation.

Full explanation →

345

MCQeasy

Which command allows an administrator to view details, including events and current binding status, of a specific PersistentVolume named 'pv-data01'?

A.oc status pv-data01

B.oc get pv pv-data01 -o yaml

C.oc describe pv pv-data01

D.oc logs pv/pv-data01

AnswerC

oc describe pv pv-data01 queries the cluster for that PersistentVolume and renders its specification, status, events and current binding to a PersistentVolumeClaim. The describe subcommand exposes exactly the events and binding status the question requires.

Why this answer

The 'oc describe pv pv-data01' command retrieves detailed information about the PersistentVolume, including its status, capacity, access modes, reclaim policy, and associated events, which is exactly what the administrator needs. The describe subcommand aggregates the object's spec, status, and recent events into a human-readable format.

Exam trap

EX280 often tests the difference between 'get -o yaml' and 'describe', where candidates incorrectly assume YAML output includes events and binding status summaries.

How to eliminate wrong answers

Option A is wrong because 'oc status' provides a high-level overview of the current project and does not accept a PV name as an argument. Option B is wrong because 'oc get pv pv-data01 -o yaml' outputs the raw YAML manifest, which does not include events or a summarized binding status. Option D is wrong because 'oc logs' retrieves container logs from pods and does not work on PersistentVolume resources.

Full explanation →

346

Multi-Selectmedium

Which TWO volume types are considered ephemeral storage patterns native to Kubernetes and OpenShift?

Select 2 answers

A.Generic ephemeral inline volumes

B.NFS network shares

C.PersistentVolumeClaim

D.emptyDir

E.AWS EBS volumes

AnswersA, D

Generic ephemeral inline volumes embed a volume template directly in the pod spec, letting the pod own the lifecycle of dynamically provisioned storage. Kubernetes and OpenShift treat this as a native ephemeral pattern, distinct from persistent PVC-backed volumes.

Why this answer

Generic ephemeral inline volumes (A) are a native Kubernetes ephemeral storage pattern: they are declared inline in the pod spec via the ephemeral.volumeClaimTemplate field, and the lifecycle of the generated PVC is tied to the pod, so the storage is created and deleted with the pod. emptyDir (D) is the classic native ephemeral volume type, created when a pod is assigned to a node and deleted permanently when the pod is removed, which is exactly the definition of ephemeral storage in Kubernetes/OpenShift. NFS network shares (B) are persistent external storage, not an ephemeral pattern, and they survive pod deletion. PersistentVolumeClaim (C) represents durable, independently managed storage whose lifecycle is decoupled from the pod, so it is not ephemeral.

AWS EBS volumes (E) are persistent block storage (via the aws-ebs CSI driver) that outlives the pod and is not a native ephemeral pattern.

Exam trap

EX280 often tests ephemeral vs persistent storage classification — candidates mistakenly include PVC or network storage as ephemeral because they can be mounted by pods.

Full explanation →

347

MCQmedium

An administrator needs to update the global pull secret for an OpenShift 4.14 cluster so that nodes can pull images from a new authenticated private registry. Which resource stores the global pull secret?

A.The MachineConfigPool resource named 'worker'.

B.The ClusterVersion custom resource spec field 'pullSecret'.

C.A Secret named 'pull-secret' in the 'openshift-config' namespace.

D.A ConfigMap named 'global-pull-registry' in 'kube-system'.

AnswerC

The global pull secret resides in the 'openshift-config' namespace as a Secret named 'pull-secret', which the cluster propagates to each node's kubelet configuration. Updating this single resource satisfies the requirement that all nodes authenticate to the new private registry without per-node edits.

Why this answer

The global pull secret for an OpenShift cluster is stored as a Secret named 'pull-secret' in the openshift-config namespace. Updating this secret causes the MCO to propagate the new credentials to every node's /var/lib/kubelet/config.json (and to the internal registry), enabling pulls from the new authenticated registry. This is the documented location for cluster-wide registry credentials.

Exam trap

EX280 often tests the confusion between the ClusterVersion spec.pullSecret reference and the actual Secret object, plus the misconception that pull credentials live in a ConfigMap or in kube-system.

How to eliminate wrong answers

Option A is wrong because a MachineConfigPool only tracks node configuration rollout state — it does not store registry credentials. Option B is wrong because while ClusterVersion has a spec.pullSecret field, that field references the Secret by name in openshift-config; the actual credential data lives in the Secret, not in the ClusterVersion object. Option D is wrong because there is no ConfigMap named 'global-pull-registry' in kube-system — pull credentials are Secrets, not ConfigMaps, and the namespace is openshift-config, not kube-system.

Full explanation →

348

Multi-Selectmedium

An administrator needs to restrict pod creation based on Pod Security Standards namespaces. Which TWO of the following are valid Pod Security Standard levels defined by Kubernetes and supported in OpenShift? (Choose TWO)

Select 2 answers

A.hardened

B.restricted

C.baseline

D.secured

E.isolated

AnswersB, C

The restricted level is one of Kubernetes' three Pod Security Standards, alongside baseline and privileged. It enforces the strictest controls, including non-root execution, dropped capabilities and seccomp profiles. OpenShift's Security Context Constraints map to these levels, so selecting restricted satisfies the requirement to limit pod creation by namespace.

Why this answer

Option B (restricted) is correct because the Kubernetes Pod Security Standards define exactly three levels — privileged, baseline, and restricted — and restricted is the most stringent, enforcing hardening such as requiring non-root execution, dropping all capabilities, and disallowing hostPath/host namespaces. Option C (baseline) is correct because it is the minimally restrictive level that still blocks known privilege escalations (e.g., hostNetwork, hostPID, privileged containers) while allowing default pod configurations. OpenShift supports these levels via namespace labels such as pod-security.kubernetes.io/enforce=baseline or restricted, which is how an administrator restricts pod creation per namespace.

Options A (hardened), D (secured), and E (isolated) are not valid Pod Security Standard levels defined by Kubernetes; they are not recognized values for the pod-security.kubernetes.io/enforce label and therefore would not restrict pod creation as intended.

Exam trap

EX280 often tests whether candidates can distinguish the three real PSA levels (privileged, baseline, restricted) from plausible-sounding fakes like 'hardened', 'secured', or 'isolated' — memorizing the exact three names is essential.

Full explanation →

349

MCQmedium

An administrator needs to configure an authentication mechanism where users logging into the OpenShift web console are authenticated via an external corporate directory using LDAP. Which resource object should the administrator configure?

A.A Secret named identity-provider in the openshift-authentication namespace

B.The cluster OAuth custom resource named cluster

C.An Authentication custom resource named cluster in the kube-system namespace

D.A ConfigMap named ldap-config in the openshift-config namespace

AnswerB

The cluster OAuth custom resource configures identity providers for the web console, including LDAP, by defining the external directory connection and attribute mappings. Editing it satisfies the requirement to authenticate console users against the corporate directory.

Why this answer

In OpenShift, the cluster OAuth custom resource named `cluster` is the central configuration point for identity providers, including LDAP. Administrators configure the `spec.identityProviders` field to add an LDAP identity provider, specifying connection details, bind credentials, and attribute mappings. This resource is cluster-scoped and resides in the `openshift-config` namespace, and changes trigger a redeployment of the OAuth server pods.

Exam trap

EX280 often tests the location and name of the OAuth custom resource, tricking candidates into choosing a non-existent Authentication CR or a ConfigMap instead of the correct OAuth CR in `openshift-config`.

How to eliminate wrong answers

Option A is wrong because a Secret named `identity-provider` in `openshift-authentication` is not the correct resource; identity provider configuration is stored in the OAuth CR, and any referenced secrets (like bindPassword) are in `openshift-config`. Option C is wrong because there is no Authentication custom resource named `cluster` in `kube-system`; the correct resource is OAuth in `openshift-config`. Option D is wrong because a ConfigMap named `ldap-config` in `openshift-config` is not used for identity provider configuration; LDAP settings are part of the OAuth CR.

Full explanation →

350

Multi-Selectmedium

An administrator is configuring a PersistentVolume to be used by multiple pods across different nodes. The storage backend supports ReadWriteMany. Which two steps are required to ensure the volume is mounted correctly in all pods? (Choose two.)

Select 2 answers

A.Set the Pod's volumeMounts readOnly field to false.

B.Set the PersistentVolume's accessModes to ReadWriteMany.

C.Set the StorageClass's volumeBindingMode to WaitForFirstConsumer.

D.Set the PersistentVolume's reclaimPolicy to Retain.

E.Set the PersistentVolumeClaim's accessModes to ReadWriteMany.

AnswersB, E

The PersistentVolume's accessModes must include ReadWriteMany to indicate that the underlying storage supports simultaneous read-write access from multiple nodes. This is a prerequisite for the volume to be bound to a PVC requesting ReadWriteMany. Without this, the volume cannot satisfy the claim's access mode, and binding will fail.

Why this answer

To use a PersistentVolume with ReadWriteMany across multiple nodes, both the PersistentVolume and the PersistentVolumeClaim must specify ReadWriteMany in their accessModes. The PV indicates the storage's capability, and the PVC requests that capability. The pod's readOnly flag and reclaim policy do not affect the access mode compatibility.

Exam trap

The trap here is thinking that pod-level readOnly or reclaim policy settings are needed for ReadWriteMany, when the access modes on the PV and PVC are the determining factors.

Full explanation →

351

MCQeasy

What is the primary role of Operator Lifecycle Manager (OLM) in OpenShift 4.14?

A.Managing the installation, upgrades, and RBAC lifecycle of Operators in the cluster.

B.Monitoring node CPU and memory utilization thresholds.

C.Provisioning physical bare-metal servers for cluster expansion.

D.Encrypting etcd database contents at rest.

AnswerA

OLM installs, upgrades and manages the RBAC and lifecycle of Operators across the cluster, resolving dependency and version constraints automatically. This directly satisfies the question's focus on installation, upgrades and RBAC lifecycle management within OpenShift 4.14.

Why this answer

Operator Lifecycle Manager (OLM) is the OpenShift component that provides a declarative way to install, upgrade, and manage the lifecycle of Operators and their associated RBAC. It introduces Custom Resource Definitions (CRDs) like ClusterServiceVersion (CSV), Subscription, and InstallPlan to automate dependency resolution, version upgrades, and permission grants. OLM ensures Operators are installed with the correct service accounts, roles, and role bindings, and it handles upgrades through channels and approval strategies.

Thus, option A accurately captures OLM's primary role.

Exam trap

EX280 often tests the misconception that OLM handles low-level infrastructure tasks like node monitoring or etcd encryption, when in fact it is strictly focused on Operator lifecycle management.

How to eliminate wrong answers

Option B is wrong because node CPU and memory monitoring is handled by the OpenShift monitoring stack (Prometheus, Alertmanager, and node-exporter), not OLM. Option C is wrong because bare-metal provisioning is performed by the OpenShift installer (IPI/UPI) or Metal3, not OLM. Option D is wrong because etcd encryption at rest is configured via the API server's encryption configuration and is managed by the cluster's kube-apiserver, not OLM.

Full explanation →

352

MCQmedium

A cluster administrator needs to inspect the current default CNI network provider configured in an OpenShift 4.14 cluster. Which command or resource should the administrator check?

A.oc get dns cluster -o jsonpath='{.spec.baseDomain}'

B.oc get proxy cluster -o jsonpath='{.spec.httpProxy}'

C.oc get clusterversion version -o jsonpath='{.status.capabilities}'

D.oc get networks.config/cluster -o jsonpath='{.spec.networkType}'

AnswerD

The cluster network configuration object stores the active CNI plugin in its spec.networkType field, so querying networks.config/cluster returns the deployed provider directly. This satisfies the requirement to inspect the current default CNI on OpenShift 4.14 without inferring it from pod annotations or node state.

Why this answer

In OpenShift 4.x, the cluster-wide network configuration is stored in the networks.config.openshift.io/cluster resource, and the CNI plugin in use is exposed in the spec.networkType field. Running `oc get networks.config/cluster -o jsonpath='{.spec.networkType}'` returns the configured network plugin, typically OpenShiftSDN or OVNKubernetes. This is the authoritative place to inspect the default CNI provider.

Exam trap

EX280 often tests whether candidates know that the CNI provider lives in the networks.config.openshift.io/cluster object rather than in the dns, proxy, or clusterversion operator resources — the similar 'oc get <operator> cluster' syntax across these objects is the trap.

How to eliminate wrong answers

Option A is wrong because `oc get dns cluster` reads the cluster DNS operator configuration and its spec.baseDomain field returns the cluster's DNS base domain, not the CNI provider. Option B is wrong because `oc get proxy cluster` reads the cluster-wide proxy configuration and spec.httpProxy returns the HTTP proxy URL, which is unrelated to the CNI plugin. Option C is wrong because `oc get clusterversion version` reports the OpenShift version and its status.capabilities field lists optional cluster capabilities (like the ones that can be disabled), not the network provider.

Full explanation →

353

Multi-Selectmedium

An administrator needs to troubleshoot an upgrade failure in OpenShift 4.14. Which TWO actions or diagnostic steps should the administrator take? (Choose TWO)

Select 2 answers

A.Reboot the entire cluster control plane via physical power cycles.

B.Delete all pods in the openshift-cluster-version namespace to force a clean restart.

C.Inspect any cluster operators reporting 'Degraded=True' or 'Progressing=True'.

D.Run 'oc describe clusterversion' to view upgrade history, channels, and failure messages.

E.Scale down all OLM Operator subscriptions to zero.

AnswersC, D

Cluster operators expose their health through status conditions, so operators reporting Degraded=True or Progressing=True pinpoint which component is blocking the upgrade. Inspecting these conditions identifies the failing subsystem, satisfying the need to diagnose the OpenShift 4.14 upgrade failure.

Why this answer

Option C is correct because during an OpenShift 4.x upgrade the Cluster Version Operator orchestrates ClusterOperators, and any operator stuck with Degraded=True or Progressing=True directly identifies the component blocking or failing the upgrade, making it the primary diagnostic signal. Option D is correct because 'oc describe clusterversion' (or 'oc get clusterversion -o yaml') exposes the ClusterVersion status, including the current and desired channel, version history, conditions, and the specific failure message recorded by the CVO, which is essential for pinpointing why an upgrade failed. Option A is wrong because power-cycling the control plane is disruptive, unsupported, and risks etcd corruption without providing any diagnostic value.

Option B is wrong because deleting pods in openshift-cluster-version does not force a clean restart of the upgrade and can disrupt the CVO's reconciliation logic. Option E is wrong because scaling OLM subscriptions to zero would break operator management and is unrelated to diagnosing a cluster version upgrade failure.

Exam trap

EX280 often tests whether candidates know to inspect ClusterOperator conditions and clusterversion history rather than taking drastic remediation actions like rebooting the control plane or deleting CVO pods.

Full explanation →

354

MCQmedium

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

A./var/lib/etcd/cert

B./etc/origin/node/certificates

C./var/lib/kubelet/pki/

D./etc/kubernetes/pki

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

355

Multi-Selectmedium

Which THREE of the following are valid identity provider types supported natively in OpenShift Container Platform? (Choose THREE)

Select 3 answers

A.ActiveDirectoryDirectIdentityProvider

B.LocalDatabaseIdentityProvider

C.OpenIDConnectIdentityProvider

D.LDAPPasswordIdentityProvider

E.HTPasswdPasswordIdentityProvider

AnswersC, D, E

OpenIDConnectIdentityProvider is a native OpenShift identity provider type, configured via an OAuth custom resource. It authenticates users against an external OIDC issuer, making it one of the valid provider kinds alongside HTPasswd, LDAP and others.

Why this answer

Option C, OpenIDConnectIdentityProvider, is correct because OpenShift Container Platform natively supports OpenID Connect (OIDC) as an identity provider type, allowing integration with OIDC-compliant providers such as Keycloak or Google. Option D, LDAPPasswordIdentityProvider, is correct because OCP natively supports LDAP-based authentication via the LDAPPasswordIdentityProvider, which validates credentials against an LDAP directory using a bind operation. Option E, HTPasswdPasswordIdentityProvider, is correct because OCP natively supports the HTPasswdPasswordIdentityProvider, which validates usernames and passwords against a flat file generated by htpasswd.

Option A, ActiveDirectoryDirectIdentityProvider, is not a valid native provider type; Active Directory is integrated through the LDAP identity provider rather than a dedicated Active Directory provider. Option B, LocalDatabaseIdentityProvider, is not a valid native provider type; OCP does not provide a built-in local user database identity provider.

Exam trap

EX280 often tests whether candidates can distinguish real OpenShift identity provider type names from plausible-sounding fabrications like 'ActiveDirectoryDirectIdentityProvider' or 'LocalDatabaseIdentityProvider' that do not exist in the API schema.

Full explanation →

356

MCQeasy

An administrator wants to prevent developers from accidentally deploying containers that request excessive CPU resources in the 'analytics' namespace. Which object should the administrator create in that namespace?

A.ResourceQuota

B.ClusterRoleBinding

C.SecurityContextConstraints

D.LimitRange

AnswerD

A LimitRange enforces per-container minimum and maximum CPU and memory requests and limits at admission time within a namespace. Creating one in 'analytics' rejects any pod whose CPU request exceeds the configured ceiling, directly preventing developers from accidentally deploying over-resourced containers.

Why this answer

A LimitRange constrains per-pod or per-container resource requests and limits within a namespace, which is exactly what prevents a developer from submitting a pod that requests excessive CPU. It can set default, min, and max values for CPU/memory per container or pod, and the API server rejects any pod spec that violates those bounds. This is the correct object for per-object resource guardrails.

Exam trap

EX280 often tests the distinction between LimitRange (per-pod/container bounds) and ResourceQuota (namespace aggregate) — candidates pick ResourceQuota because it sounds like the resource-control object, but it does not stop a single oversized pod.

How to eliminate wrong answers

Option A is wrong because ResourceQuota caps aggregate namespace consumption (total CPU/memory across all pods), not the per-container request of a single pod — a single oversized pod could still be admitted if the namespace total is under quota. Option B is wrong because ClusterRoleBinding grants cluster-wide RBAC permissions and has nothing to do with resource sizing. Option C is wrong because SecurityContextConstraints govern pod security (SELinux, runAsUser, capabilities, volumes), not CPU/memory limits.

Full explanation →

357

MCQeasy

A developer wants to track multiple versions and tags of container images within an OpenShift cluster efficiently. Which OpenShift resource provides this capability?

A.Route

B.ImageStream

C.DeploymentConfig

D.BuildConfig

AnswerB

ImageStreams abstract image references, tracking multiple versions and tags via image tags and history within OpenShift. This satisfies the developer's need to manage and reference changing container images without hardcoding registry paths, enabling triggers and rollbacks.

Why this answer

An ImageStream is an OpenShift resource that acts as an abstraction layer over container images, allowing you to track multiple versions and tags of an image. It maintains a history of image changes and provides a stable reference that can trigger builds and deployments when new images are pushed or tagged. This makes it ideal for efficiently managing image versions and tags within the cluster.

Exam trap

EX280 often tests the distinction between resources that manage images versus those that manage deployments or builds, causing candidates to confuse ImageStreams with BuildConfigs or DeploymentConfigs.

How to eliminate wrong answers

Option A is wrong because a Route exposes a service to external traffic and has nothing to do with tracking container image versions or tags. Option C is wrong because a DeploymentConfig defines how to deploy an application, including triggers and strategies, but it does not itself track multiple versions or tags of images; it relies on ImageStreams for that capability. Option D is wrong because a BuildConfig defines how to build a container image from source code, but it does not provide version or tag tracking of existing images.

Full explanation →

358

Multi-Selecthard

Which TWO of the following steps are required when configuring an HTPasswd identity provider in OpenShift? (Choose TWO)

Select 2 answers

A.Create a ClusterRoleBinding for all users in the htpasswd file.

B.Place the htpasswd file directly on every control plane node at '/etc/origin/master/'.

C.Restart the kube-apiserver static pods manually across all masters.

D.Create a Secret containing the htpasswd file in the 'openshift-config' namespace.

E.Update the cluster OAuth configuration resource to reference the HTPasswd identity provider and Secret.

AnswersD, E

Creating the htpasswd Secret in the `openshift-config` namespace satisfies OpenShift's requirement that OAuth identity provider secrets reside there for the cluster OAuth server to consume. The `oauth` resource references this Secret by name, so the file must exist in that namespace before the identity provider can authenticate users.

Why this answer

Option D is correct because OpenShift requires the htpasswd file to be stored as a Secret in the 'openshift-config' namespace, which the OAuth server mounts and reads; the file cannot be referenced from an arbitrary path on the nodes. Option E is correct because after creating the Secret you must edit the cluster-scoped OAuth custom resource (oc edit oauth cluster) to add an identityProviders entry of type HTPasswd that references that Secret by name, which triggers the OAuth server to reconfigure. Option A is not required: HTPasswd users are not automatically granted any cluster role, and creating a ClusterRoleBinding for all users is an optional authorization step, not part of identity provider configuration.

Option B is incorrect because the htpasswd file is not placed directly on control plane nodes at '/etc/origin/master/'; that legacy path is not how modern OpenShift consumes the file. Option C is incorrect because you do not manually restart kube-apiserver static pods; the OAuth server (an operator-managed deployment) redeploys automatically when the OAuth configuration changes.

Exam trap

EX280 often tests the misconception that OpenShift 4 still uses the OpenShift 3 file-based htpasswd path or requires manual pod restarts, when the correct approach is a Secret plus OAuth CR update.

Full explanation →

359

MCQeasy

Which command is used to delete a PersistentVolumeClaim named 'my-app-pvc' in the current project?

A.oc remove pvc my-app-pvc

B.oc delete pvc my-app-pvc

C.oc destroy pvc my-app-pvc

D.oc prune pvc my-app-pvc

AnswerB

`oc delete pvc my-app-pvc` targets the resource type by its short name, PersistentVolumeClaim, and the object name within the active project namespace, satisfying the stem's "current project" constraint. OpenShift resolves `pvc` as the standard abbreviation, so no `-n` flag is needed.

Why this answer

'oc delete pvc my-app-pvc' is the correct syntax to remove a PersistentVolumeClaim in the current project. The 'oc delete' verb works uniformly across resource types, and 'pvc' is the accepted short name for PersistentVolumeClaim. The current namespace is used unless -n is specified.

Exam trap

EX280 often tests whether candidates invent plausible-sounding verbs like 'remove', 'destroy', or 'prune' instead of the universal 'oc delete' that applies to every resource type.

How to eliminate wrong answers

Option A is wrong because 'oc remove' is not a valid OpenShift subcommand — the verb is 'delete'. Option C is wrong because 'oc destroy' does not exist in the oc CLI. Option D is wrong because 'oc prune' is used for cleaning up unused images, builds, and deployments, not for deleting arbitrary resources like PVCs.

Full explanation →

360

MCQhard

An OpenShift cluster uses a CSI driver that supports volume cloning. A user wants to clone an existing PVC named 'data-pvc' into a new PVC named 'clone-pvc'. How should the dataSource be specified?

A.dataSource: { apiGroup: "snapshot.storage.k8s.io", kind: "VolumeSnapshot", name: "data-pvc" }

B.spec.cloneSource: "data-pvc"

C.dataSource: { apiGroup: "", kind: "PersistentVolumeClaim", name: "data-pvc" }

D.spec.volumeName: "data-pvc"

AnswerC

For a same-namespace PVC clone, the dataSource uses an empty apiGroup with kind PersistentVolumeClaim and the source name, since core v1 resources belong to no API group. This satisfies the cloning requirement by referencing data-pvc correctly.

Why this answer

To clone an existing PVC named 'data-pvc' into a new PVC named 'clone-pvc' using a CSI driver that supports volume cloning, the dataSource field must specify the source PVC. The correct specification is dataSource: { apiGroup: "", kind: "PersistentVolumeClaim", name: "data-pvc" }. The apiGroup is empty because PersistentVolumeClaim is a core Kubernetes resource.

This tells the CSI driver to clone the volume from the specified PVC.

Exam trap

EX280 often tests the confusion between volume cloning and snapshot restoration, leading candidates to incorrectly specify a VolumeSnapshot as the data source.

How to eliminate wrong answers

Option A is wrong because it specifies a VolumeSnapshot as the data source, which is used for restoring from a snapshot, not for cloning a PVC directly. Option B is wrong because 'spec.cloneSource' is not a valid field in a PVC specification; the correct field is 'dataSource'. Option D is wrong because 'spec.volumeName' is used to bind a PVC to a specific pre-existing PV, not for cloning.

Full explanation →

361

MCQmedium

When creating a build using S2I, what does the 'assemble' script do?

A.Sets up the user environment

B.Starts the application

C.Downloads the base image

D.Builds the application artifacts

AnswerD

The assemble script executes the build logic inside the builder image, compiling source and producing the runnable artefacts placed in the build context. This is the S2I phase that transforms application source into deployable output, distinct from the run script that starts the resulting image.

Why this answer

In Source-to-Image (S2I), the assemble script is responsible for building the application artifacts from the source code. It runs after the source code is copied into the builder image and performs the necessary build steps, such as compiling code, installing dependencies, and preparing the application for execution. This is a core part of the S2I build process.

Exam trap

EX280 often tests the confusion between the assemble and run scripts. The trap is thinking that assemble starts the application, but it actually builds it.

How to eliminate wrong answers

Option A is wrong because setting up the user environment is typically handled by the run script or the builder image's setup, not the assemble script. Option B is wrong because starting the application is the role of the run script, which is executed when the container is launched. Option C is wrong because downloading the base image is done by the S2I tooling before the build process, not by the assemble script.

Full explanation →

362

MCQmedium

When performing a 'rollout undo' on a Deployment, what is the default behavior if no revision is specified?

A.Delete the current deployment

B.Return to the state at initial deployment

C.Roll back to the previous revision

D.Roll back to revision 1

AnswerC

With no revision given, rollout undo reverts the Deployment to the immediately preceding ReplicaSet revision, satisfying the default rollback behaviour. Kubernetes records each template change as a numbered revision, so omitting --to-revision simply steps back one, restoring the prior pod template and configuration.

Why this answer

The `oc rollout undo` command (and its kubectl equivalent) defaults to reverting a Deployment to the immediately preceding revision when no `--to-revision` flag is supplied. OpenShift tracks each DeploymentConfig/Deployment revision via ReplicaSets, and the undo operation simply scales up the prior ReplicaSet while scaling down the current one. This makes 'previous revision' the implicit target, not revision 1 or the initial state.

Exam trap

EX280 often tests whether candidates confuse the default 'previous revision' behavior of `rollout undo` with the explicit `--to-revision=1` flag that targets the initial deployment.

How to eliminate wrong answers

Option A is wrong because `rollout undo` never deletes a Deployment — it swaps the active ReplicaSet to a prior revision, leaving the Deployment object intact. Option B is wrong because returning to the initial deployment would require explicitly specifying `--to-revision=1`; the default is the immediately previous revision, not the first one. Option D is wrong because revision 1 is only the target if the administrator explicitly passes `--to-revision=1`; the default is the prior revision regardless of how many revisions exist.

Full explanation →

363

Multi-Selecthard

An administrator wants to customize worker node behavior in an OpenShift 4.14 cluster using the Machine Config Operator. Which THREE custom resources are natively provided and managed by the MCO for node customization? (Choose THREE)

Select 3 answers

A.ClusterVersion

B.MachineConfig

C.KubeletConfig

D.ContainerRuntimeConfig

E.OperatorGroup

AnswersB, C, D

MachineConfig is the MCO's core custom resource, delivering Ignition configs that write files, systemd units and kernel arguments to nodes. It satisfies the stem's requirement for a natively provided MCO resource used to customise worker node behaviour.

Why this answer

The Machine Config Operator (MCO) natively manages three node-customization custom resources: MachineConfig (B), which defines Ignition-based changes to files, systemd units, and kernel arguments on nodes; KubeletConfig (C), which customizes kubelet parameters such as maxPods, podPidsLimit, and eviction thresholds; and ContainerRuntimeConfig (D), which tunes CRI-O settings like pidsLimit and logLevel. These three CRs are all reconciled by the MCO's controller and rendered into the machine-config daemon's desired state. ClusterVersion (A) is managed by the Cluster Version Operator (CVO) to control cluster updates, not by the MCO for node customization.

OperatorGroup (E) is an OLM resource that scopes Operator installation to namespaces and is unrelated to MCO node configuration.

Exam trap

EX280 often tests the confusion between resources managed by different operators. The trap is assuming ClusterVersion is managed by MCO, but it's actually managed by CVO.

Full explanation →

364

MCQhard

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

A.oc get clusteroperator openshift-apiserver -o yaml

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

Full explanation →

365

MCQeasy

Which custom resource defines a group of nodes (such as all worker nodes or a custom compute pool) that share a common MachineConfig in OpenShift 4.14?

A.NodeGroup

B.MachineSet

C.MachineConfigPool

D.ConfigMap

AnswerC

MachineConfigPool groups nodes sharing a common MachineConfig, targeting updates to worker nodes or custom pools via node selectors. It is the custom resource that binds MachineConfigs to defined node sets, matching the stem's requirement precisely.

Why this answer

A MachineConfigPool (MCP) groups nodes that share the same MachineConfig, such as all worker nodes (the 'worker' pool) or a custom pool like 'infra'. The Machine Config Operator (MCO) applies MachineConfigs to nodes based on their pool membership, and each pool has its own rendered MachineConfig. This is the resource that defines a set of nodes with a common configuration.

Exam trap

The trap is confusing MachineSet (which manages machine lifecycle/scaling) with MachineConfigPool (which groups nodes for configuration), or picking the generic ConfigMap because it sounds like a configuration grouping resource.

How to eliminate wrong answers

Option A is wrong because NodeGroup is not an OpenShift resource — it is a concept in other systems (e.g., GKE node pools, EKS managed node groups), not an OpenShift CRD. Option B is wrong because MachineSet manages the lifecycle and scaling of machines (nodes) for a MachineConfigPool, but it does not define the configuration grouping itself — MachineSets are associated with a pool via labels, not the other way around. Option D is wrong because ConfigMap is a generic Kubernetes resource for storing non-confidential configuration data; it has no role in defining node configuration groups in OpenShift.

Full explanation →

366

Multi-Selecthard

Which THREE troubleshooting steps should an administrator take when a newly created Route fails to resolve or connect? (Choose THREE)

Select 3 answers

A.Reinstall the entire cluster storage operator.

B.Check that the Route hostname resolves correctly via DNS to the cluster router IP.

C.Verify that the referenced Service has active endpoints.

D.Inspect the Ingress controller operator logs for routing errors.

E.Modify the cluster kube-apiserver certificates.

AnswersB, C, D

A Route only works if its hostname resolves to the router's external IP; verifying DNS resolution confirms whether the failure lies in name resolution rather than the Route or Service configuration, isolating the fault domain.

Why this answer

Option B is correct because a Route only works if its hostname resolves via DNS to the cluster's router (Ingress controller) IP; if DNS points elsewhere or does not resolve, clients cannot reach the route. Option C is correct because a Route forwards to a Service, and if that Service has no active endpoints (e.g., selector mismatch or unready pods), the router returns 503 and the route appears broken. Option D is correct because the Ingress controller operator/router logs record routing errors such as missing TLS secrets, invalid route admission, or backend failures, making them the primary diagnostic source.

Option A is wrong because reinstalling the entire cluster storage operator is unrelated to Route resolution and would not fix DNS, Service, or router issues. Option E is wrong because modifying kube-apiserver certificates is a destructive, unrelated action that does not affect Route hostname resolution or backend connectivity.

Exam trap

EX280 often tests the layered troubleshooting approach for Routes — candidates focus only on the Route object itself and forget to check DNS resolution, Service endpoints, and Ingress controller logs, which are the actual common failure points.

Full explanation →

367

Multi-Selecteasy

Which TWO security standards are natively tracked in OpenShift?

Select 2 answers

A.isolated

B.custom

C.restricted

D.privileged

E.secure

AnswersC, D

The `restricted` SCC enforces the tightest pod security by dropping all Linux capabilities, blocking host networking and privileged escalation, and requiring non-root execution. It satisfies the stem's demand for a natively tracked OpenShift security standard, since SCCs ship with the platform and are enforced by the API server during pod admission.

Why this answer

In OpenShift, Security Context Constraints (SCCs) are the native mechanism for controlling pod permissions, and the platform ships with several predefined SCCs, including restricted and privileged. The restricted SCC is correct because it is the default, most locked-down policy that enforces running as a non-root user, drops capabilities, and uses a restricted SELinux context. The privileged SCC is correct because it is a built-in policy that grants broad access, allowing privileged containers, host networking, host PID/IPC, and all capabilities for cluster-admin workloads.

The options isolated, custom, and secure are not native OpenShift SCC names, so they are not tracked as built-in security standards.

Exam trap

EX280 often tests whether candidates can distinguish built-in SCCs from made-up names — the trap is selecting plausible-sounding options like 'isolated' or 'secure' that don't exist in the default SCC set.

Full explanation →

368

MCQeasy

Which SCC is assigned by default to authenticated users who are not service accounts?

A.restricted

B.anyuid

C.nonroot

D.privileged

AnswerA

OpenShift assigns the restricted SCC to authenticated non-service-account users by default, permitting only minimal, non-root access. This satisfies the stem's constraint of the default SCC for regular authenticated users, since service accounts instead receive the anyuid or nonroot SCCs depending on their namespace role bindings.

Why this answer

In OpenShift, authenticated users who are not service accounts are automatically granted the 'restricted' SCC (and in newer versions restricted-v2) via the system:authenticated group binding. This is the default least-privilege SCC that allows pods to run without root, with dropped capabilities. It is assigned by the cluster's default SCC admission configuration, not by any user action.

Exam trap

EX280 often tests the confusion between the default SCC for authenticated users (restricted) versus service accounts, and the misconception that anyuid or nonroot is granted by default.

How to eliminate wrong answers

Option B is wrong because anyuid allows containers to run as any UID including root and is not granted by default to authenticated users — it must be explicitly bound. Option C is wrong because nonroot is a stricter SCC that requires a specific non-root UID and is not the default for authenticated users. Option D is wrong because privileged grants full host access and is never assigned by default; it must be explicitly granted to specific service accounts.

Full explanation →

369

MCQeasy

A cluster administrator is preparing a PersistentVolume for a database that must survive node failures and be reattached to a rescheduled pod. The storage backend is a CSI driver that supports topology-aware provisioning. Which access mode should the administrator specify in the PersistentVolumeClaim to allow the volume to be mounted as read-write by a single node at a time?

A.ReadWriteOnce

B.ReadWriteMany

C.ReadOnlyMany

D.ReadWriteOncePod

AnswerA

ReadWriteOnce allows the volume to be mounted as read-write by a single node. The CSI driver enforces node-level attachment, so when the pod is rescheduled to another node the volume is detached and reattached there. This matches a database workload that must not be written concurrently from multiple nodes while still tolerating node failure.

Why this answer

ReadWriteOnce grants read-write access to a single node, letting the CSI driver detach and reattach the volume when the pod moves to a healthy node. This balances write exclusivity with failure recovery, unlike ReadOnlyMany, ReadWriteMany, or the pod-scoped ReadWriteOncePod, which either forbid writes or over-constrain attachment.

Exam trap

The trap here is confusing node-level exclusivity with pod-level exclusivity, where ReadWriteOncePod sounds similar but restricts to one pod rather than one node.

Full explanation →

370

MCQeasy

Which tool would you use to package an application including its dependencies and configuration for easy distribution in OpenShift?

A.Helm

B.oc build

C.Kustomize

D.S2I

AnswerA

Helm charts bundle Kubernetes manifests, default values and dependency charts into a single versioned artefact, so an application's configuration and dependencies ship together. This satisfies the stem's packaging-and-distribution requirement, unlike raw manifests or templates alone.

Why this answer

Helm is a package manager for Kubernetes/OpenShift that bundles application manifests, dependencies, and configuration into a single chart for easy distribution and versioned installation. It supports templating, values files, and dependency management, making it the standard tool for packaging and distributing applications. The other options are build or configuration tools, not packaging/distribution tools.

Exam trap

EX280 often tests the distinction between packaging/distribution tools (Helm) and build/configuration tools (S2I, Kustomize, oc start-build), so candidates must not pick a build tool when the question asks for packaging.

How to eliminate wrong answers

Option B is wrong because 'oc build' is not a real command; builds are started with 'oc start-build' and are used to produce images, not package applications. Option C is wrong because Kustomize is a configuration overlay tool that customizes YAML without templating, but it does not package dependencies or provide a distribution format like a chart. Option D is wrong because S2I (Source-to-Image) builds container images from source code; it does not package an application with its dependencies and configuration for distribution.

Full explanation →

371

MCQmedium

A cluster administrator has deleted a PersistentVolumeClaim, but the underlying PersistentVolume still exists in the cluster with a Released status and its data remains intact on the storage backend. What is the most likely cause of this behavior?

A.The StorageClass associated with the PV has allowVolumeExpansion set to false.

B.The volume access mode was configured as ReadWriteMany instead of ReadWriteOnce.

C.The persistentVolumeReclaimPolicy of the PersistentVolume was set to Retain.

D.The PVC was protected by a finalizer that prevented immediate deletion.

AnswerC

Retain reclaim policy deliberately preserves the PersistentVolume and its backend data after the bound claim is deleted, transitioning the volume to Released rather than deleting it. This exactly matches the stem's constraint: the PVC is gone yet the PV survives with data intact, which Delete or Recycle would not produce.

Why this answer

When a PVC is deleted, the PersistentVolume's reclaim policy determines what happens to the underlying storage. If the PV's persistentVolumeReclaimPolicy is set to Retain, the PV transitions to Released status and the data on the backend is preserved; the PV must be manually reclaimed or deleted by an administrator. This exactly matches the described behavior.

Exam trap

EX280 often tests whether candidates confuse PVC finalizers (which delay deletion while in use) with PV reclaim policies (which govern post-deletion data retention) — the Released status with intact data is the signature of Retain.

How to eliminate wrong answers

Option A is wrong because allowVolumeExpansion controls whether a PVC can be resized, not what happens to a PV after PVC deletion; it has no effect on reclaim behavior. Option B is wrong because access modes (ReadWriteOnce, ReadWriteMany, ReadOnlyMany) govern how many nodes can mount a volume concurrently, not the post-deletion lifecycle of the PV. Option D is wrong because while PVCs can have finalizers (kubernetes.io/pvc-protection) that delay deletion while a pod is using them, once the PVC is actually deleted, the PV's fate is governed by reclaimPolicy, not by a finalizer.

Full explanation →

372

MCQhard

An administrator wants to apply kernel arguments to all worker nodes in an OpenShift 4.14 cluster using the Machine Config Operator. After creating a new MachineConfig object, the administrator notices that the worker nodes are not updating and the MachineConfigPool status shows 'Updating=False'. What is the most likely cause?

A.The administrator forgot to run 'oc adm upgrade --force' to trigger node reboots.

B.The MachineConfig object lacks the correct labels required to associate it with the target MachineConfigPool.

C.The Cluster Version Operator must be manually restarted to detect new MachineConfig definitions.

D.The cluster storage provider must be re-initialized to support kernel argument persistence.

AnswerB

The Machine Config Operator selects MachineConfigs by the machineconfiguration.openshift.io/role label, which binds each object to a MachineConfigPool. Without the matching worker role label, the rendered config never merges into that pool, so nodes stay put and the pool reports Updating=False.

Why this answer

MachineConfig objects are associated with a MachineConfigPool (MCP) through the 'machineconfiguration.openshift.io/role' label (e.g., 'worker' or 'master'). Without this label, the MCO has no way to know which pool should consume the config, so the pool's rendered config never changes and 'Updating=False' remains. The MCO does not scan for arbitrary MachineConfigs — it only renders configs whose role label matches the pool's node selector.

Exam trap

EX280 often tests the assumption that any MachineConfig object is automatically applied cluster-wide; the trap is forgetting that MachineConfigs are scoped to a pool via the 'machineconfiguration.openshift.io/role' label, not applied globally.

How to eliminate wrong answers

Option A is wrong because 'oc adm upgrade --force' is a Cluster Version Operator command for triggering cluster upgrades, not for applying MachineConfig changes; the MCO reboots nodes automatically when the rendered config changes. Option C is wrong because the Cluster Version Operator does not detect MachineConfig objects — the Machine Config Operator watches them directly, and restarting CVO has no effect on MCP rendering. Option D is wrong because kernel argument persistence is handled by the MCO writing to the node's bootloader config via Ignition; storage providers have no role in this process.

Full explanation →

373

MCQmedium

A user creates a PVC, but the storage backend fails to provision the volume. Where can the administrator look to find detailed error messages emitted by the external provisioner controller?

A.Run 'oc adm diagnostics storage'.

B.Inspect the container image registry logs.

C.Review the logs of the CSI external provisioner controller pod in its management namespace.

D.Check /var/log/messages on the control plane nodes.

AnswerC

The external provisioner controller performs dynamic provisioning, so its pod logs record the storage backend's API errors and failure reasons. Checking that pod's logs in its management namespace reveals why the PVC's volume could not be created.

Why this answer

When a PVC fails to provision, the external provisioner sidecar (e.g., csi-provisioner) running alongside the CSI driver controller is the component that actually calls the storage backend's CreateVolume API and logs the resulting errors. In OpenShift, CSI controller pods run in the driver's management namespace (typically openshift-cluster-csi-drivers or the operator's namespace), so reviewing that pod's logs reveals the detailed backend error messages.

Exam trap

EX280 often tests the misconception that generic node logs or diagnostics commands contain CSI provisioner errors, when the detailed backend error is only in the external-provisioner sidecar container logs.

How to eliminate wrong answers

Option A is wrong because 'oc adm diagnostics storage' runs general cluster storage health checks and does not surface the external provisioner's per-request error output. Option B is wrong because the container image registry is unrelated to CSI volume provisioning; its logs contain image push/pull events, not storage backend errors. Option D is wrong because /var/log/messages on control plane nodes contains kubelet and system daemon logs, not the CSI provisioner sidecar's application logs, which are captured by the container runtime and accessible via oc logs.

Full explanation →

374

Multi-Selectmedium

An administrator is reviewing the default Security Context Constraints in OpenShift 4.14+. Which THREE of the following SCCs are built-in and provided out-of-the-box by OpenShift? (Choose THREE)

Select 3 answers

A.root-container-v1

B.custom-app-scc

C.nonroot

D.restricted-v2

E.privileged

AnswersC, D, E

The nonroot SCC ensures pods run as a non-root UID without restricting capabilities as heavily as restricted.

Why this answer

Option C (nonroot) is correct because OpenShift ships a built-in nonroot SCC that allows pods to run as any non-root UID while still restricting privileged access, and it is part of the default SCC set. Option D (restricted-v2) is correct because it is the default SCC assigned to authenticated users in OpenShift 4.14+, replacing the older restricted SCC with stricter seccomp and capability requirements. Option E (privileged) is correct because the privileged SCC is a built-in SCC that allows full unrestricted host access and is provided out-of-the-box for system workloads.

Options A (root-container-v1) and B (custom-app-scc) are not built-in SCCs; they appear to be custom or fabricated names, and OpenShift does not provide them by default.

Exam trap

EX280 often tests whether candidates can distinguish built-in SCCs from custom ones; the trap is selecting plausible-sounding names like 'root-container-v1' or 'custom-app-scc' that are not actually shipped by OpenShift.

Full explanation →

375

MCQeasy

Which OpenShift CLI command is used to display all PersistentVolumeClaims in the current project along with their bound PersistentVolumes and storage classes?

A.oc get pvc

B.oc get pv

C.oc get sc

D.oc describe volume

AnswerA

Running oc get pvc lists every PersistentVolumeClaim in the current project, and its default output columns include the bound volume name and storage class, satisfying the requirement to show claims alongside their PersistentVolumes and storage classes without extra flags.

Why this answer

'oc get pvc' lists all PersistentVolumeClaims in the current project, and its default output includes the STATUS, VOLUME (the bound PV name), CAPACITY, ACCESS MODES, and STORAGECLASS columns. This single command gives the administrator the PVC-to-PV-to-StorageClass mapping requested.

Exam trap

The trap here is confusing the resource scopes: candidates may pick 'oc get pv' because PVs are the backing objects, but the question specifically asks for PVCs in the current project — 'oc get pvc' is the namespaced command that shows the PVC, its bound PV, and its StorageClass in one view.

How to eliminate wrong answers

Option B is wrong because 'oc get pv' lists PersistentVolumes (cluster-scoped) and shows which PVC claims them, but it does not enumerate PVCs by project and is not the direct answer to 'display all PVCs in the current project'. Option C is wrong because 'oc get sc' lists StorageClasses only — it shows provisioner and reclaim policy but no PVC or PV binding information. Option D is wrong because 'oc describe volume' is not a valid oc subcommand; volume inspection is done via 'oc describe pvc <name>' or 'oc get pvc'.

Full explanation →

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