Knowledge + Practice

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

414 questions total · 6 pages · All types, answers revealed

Take a mock exam Exam hub

Page 1 of 6

1

MCQeasy

Which component in OpenShift 4.14 manages the creation and deletion of compute machines (VMs or physical servers) on cloud providers or bare metal?

A.Operator Lifecycle Manager

B.Machine Config Operator

C.Cluster Version Operator

D.Machine API Operator

AnswerD

The Machine API Operator reconciles MachineSet and Machine objects, driving cloud provider or bare-metal actuators to create and delete compute nodes. It satisfies the stem's requirement for automated lifecycle management of VMs and physical servers, unlike Cluster Version Operator or control-plane operators, which handle updates and masters respectively.

Why this answer

The Machine API Operator manages the lifecycle of compute machines (VMs or physical servers) by creating and deleting Machine objects, which are backed by cloud provider or bare metal integrations. It runs in the openshift-machine-api namespace and works with the Cluster API to provision nodes.

Exam trap

EX280 often tests the roles of different operators, and candidates might confuse the Machine API Operator with the Machine Config Operator, which handles node configuration, not provisioning.

How to eliminate wrong answers

Option A is wrong because Operator Lifecycle Manager (OLM) manages the installation and upgrade of operators, not the creation of machines. Option B is wrong because the Machine Config Operator manages the configuration of nodes (e.g., kubelet, container runtime), not their provisioning. Option C is wrong because the Cluster Version Operator manages cluster version updates, not machine lifecycle.

Full explanation →

2

Multi-Selectmedium

An administrator is preparing to grant a ServiceAccount named 'reporter-sa' in the 'monitoring' namespace read-only access to pods and services across all namespaces in the cluster. Which TWO actions should the administrator take? (Choose two.)

Select 2 answers

A.Assign the 'cluster-admin' ClusterRole to 'reporter-sa' to guarantee visibility into all namespaces.

B.Ensure the ServiceAccount subject in the binding specifies the name 'reporter-sa' and the namespace 'monitoring'.

C.Create a ClusterRoleBinding that binds the 'view' ClusterRole to the 'reporter-sa' ServiceAccount in the 'monitoring' namespace.

D.Add the 'reporter-sa' ServiceAccount to the 'system:authenticated' group to inherit read access.

E.Create a RoleBinding in each namespace that binds the 'view' ClusterRole to 'reporter-sa'.

AnswersB, C

ServiceAccount subjects in RBAC bindings must include both the name and the namespace because ServiceAccount names are only unique within a namespace. Specifying 'reporter-sa' with namespace 'monitoring' ensures the binding matches the intended identity and not a same-named account elsewhere.

Why this answer

Cluster-wide read access for a ServiceAccount is achieved with a ClusterRoleBinding to the 'view' ClusterRole, with the subject identifying both the ServiceAccount name and its namespace. Together these two actions grant the required permissions across all namespaces while keeping the account read-only and avoiding per-namespace maintenance.

Exam trap

The trap here is thinking a ServiceAccount subject needs only a name, when RBAC requires the namespace as well because ServiceAccount names are namespace-scoped.

Full explanation →

3

MCQhard

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

A.oc adm diagnostics ovs

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

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

D.oc rsh daemonset/ovnkube-node

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

4

MCQeasy

Which component in OpenShift 4.14 is responsible for orchestrating the upgrade of the entire cluster from one minor version to another?

A.Machine Config Operator (MCO)

B.Cluster Version Operator (CVO)

C.Cluster Infrastructure Operator (CIO)

D.Operator Lifecycle Manager (OLM)

AnswerB

The Cluster Version Operator continuously reconciles the cluster's desired OpenShift version against its actual state, driving the minor-version upgrade orchestration. It satisfies the stem's requirement for the component responsible for orchestrating the entire cluster upgrade, coordinating ClusterOperators through the release image.

Why this answer

The Cluster Version Operator (CVO) is the OpenShift component responsible for orchestrating cluster upgrades. It watches the ClusterVersion custom resource, fetches the desired release payload from the release image, and coordinates the upgrade of all cluster operators in the correct order. The CVO ensures that each operator reaches its target version before proceeding, providing a controlled, verifiable upgrade path.

Exam trap

EX280 often tests the confusion between the CVO (orchestrates upgrades) and the MCO (applies node configuration), tricking candidates into selecting the MCO when the question asks about cluster-wide upgrade orchestration.

How to eliminate wrong answers

Option A is wrong because the Machine Config Operator (MCO) manages node-level configuration (MachineConfig objects, kubelet settings, systemd units) and applies them via rolling reboots — it is a consumer of the upgrade, not the orchestrator. Option C is wrong because there is no 'Cluster Infrastructure Operator (CIO)' in OpenShift — this is a fabricated name; infrastructure components are managed by operators like the Cluster Infrastructure Operator for cloud provider integration, but it does not orchestrate upgrades. Option D is wrong because Operator Lifecycle Manager (OLM) manages the lifecycle of add-on operators installed via OperatorHub (install, upgrade, RBAC), not the core cluster upgrade.

Full explanation →

5

Multi-Selecteasy

Which THREE of the following actions can a user with the default OpenShift 'view' role perform within a project? (Choose THREE)

Select 3 answers

A.Delete PersistentVolumeClaims

B.View ConfigMaps

C.Modify RoleBindings within the project

D.List and read Pods

E.View Deployments and Services

AnswersB, D, E

Viewing ConfigMaps is permitted because the default OpenShift `view` role grants read-only access to most project-scoped resources, excluding Secrets and role bindings. ConfigMaps hold non-sensitive configuration data, so read access aligns with the role's constraint of allowing inspection without permitting modification or exposure of credentials.

Why this answer

The default OpenShift 'view' role is a ClusterRole aggregated to grant read-only access to most project-scoped resources, so option B (View ConfigMaps) is correct because ConfigMaps are readable via get/list/watch verbs under the view role. Option D (List and read Pods) is correct because the view role includes get, list, and watch on pods and pod logs. Option E (View Deployments and Services) is correct because the view role grants read access to Deployments, Services, and other workload/networking resources in the project.

Option A (Delete PersistentVolumeClaims) is incorrect because delete is a write verb not granted by the view role; that requires edit or admin. Option C (Modify RoleBindings within the project) is incorrect because managing RoleBindings requires admin-level permissions, not the read-only view role.

Exam trap

EX280 often tests the exact boundaries of default roles, so candidates must remember that 'view' is strictly read-only and cannot delete PVCs or modify RoleBindings.

Full explanation →

6

MCQmedium

What is the primary difference between a Deployment and a DeploymentConfig in OpenShift?

A.Deployments support triggers, DeploymentConfigs do not

B.Deployments can be scaled, DeploymentConfigs cannot

C.DeploymentConfigs are OpenShift-specific

D.DeploymentConfigs do not support rollbacks

AnswerC

DeploymentConfigs are an OpenShift-specific resource, absent from upstream Kubernetes, whereas Deployments are the native Kubernetes workload API. This distinction satisfies the stem's request for the primary difference: DeploymentConfigs rely on OpenShift's ImageStream triggers and custom rollout logic, while Deployments use standard Kubernetes controllers.

Why this answer

DeploymentConfigs are a legacy OpenShift-specific resource that predates native Kubernetes Deployments. They are not part of upstream Kubernetes and are only available in OpenShift, whereas Deployments are a standard Kubernetes API resource. This is the primary architectural difference: DeploymentConfigs rely on OpenShift's ImageStreams and custom rollout logic, while Deployments use ReplicaSets and the standard Kubernetes deployment controller.

Exam trap

EX280 often tests the misconception that DeploymentConfigs are simply a newer or enhanced version of Deployments, when in fact they are legacy OpenShift-specific resources that lack native Kubernetes compatibility.

How to eliminate wrong answers

Option A is wrong because Deployments do not support OpenShift-style triggers (ImageChange, ConfigChange); triggers are a feature of DeploymentConfigs. Option B is wrong because both Deployments and DeploymentConfigs can be scaled; scaling is a fundamental capability of both resource types. Option D is wrong because DeploymentConfigs do support rollbacks via `oc rollout undo`, just as Deployments do with `kubectl rollout undo`.

Full explanation →

7

Multi-Selecthard

An administrator is troubleshooting a custom MachineConfig that failed to apply across a worker MachineConfigPool. Which THREE diagnostic steps or resources should the administrator check? (Choose THREE)

Select 3 answers

A.Check the Cluster Version Operator logs for container registry pull errors.

B.Review the logs of the machine-config-daemon pods on the affected nodes.

C.Verify the OLM CatalogSource status.

D.Check the MachineConfigPool status conditions for Degraded or Updating status.

E.Inspect the rendered MachineConfig object generated by the MCO.

AnswersB, D, E

The machine-config-daemon runs on each node and applies the rendered config locally. Its pod logs record the exact failure—ignition parse errors, file conflicts, or reboot issues—on affected worker nodes, pinpointing why the custom MachineConfig did not apply.

Why this answer

To diagnose MachineConfig application failures, check pool status conditions, machine-config-daemon pod logs, and rendered MachineConfigs.

Full explanation →

8

MCQmedium

You need to update an application without downtime. Which deployment strategy is most appropriate?

A.Canary

B.Blue-Green

C.Recreate

D.Rolling

AnswerD

Rolling updates replace instances incrementally, so a subset of pods remains available to serve traffic throughout the rollout. This satisfies the no-downtime constraint by keeping the application reachable while new versions are progressively introduced and old ones retired, provided readiness probes and sufficient replicas are configured.

Why this answer

Rolling deployment is the most appropriate strategy for updating an application without downtime because it incrementally replaces old pods with new ones, ensuring that a portion of the application remains available throughout the update. This is the default deployment strategy in OpenShift (and Kubernetes), and it maintains service continuity by scaling down the old ReplicaSet while scaling up the new one, with configurable parameters like maxUnavailable and maxSurge to control the pace. Unlike other strategies, rolling updates do not require additional infrastructure or complex traffic routing, making it the standard choice for zero-downtime updates in OpenShift.

Exam trap

EX280 often tests the distinction between deployment strategies, and candidates frequently confuse rolling updates with blue-green or canary, assuming those are required for zero-downtime, when in fact rolling is the default and simplest method in OpenShift.

How to eliminate wrong answers

Option A is wrong because canary deployments, while they minimize risk by routing a small percentage of traffic to the new version, require advanced traffic management (e.g., service mesh or ingress controllers) and are not the default or simplest method for zero-downtime updates in OpenShift. Option B is wrong because blue-green deployments require double the resources (two full environments) and a mechanism to switch traffic instantly, which is more complex and costly than necessary for a typical update. Option C is wrong because recreate strategy stops all old pods before starting new ones, causing guaranteed downtime, which directly contradicts the requirement.

Full explanation →

9

MCQmedium

An administrator wants to check the health and availability status of all core OpenShift 4.14 cluster operators (such as authentication, ingress, and dns). Which command should be used?

A.oc get csv

B.oc get operators --all-namespaces

C.oc adm cluster-health

D.oc get clusteroperators

AnswerD

`oc get clusteroperators` queries the ClusterOperator resources directly, returning each operator's AVAILABLE, PROGRESSING and DEGRADED conditions. This satisfies the stem's requirement to check health and availability across all core operators, including authentication, ingress and dns, in one cluster-scoped listing.

Why this answer

In OpenShift 4.x, cluster operators are managed by the Cluster Version Operator and their health is exposed via the clusteroperators resource. Running oc get clusteroperators (or oc get co) lists each operator with AVAILABLE, PROGRESSING, and DEGRADED status columns, which is exactly what the administrator needs to check core operator health.

Exam trap

EX280 often tests the difference between clusteroperators (core OpenShift operators managed by CVO) and CSVs (OLM-managed operators) — candidates pick oc get csv because it also lists 'operators', but those are user-installed OLM operators, not core cluster operators.

How to eliminate wrong answers

Option A is wrong because oc get csv lists ClusterServiceVersions, which are OLM-managed operator bundles in a namespace, not the core OpenShift cluster operators. Option B is wrong because oc get operators is not a valid resource type — the correct resource is clusteroperators (or co). Option C is wrong because oc adm cluster-health is not a real subcommand; health is checked via oc get clusteroperators or oc adm top.

Full explanation →

10

Multi-Selecteasy

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

Select 2 answers

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

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

C.oc get clusterversion --warnings

D.oc logs --warnings

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

AnswersA, B

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

Why this answer

Option B, `oc get events --field-selector type=Warning`, is correct because the `--field-selector` flag on `oc get events` filters the returned Event objects server-side by their `type` field, and `Warning` is the exact value used for warning-type events in Kubernetes/OpenShift. Option A, `oc describe pod <pod-name>`, is correct because `describe` renders the pod's status and appends the related Events section, which surfaces recent warning events (e.g., FailedScheduling, BackOff) tied to that specific pod. Option C, `oc get clusterversion --warnings`, is not a valid flag for that command and does not filter events by type.

Option D, `oc logs --warnings`, is invalid because `oc logs` streams container logs and has no `--warnings` flag. Option E, `oc adm must-gather --warnings-only`, is not a real flag; must-gather collects diagnostic data and does not filter events by warning type.

Exam trap

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

Full explanation →

11

MCQeasy

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

A.oc logs pod/my-pod backend

B.oc rsh pod/my-pod backend

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

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

AnswerD

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

Why this answer

`oc logs pod/my-pod -c backend` uses the `-c` flag to specify the container name 'backend' within a multi-container pod, which is the correct syntax to retrieve that container's logs. Without `-c`, oc logs would default to the first container or error out, so the flag is required.

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

12

MCQmedium

A developer deploys an application that mounts a PVC in read-only mode inside the pod specification. How is this configured in the Pod's volumeMounts?

A.Set accessModes to ReadOnlyMany on the PVC object.

B.Set readOnly: true in the container's volumeMounts entry.

C.Set volumeMode: ReadOnly in the PVC spec.

D.Annotate the PVC with 'volume.beta.kubernetes.io/readonly'.

AnswerB

Setting `readOnly: true` on the container's `volumeMounts` entry enforces read-only access at the mount point, satisfying the stem's requirement that the PVC be mounted read-only inside the pod. This is the per-container mount flag, distinct from the PersistentVolumeClaim's own access modes, which govern node-level attachment rather than filesystem writability.

Why this answer

Read-only mounting of a PVC inside a pod is set per-container via `readOnly: true` in the volumeMounts entry. This tells the kubelet to mount the volume read-only for that container, regardless of the PVC's access modes.

Exam trap

EX280 often tests whether candidates confuse PVC accessModes (volume capability) with the per-container volumeMounts.readOnly flag (mount behavior), leading them to pick ReadOnlyMany incorrectly.

How to eliminate wrong answers

Option A is wrong because accessModes (ReadOnlyMany) describe how the volume can be mounted by multiple nodes, not whether a specific container mounts it read-only. Option C is wrong because volumeMode is either Filesystem or Block, not ReadOnly. Option D is wrong because there is no such annotation `volume.beta.kubernetes.io/readonly` — it is fabricated.

Full explanation →

13

MCQhard

An administrator needs to roll back a Deployment in OpenShift to a specific previous revision because the latest update introduced a critical database connection bug. Which command identifies the available revisions and their associated change causes before executing the rollback?

A.oc get replicasets --selector=app=my-app

B.oc get deployment/<deployment-name> -o yaml

C.oc describe deploymentconfig <deployment-config-name>

D.oc rollout history deployment/<deployment-name>

AnswerD

'oc rollout history' displays all recorded revisions for a deployment along with their change causes.

Why this answer

The `oc rollout history deployment/<deployment-name>` command is specifically designed to display the revision history of a Deployment, including the revision number and the change cause (the reason for each rollout). This allows the administrator to identify which revision to roll back to before executing `oc rollout undo deployment/<deployment-name> --to-revision=<n>`. It directly addresses the need to see available revisions and their associated change causes.

Exam trap

EX280 often tests the distinction between Deployments and DeploymentConfigs, and candidates may mistakenly choose `oc describe deploymentconfig` or `oc get replicasets` thinking they show revision history, but only `oc rollout history` provides the ordered revisions with change causes for Deployments.

How to eliminate wrong answers

Option A is wrong because `oc get replicasets --selector=app=my-app` lists ReplicaSets but does not show revision numbers or change causes in a directly usable format for rollback; while ReplicaSets are created per revision, the output lacks the ordered history and change-cause annotations that `oc rollout history` provides. Option B is wrong because `oc get deployment/<deployment-name> -o yaml` dumps the full Deployment configuration, which includes only the current revision and metadata, not a list of previous revisions or their change causes. Option C is wrong because `oc describe deploymentconfig <deployment-config-name>` is for DeploymentConfigs (the older OpenShift-specific resource), not Deployments (the standard Kubernetes resource); the question explicitly refers to a Deployment, and using the wrong resource type would fail or show irrelevant information.

Full explanation →

14

Multi-Selectmedium

Which TWO characteristics describe StorageClasses in OpenShift?

Select 2 answers

A.They specify the provisioner plugin responsible for creating volumes.

B.They store the actual application data files.

C.They are namespace-scoped and unique to each project.

D.They can only be created by unprivileged developer users.

E.They are cluster-scoped resources.

AnswersA, E

Each StorageClass names a provisioner plugin, such as a CSI driver, that dynamically creates the underlying volume when a PVC references it. This provisioner field is what determines which storage backend fulfils the claim, satisfying the characteristic described.

Why this answer

Option A is correct because a StorageClass defines the provisioner field (for example kubernetes.io/aws-ebs, ebs.csi.aws.com, or a custom CSI driver) that tells OpenShift which plugin dynamically creates the PersistentVolume backing a PVC. Option E is correct because StorageClasses are cluster-scoped resources, not namespaced, so they are visible across all projects and can be referenced by PVCs in any namespace. Options B, C, and D are incorrect: StorageClasses do not hold application data (that resides on the PersistentVolume), they are not namespace-scoped or project-unique, and creating them typically requires cluster-admin privileges rather than unprivileged developer access.

Exam trap

EX280 often tests the misconception that StorageClasses are namespace-scoped, but they are cluster-scoped, and candidates must also remember that they define provisioners, not store data.

Full explanation →

15

Multi-Selectmedium

An administrator is investigating why cluster operator upgrades are failing. Which TWO locations or commands provide detailed diagnostic information about cluster operators? (Choose TWO)

Select 2 answers

A.Run 'oc describe clusteroperator <operator-name>' to inspect status conditions and messages.

B.Check the global DNS configuration map in the default namespace.

C.Inspect the logs of the operator's controller pods running in their respective namespaces.

D.Run 'oc adm cluster-operator-reset --all'.

E.Inspect the MachineConfigPool status conditions for OLM errors.

AnswersA, C

The clusteroperator resource exposes status conditions, reasons and messages recording why an operator cannot progress its upgrade. Describing it surfaces the specific blocking condition, giving the administrator the diagnostic detail the failing upgrade investigation requires.

Why this answer

Option A is correct because 'oc describe clusteroperator <operator-name>' surfaces the ClusterOperator object's status.conditions, including Available, Progressing, Degraded, and their human-readable messages, which directly reveal why an upgrade is stuck or failing. Option C is correct because the actual controller pods (for example, the cluster-version-operator pod in openshift-cluster-version or an operator's own controller pods in its namespace) emit detailed logs that explain reconciliation errors, failed image pulls, or API conflicts behind the conditions. Option B is wrong because the DNS configuration map in the default namespace only holds cluster DNS settings and has nothing to do with operator upgrade diagnostics.

Option D is wrong because 'oc adm cluster-operator-reset --all' is not a valid diagnostic command and would not report operator status. Option E is wrong because MachineConfigPool status conditions report node configuration rollout state, not OLM or cluster operator errors.

Exam trap

EX280 often tests the misconception that generic cluster resources like DNS ConfigMaps or MachineConfigPools provide operator diagnostics, when in fact the ClusterOperator resource and operator pod logs are the correct sources.

Full explanation →

16

MCQhard

An administrator needs to perform a canary deployment strategy using standard OpenShift Deployment resources (not DeploymentConfigs). What is the standard Kubernetes/OpenShift native mechanism to route a small percentage of traffic to the canary deployment?

A.Setting the traffic-split annotation on the Deployment resource

B.Using an OpenShift Route with weighted backend services pointing to stable and canary Services

C.Configuring weight parameters directly in the Deployment spec rollingUpdate strategy

D.Enabling canary mode in the ImageStream tag metadata

AnswerB

An OpenShift Route supports `alternateBackends` with integer weights, splitting traffic between stable and canary Services without extra tooling. This satisfies the stem's native-mechanism constraint for standard Deployments, since both Services select pods by label and the Route itself performs the percentage split.

Why this answer

OpenShift Routes support weighted backends via the 'alternateBackends' field with a 'weight' value, allowing a single Route to split traffic between a stable Service and a canary Service. This is the native mechanism for canary traffic splitting without a service mesh, and it works with standard Deployments behind each Service.

Exam trap

EX280 often tests whether candidates assume Deployments themselves can split traffic, missing that OpenShift Routes (or a service mesh) are the actual traffic-splitting layer.

How to eliminate wrong answers

Option A is wrong because there is no 'traffic-split' annotation on Deployment resources — Deployments have no concept of traffic weighting. Option C is wrong because the rollingUpdate strategy controls pod replacement (maxSurge/maxUnavailable), not traffic percentages, and it cannot route a fraction of requests to a separate canary. Option D is wrong because ImageStream tag metadata (e.g., 'importPolicy', 'referencePolicy') governs image resolution and triggers, not traffic routing.

Full explanation →

17

MCQeasy

An ImageStream named 'frontend' in a project contains multiple tags, including 'latest' and 'v1.0'. You want to update an existing Deployment to specifically use the 'v1.0' tag of this ImageStream. Where must this reference be updated in the Deployment specification?

A.In the spec.imageStreamRef field.

B.In the metadata.annotations['openshift.io/image.in-cluster'] field.

C.In the spec.template.spec.containers[].image field pointing to image-registry.openshift-image-registry.svc:5000/namespace/frontend:v1.0.

D.In the spec.strategy.rollingUpdate.image field.

AnswerC

The container image field is where OpenShift resolves an ImageStream tag to a pullable reference, so pinning spec.template.spec.containers[].image to the internal registry path with the v1.0 tag satisfies the requirement to use that specific tag.

Why this answer

In OpenShift, an ImageStream tag is consumed by referencing the internal registry image path in the container's image field. The correct form is image-registry.openshift-image-registry.svc:5000/<namespace>/<imagestream>:<tag>, which the kubelet resolves through the internal registry and the ImageStream tag. Updating spec.template.spec.containers[].image to this fully qualified reference with the v1.0 tag ensures the Deployment pulls that specific tag.

Exam trap

EX280 often tests whether candidates know the exact internal registry path format and that ImageStream tags are consumed through the container image field, not a fictitious imageStreamRef field.

How to eliminate wrong answers

Option A is wrong because spec.imageStreamRef is not a valid field in a Pod/Deployment container spec; ImageStream references are resolved via the image field, not a dedicated ref field. Option B is wrong because metadata.annotations['openshift.io/image.in-cluster'] is not a real annotation used to select ImageStream tags. Option D is wrong because spec.strategy.rollingUpdate.image does not exist; the rollingUpdate strategy only accepts maxSurge and maxUnavailable.

Full explanation →

18

MCQeasy

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

A.oc whoami

B.oc user-info

C.oc auth current-user

D.oc get user --current

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

19

MCQmedium

You need to ensure that your application deployment always maintains at least 80% of its desired pod count during a rolling update. Which strategy parameter should you configure?

A.maxUnavailable: 20%

B.minReadySeconds: 20

C.maxSurge: 20%

D.rollingUpdatePeriod: 20%

AnswerA

Setting `maxUnavailable: 20%` in the rolling update strategy guarantees that no more than 20% of desired pods are unavailable at any moment, leaving at least 80% running. This directly satisfies the stem's requirement to maintain a minimum of 80% of the desired pod count throughout the deployment.

Why this answer

In a rolling update strategy, maxUnavailable defines the maximum number of Pods that can be unavailable during the update. Setting maxUnavailable: 20% ensures that at least 80% of the desired Pod count remains available at all times, satisfying the requirement. This parameter directly controls the availability floor during the rollout.

Exam trap

EX280 often tests the difference between maxUnavailable (availability floor) and maxSurge (extra capacity), so candidates must not confuse the two when the question asks for maintaining a minimum percentage of Pods.

How to eliminate wrong answers

Option B is wrong because minReadySeconds specifies how long a new Pod must be ready before it is considered available; it does not guarantee a minimum percentage of available Pods. Option C is wrong because maxSurge controls how many extra Pods can be created above the desired count, not how many must remain available. Option D is wrong because rollingUpdatePeriod is not a valid Kubernetes Deployment strategy parameter.

Full explanation →

20

Multi-Selectmedium

An administrator is troubleshooting an Operator installation issue in OpenShift 4.14. Which TWO resources or logs should the administrator examine to diagnose OLM operator subscription and CSV issues? (Choose TWO)

Select 2 answers

A.Review the MachineConfigPool status in openshift-machine-api.

B.Check the cluster-wide node storage provisioning logs.

C.Review the ClusterVersion resource status conditions.

D.Inspect the ClusterServiceVersion (CSV) status and conditions.

E.Inspect the Subscription object status in the target namespace.

AnswersD, E

The CSV reports the operator's phase and condition messages, exposing failures such as failed deployments, unmet RBAC or unsupported APIs. Inspecting its status pinpoints why the operator itself did not reach Succeeded, which the Subscription alone cannot show.

Why this answer

Option D is correct because the ClusterServiceVersion (CSV) is the OLM resource that represents a running operator; its status.phase (e.g., Succeeded, Failed, Pending) and status.conditions (such as InstallSucceeded, InstallReady, RequirementsUnknown) directly reveal why an operator install is failing, including dependency or RBAC problems. Option E is correct because the Subscription object in the target namespace tracks the operator's desired channel, installPlanApproval, and its status.conditions (e.g., CatalogSourcesUnhealthy, InstallPlanMissing, ResolutionFailed), which is the first place OLM records subscription resolution and upgrade errors. Option A is not relevant because MachineConfigPool status in openshift-machine-api reflects node configuration rollout, not OLM operator subscription or CSV state.

Option B is not relevant because node storage provisioning logs pertain to CSI/storage operators and PV binding, not to OLM subscription or CSV diagnostics. Option C is not relevant because the ClusterVersion resource reports OpenShift platform update status, not the health of individual operator subscriptions or CSVs.

Exam trap

EX280 often tests whether candidates confuse OLM operator diagnostics (Subscription and CSV) with unrelated platform resources like ClusterVersion or MachineConfigPool.

Full explanation →

21

MCQeasy

An administrator needs to completely remove a Helm release named my-redis from the cluster, including its history. Which Helm command should be executed?

A.helm remove my-redis

B.helm delete my-redis --purge

C.helm uninstall my-redis

D.helm drop my-redis

AnswerC

`helm uninstall my-redis` removes the release and, by default, deletes its release history from the cluster, satisfying the requirement to erase all records. Unlike `helm delete --keep-history`, which retains revision data for rollback, plain uninstall purges the release entirely, leaving no residual state.

Why this answer

The correct command to completely remove a Helm release and its history is helm uninstall my-redis. In Helm 3, uninstall replaces the delete command and removes the release and its history by default.

Exam trap

EX280 often tests Helm 3 command changes, so candidates must remember that 'helm uninstall' is the correct command, not 'helm delete' with '--purge' which is Helm 2 syntax.

How to eliminate wrong answers

Option A is wrong because helm remove is not a valid command; the correct verb is uninstall. Option B is wrong because helm delete my-redis --purge is Helm 2 syntax; in Helm 3, --purge is deprecated and delete is aliased to uninstall, but the standard command is uninstall. Option D is wrong because helm drop is not a valid command.

Full explanation →

22

MCQmedium

A developer needs to know if their pod's service account has permissions to create pods in another namespace named 'target-ns'. Which command can the developer run to check this?

A.oc auth can-i create pods -n target-ns

B.oc get rolebindings -n target-ns --user=self

C.oc check-permission create pods -n target-ns

D.oc describe authorization -n target-ns

AnswerA

oc auth can-i submits a SubjectAccessReview for the current service account against the specified verb and resource, honouring the -n flag to target 'target-ns'. It returns yes or no, directly answering whether pod creation is permitted there.

Why this answer

The 'oc auth can-i' command is the OpenShift-native way to perform a SelfSubjectAccessReview against the API server, returning yes or no for a specific verb/resource combination. Adding '-n target-ns' scopes the check to the target namespace, so the developer can verify whether their current service account or user can create pods there. This is the exact command documented for permission troubleshooting in OpenShift.

Exam trap

EX280 often tests whether candidates know the exact oc subcommand for permission checks — many confuse it with kubectl auth can-i syntax variants or invent plausible-sounding commands like 'oc check-permission' that do not exist.

How to eliminate wrong answers

Option B is wrong because 'oc get rolebindings' lists RoleBinding objects but does not evaluate effective permissions — the developer would have to manually trace subjects, roles, and cluster-scoped bindings, which is error-prone and does not account for ClusterRoleBindings. Option C is wrong because 'oc check-permission' is not a real oc subcommand; the correct verb is 'auth can-i'. Option D is wrong because 'oc describe authorization' is not a valid command — authorization is evaluated through SubjectAccessReview/SelfSubjectAccessReview APIs, surfaced via 'oc auth can-i'.

Full explanation →

23

MCQeasy

Where are PersistentVolumeClaims located in terms of OpenShift's API scope?

A.They are node-scoped resources.

B.They are namespaced resources.

C.They are global resources shared across all clusters in a fleet.

D.They are cluster-scoped resources.

AnswerB

PersistentVolumeClaims are namespaced resources, meaning each claim exists within a single project and is visible only to workloads in that namespace. This scoping satisfies OpenShift's API constraint that claims bind to storage within their own project boundary.

Why this answer

PersistentVolumeClaims (PVCs) are namespaced resources in OpenShift, meaning they exist within a specific project (namespace) and are scoped to that namespace. This allows different projects to have their own PVCs with the same name.

Exam trap

EX280 often tests the confusion between namespaced and cluster-scoped resources, and candidates may incorrectly think PVCs are cluster-scoped like PVs.

How to eliminate wrong answers

Option A is wrong because PVCs are not node-scoped; they are not tied to a specific node. Option C is wrong because PVCs are not global resources shared across clusters; they are limited to a single cluster and namespace. Option D is wrong because cluster-scoped resources are accessible across all namespaces, but PVCs are namespaced.

Full explanation →

24

MCQhard

A developer needs to mount an existing PersistentVolumeClaim into a pod, but the application requires that the volume be mounted read-only to prevent accidental writes. The PVC was created with accessMode ReadWriteOnce. Which configuration in the pod's volumeMounts is correct?

A.Set readOnly: true in the volumeMounts section for that volume.

B.Set readOnly: true in the PersistentVolume's spec.

C.Change the PVC's accessMode to ReadOnlyMany.

D.Set readOnly: true in the pod's volumes section for that volume.

AnswerA

The readOnly field in volumeMounts controls whether the volume is mounted read-only for that specific container. Even if the PVC was created with ReadWriteOnce, the pod can mount it read-only by setting readOnly: true. This enforces read-only access at the mount point, preventing writes from the container. It does not change the PVC's access mode, which remains ReadWriteOnce.

Why this answer

To mount a volume read-only in a pod, set readOnly: true in the volumeMounts entry for that volume within the container. This is independent of the PVC's access mode. The access mode governs how many nodes can mount the volume and whether they can write, but the pod-level readOnly flag enforces read-only at the mount point for that container.

Exam trap

The trap here is confusing the PVC access mode with the pod's volumeMount readOnly field; the access mode does not enforce read-only at the container level.

Full explanation →

25

MCQeasy

A service of type NodePort has been created in OpenShift. Within what default port range are NodePort services typically allocated on the worker nodes?

A.30000-32767

B.50000-60000

C.1024-65535

D.80-443

AnswerA

OpenShift allocates NodePort services from the 30000-32767 range by default, exposing each service on every worker node's IP at that port. This range is configurable via the service-node-port-range parameter, but 30000-32767 remains the standard default.

Why this answer

By default, Kubernetes and OpenShift allocate NodePort services from the range 30000-32767. This range is configurable at the cluster level, but the default is standardized. NodePort services expose the service on each node's IP at that port, allowing external access.

Exam trap

EX280 often tests the default NodePort range, and candidates may confuse it with the ephemeral port range or the full non-privileged port range.

How to eliminate wrong answers

Option B is wrong because 50000-60000 is not the default NodePort range; it might be used for other purposes but not standard. Option C is wrong because 1024-65535 is the entire range of non-privileged ports, not the specific default for NodePort. Option D is wrong because 80-443 are privileged ports used for HTTP/HTTPS, not NodePort allocations.

Full explanation →

26

MCQhard

An administrator is troubleshooting a node that is reporting `NotReady` in an OpenShift cluster. The administrator runs `oc get nodes` and sees the node's status as `NotReady,SchedulingDisabled`. Which command should the administrator use to view the node's conditions and determine the specific reason for the NotReady state?

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

B.oc adm top node <node-name>

C.oc describe node <node-name>

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

AnswerC

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

Why this answer

When a node is NotReady, the most efficient way to see why is to inspect its conditions. The oc describe node command presents these conditions in a readable format, including the Ready condition's status, reason, and message, along with any taints and recent events. This allows the administrator to quickly pinpoint issues like kubelet not posting status or network plugin problems.

Exam trap

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

Full explanation →

27

MCQmedium

An administrator needs to inspect the current update channel and version of an OpenShift 4.14 cluster. Which command provides this status directly?

A.oc version --cluster

B.oc get nodes --version

C.oc get clusterversion

D.oc describe operator cluster

AnswerC

`oc get clusterversion` queries the ClusterVersionOperator's custom resource, returning the cluster's current version and its `spec.channel` update channel directly. This satisfies the stem's requirement to inspect both update channel and version on the 4.14 cluster without additional flags or resource lookups.

Why this answer

The `oc get clusterversion` command retrieves the ClusterVersion custom resource, which contains the cluster's current version and update channel. This resource is the authoritative source for OpenShift update status, including available updates and the desired channel. It directly answers the administrator's need to inspect both the update channel and version.

Exam trap

EX280 often tests the distinction between commands that show component versions (like `oc version`) and those that reveal the cluster's update channel and version, so candidates may mistakenly choose `oc version --cluster` assuming it provides cluster-wide version details.

How to eliminate wrong answers

Option A is wrong because `oc version --cluster` is not a valid command; `oc version` displays client and server versions but does not show the update channel. Option B is wrong because `oc get nodes --version` is invalid syntax; `oc get nodes` lists nodes but does not provide cluster version or channel information. Option D is wrong because `oc describe operator cluster` is not a valid command; operators are managed via `oc get clusteroperators`, and this does not directly show the cluster version or update channel.

Full explanation →

28

MCQmedium

An administrator needs to restrict ingress traffic to pods in the 'frontend' namespace so that only pods labeled role=api in the 'backend' namespace can connect on TCP port 8080. All other traffic must be denied. Which NetworkPolicy configuration achieves this?

A.A NetworkPolicy in the frontend namespace with podSelector matching app=web, ingress from namespaceSelector matching name=backend and podSelector matching role=api, and ports TCP 8080.

B.A NetworkPolicy in the frontend namespace with podSelector matching app=web and ingress from ipBlock 10.0.0.0/8 on TCP 8080.

C.A NetworkPolicy in the backend namespace with podSelector matching role=api and egress to namespaceSelector matching name=frontend and port TCP 8080.

D.A NetworkPolicy in the frontend namespace with podSelector matching app=web and ingress from namespaceSelector matching name=backend without specifying ports.

AnswerA

This policy selects the target pods via podSelector, allows ingress only from pods in the backend namespace that also have the role=api label, and restricts to TCP 8080. Because NetworkPolicy is additive and any pod selected by at least one policy has all non-allowed traffic denied, this correctly enforces the restriction.

Why this answer

A NetworkPolicy must be created in the namespace of the pods it protects (frontend) and use podSelector to select those pods. The ingress rule must combine namespaceSelector and podSelector to allow only pods in backend with role=api, and specify the port TCP 8080. Once any policy selects the frontend pods, all other ingress is denied by default.

Exam trap

The trap here is placing the policy in the source namespace or using ipBlock instead of label selectors, which fails to restrict traffic based on pod identity.

Full explanation →

29

MCQmedium

A cluster administrator wants to grant a group of users read access to all Pod logs across every namespace in the cluster. Which ClusterRole and binding approach should be used?

A.ClusterRole with apiGroups: [''], resources: ['pods/log'], verbs: ['get'] bound via ClusterRoleBinding

B.RoleBinding in each individual namespace pointing to the 'view' ClusterRole

C.SecurityContextConstraints modification

D.ClusterRole with apiGroups: ['apps'], resources: ['deployments/scale'], verbs: ['get']

AnswerA

pods/log is a subresource, so the ClusterRole must specify resources: ['pods/log'] with verb get, and a ClusterRoleBinding grants it cluster-wide across all namespaces. A RoleBinding would restrict access to one namespace, failing the every-namespace requirement.

Why this answer

To grant read access to pod logs across all namespaces, you need a ClusterRole that grants 'get' on the 'pods/log' subresource in the core API group, bound with a ClusterRoleBinding to the target group. The ClusterRoleBinding ensures the permission applies cluster-wide rather than in a single namespace. This is the canonical RBAC pattern for cross-namespace log access.

Exam trap

EX280 often tests the confusion between RoleBinding and ClusterRoleBinding — candidates must recognize that cluster-wide access requires a ClusterRoleBinding, and that 'pods/log' is a separate subresource from 'pods'.

How to eliminate wrong answers

Option B is wrong because RoleBindings are namespace-scoped — you would need to create one in every namespace, which is operationally fragile and does not scale; a ClusterRoleBinding is the correct cluster-wide mechanism. Option C is wrong because SecurityContextConstraints govern pod security contexts, not log access, and have nothing to do with RBAC permissions on the pods/log subresource. Option D is wrong because it targets the 'apps' API group and the 'deployments/scale' subresource, which controls deployment scaling, not pod log retrieval.

Full explanation →

30

MCQhard

An OpenShift administrator needs to restrict external access to a specific application Route by limiting access to a predefined list of allowed client IP addresses. How can this be accomplished?

A.Configure spec.clientIP in the Service object definition.

B.Create a NetworkPolicy with spec.ingress.ipBlock restricting the router pod.

C.Add the annotation 'haproxy.router.openshift.io/ip_whitelist' to the Route object.

D.Update the IngressController CR with a global clientIP blacklist.

AnswerC

The haproxy.router.openshift.io/ip_whitelist annotation is read by the HAProxy router and enforces an allow-list of client source IPs at the edge, rejecting all others before traffic reaches the application. This directly satisfies the requirement to restrict external Route access to a predefined set of addresses.

Why this answer

The annotation 'haproxy.router.openshift.io/ip_whitelist' on a Route object instructs the HAProxy router to allow only the specified client IP addresses (or CIDR ranges) to access that route. This is the standard OpenShift method for per-route IP whitelisting without affecting other routes or the entire router. The annotation is processed by the router's HAProxy configuration, which adds ACL rules to enforce the whitelist.

Exam trap

EX280 often tests the difference between Route annotations and NetworkPolicy for access control, and candidates may incorrectly choose NetworkPolicy because it is a Kubernetes-native construct, but NetworkPolicy operates at the pod level and cannot easily target per-route client IPs.

How to eliminate wrong answers

Option A is wrong because Service objects do not have a spec.clientIP field; Kubernetes Services use spec.loadBalancerSourceRanges for load balancer IP restrictions, but that is not applicable to OpenShift Routes and does not restrict client IPs at the router level. Option B is wrong because NetworkPolicy with spec.ingress.ipBlock is not a valid field; NetworkPolicy uses ipBlock under ingress.from, but applying it to the router pod would restrict traffic to the router itself, not per-route client IPs, and would require complex pod selectors. Option D is wrong because the IngressController CR does not support a global clientIP blacklist; it manages router deployment settings, not per-route access control.

Full explanation →

31

MCQeasy

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

A.openshift-cluster-version

B.openshift-operator-lifecycle-manager

C.openshift-config-operator

D.kube-system

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

32

MCQmedium

What is the effect of setting 'allowVolumeExpansion: true' in a StorageClass?

A.It automatically shrinks PVCs when storage usage drops below 50%.

B.It permits users to increase the storage size of PVCs created from this StorageClass.

C.It allows multiple pods to write to an RWO volume simultaneously.

D.It allows the cluster to automatically scale the number of worker nodes based on storage demand.

AnswerB

The allowVolumeExpansion field on the StorageClass enables the CSI driver's resize capability, letting users edit a PVC's requested storage upward. Without it, the API server rejects PVC size increases, so this setting satisfies the requirement to permit growing volumes provisioned from that class.

Why this answer

Setting allowVolumeExpansion: true in a StorageClass allows users to increase the size of PVCs created from that StorageClass. This enables online expansion of volumes, provided the underlying storage provider supports it.

Exam trap

EX280 often tests the misconception that allowVolumeExpansion enables automatic scaling or shrinking, when it only permits manual expansion of PVCs.

How to eliminate wrong answers

Option A is wrong because volume expansion does not automatically shrink PVCs; shrinking is not supported. Option C is wrong because allowVolumeExpansion does not change the access mode; RWO volumes still allow only one pod to write. Option D is wrong because allowVolumeExpansion does not trigger node scaling; that is handled by the cluster autoscaler.

Full explanation →

33

MCQeasy

A developer has deployed a Helm chart in OpenShift and needs to list all currently installed Helm releases in the current namespace. Which command should be used?

A.helm get releases

B.helm status

C.helm search installed

D.helm list

AnswerD

`helm list` queries the Helm release storage backend (Kubernetes Secrets of type `helm.sh/release.v1` by default) and returns every release recorded in the active namespace, satisfying the requirement to enumerate installed releases. Adding `--all-namespaces` would broaden scope, but the stem restricts output to the current namespace.

Why this answer

The helm list command lists all Helm releases in the current namespace (or all namespaces with -A). It shows release name, namespace, revision, status, chart, and app version. This is the standard command to view installed releases.

Exam trap

EX280 often tests the confusion between helm list (list releases) and helm status (status of one release) or helm get (retrieve details of one release).

How to eliminate wrong answers

Option A is wrong because helm get releases is not a valid Helm command; helm get is used to get information about a specific release (e.g., helm get values). Option B is wrong because helm status shows the status of a single release, not a list of all releases. Option C is wrong because helm search installed is not a valid command; helm search is used to search for charts in repositories or Hub.

Full explanation →

34

MCQhard

An administrator must configure a NetworkPolicy in the 'secure-zone' namespace to explicitly deny all ingress traffic except for TCP traffic coming from pods labeled 'tier=frontend' in the 'frontend-zone' namespace. Which NetworkPolicy specification achieves this?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend namespace: secure-zone spec: podSelector: {} policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 10.128.0.0/14 ports: - protocol: TCP

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend namespace: secure-zone spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend-zone ports: - protocol: TCP

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend namespace: secure-zone spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend-zone podSelector: matchLabels: tier: frontend ports: - protocol: TCP

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend namespace: secure-zone spec: podSelector: {} policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: tier: frontend matchExpressions: - key: namespace operator: In values: [frontend-zone] ports: - protocol: TCP

AnswerC

An empty podSelector selects all pods in secure-zone, and policyTypes Ingress makes the policy default-deny. The single ingress rule permits TCP only from pods labelled tier=frontend in the frontend-zone namespace, satisfying the explicit allowlist constraint.

Why this answer

Option C is correct because it uses a single ingress rule with both a namespaceSelector matching the 'frontend-zone' namespace (via the automatic label kubernetes.io/metadata.name) and a podSelector matching pods with label tier=frontend. In Kubernetes NetworkPolicy, when multiple selectors are specified within the same 'from' element, they are ANDed together, meaning only pods that satisfy both conditions are allowed. The policy also sets podSelector: {} to apply to all pods in the secure-zone namespace, and policyTypes: [Ingress] to enforce the rule, effectively denying all other ingress traffic.

Exam trap

EX280 often tests the distinction between namespaceSelector and podSelector, and the fact that they must be combined in the same 'from' element to achieve an AND condition; candidates frequently mistakenly use only one selector or incorrectly try to match namespace labels with podSelector.

How to eliminate wrong answers

Option A is wrong because it uses an ipBlock with CIDR 10.128.0.0/14, which allows traffic from any pod in that IP range regardless of labels or namespace, not specifically from pods labeled tier=frontend in frontend-zone. Option B is wrong because it only uses a namespaceSelector for frontend-zone, which allows all pods in that namespace, not just those with the tier=frontend label. Option D is wrong because it attempts to use a podSelector with matchExpressions on a 'namespace' key, but podSelector only matches pod labels, not namespace labels; the namespace field is not a valid pod label, so this would not correctly select pods from the frontend-zone namespace.

Full explanation →

35

MCQhard

A cluster administrator needs to configure a generic ephemeral inline volume in a Pod specification. Where is the volume defined?

A.In the namespace ResourceQuota configuration.

B.In the StorageClass definition under the ephemeralTemplate field.

C.As a standalone PVC that is automatically annotated by the scheduler.

D.Directly in the Pod's spec.volumes array using the ephemeral volume source type.

AnswerD

Generic ephemeral inline volumes are declared within the Pod's own spec.volumes array using the ephemeral volume source, so the volume lifecycle is tied to the Pod. This satisfies the stem's requirement for where the volume is defined.

Why this answer

A generic ephemeral inline volume is defined directly in the Pod's spec.volumes array using the ephemeral volume source type. This allows the volume to be created and destroyed alongside the Pod, with the underlying storage managed by a PersistentVolumeClaim template embedded in the Pod spec. The ephemeral volume source references a volumeClaimTemplate that specifies the StorageClass and size, enabling dynamic provisioning without a separate PVC object.

Exam trap

EX280 often tests the distinction between persistent and ephemeral storage, and candidates may confuse generic ephemeral volumes with standalone PVCs or assume they are defined in StorageClass, leading to incorrect answers.

How to eliminate wrong answers

Option A is wrong because ResourceQuota is used to limit resource consumption in a namespace, not to define volumes. Option B is wrong because StorageClass definitions do not contain an ephemeralTemplate field; ephemeral volumes are defined in the Pod spec, not in the StorageClass. Option C is wrong because a standalone PVC is a separate resource and is not automatically annotated by the scheduler for ephemeral use; generic ephemeral volumes are inline and do not require a pre-created PVC.

Full explanation →

36

Multi-Selecteasy

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

Select 2 answers

A.The PersistentVolumeClaim is stuck in Pending.

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

C.The route hostname is invalid.

D.The liveness probe timeout is configured too short.

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

AnswersB, E

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

Why this answer

Option B is correct because image pulls from private registries require valid credentials, and if the imagePullSecret referenced by the pod's service account is missing or has wrong registry credentials, the kubelet will fail with ImagePullBackOff or ErrImagePull. Option E is correct because a typo in the image repository path or a nonexistent tag (e.g., myapp:v2 when only v1 exists) causes the registry to return a manifest-not-found error, which also surfaces as ImagePullBackOff. Option A does not belong because a Pending PVC affects volume mounting and pod scheduling, not the image pull phase.

Option C does not belong because an invalid route hostname is an OpenShift networking issue affecting external access, not kubelet image retrieval. Option D does not belong because a short liveness probe timeout causes container restarts after startup, not image pull failures.

Exam trap

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

Full explanation →

37

MCQmedium

An administrator wants members of the LDAP-backed group 'cn=auditors,ou=groups,dc=corp' to have read-only access to every project in the cluster, including future ones, without granting them any write capability. Which action achieves this?

A.Create a ClusterRoleBinding that binds the group to the 'edit' ClusterRole.

B.Create a RoleBinding in each namespace that binds the group to the 'view' ClusterRole.

C.Create a ClusterRoleBinding that binds the group to the 'cluster-admin' ClusterRole.

D.Create a ClusterRoleBinding that binds the group to the 'view' ClusterRole.

AnswerD

A ClusterRoleBinding grants the referenced ClusterRole across all namespaces, present and future, without per-project maintenance. Binding the LDAP group to the 'view' ClusterRole gives exactly read-only access cluster-wide, matching the requirement and avoiding any write verbs.

Why this answer

A ClusterRoleBinding to the 'view' ClusterRole is the correct mechanism because it applies cluster-wide and automatically covers namespaces created later. It grants only read verbs, satisfying the no-write constraint, and binding a group means all LDAP members inherit the access without per-user configuration.

Exam trap

The trap here is choosing a per-namespace RoleBinding for read access, forgetting that ClusterRoleBindings are what extend a ClusterRole's permissions to all current and future namespaces.

Full explanation →

38

MCQhard

You notice that your builds are failing due to a lack of memory. Where can you set resource limits for the build process?

A.In the BuildConfig resources field

B.In the LimitRange

C.In the project Quota

D.In the Deployment object

AnswerA

Setting `resources` in the BuildConfig lets you declare CPU and memory requests and limits for the build pod, so the scheduler reserves sufficient memory and the kubelet enforces the cap. This directly addresses the failing builds by guaranteeing the build container receives the memory it needs.

Why this answer

Build resource limits are configured in the `resources` field of the BuildConfig's `spec`, which is passed to the build pod that executes the build. This lets you cap CPU and memory for the build container so that memory-hungry builds (for example, large Maven or Node builds) don't get OOM-killed. The values follow standard Kubernetes resource requests/limits syntax.

Exam trap

EX280 often tests the misconception that namespace-level controls (LimitRange or ResourceQuota) are the right place to fix a specific build's memory problem, when the per-BuildConfig `resources` field is the direct answer.

How to eliminate wrong answers

Option B is wrong because a LimitRange sets default and min/max constraints for pods in a namespace but does not target the build process specifically and won't override a BuildConfig that needs higher limits. Option C is wrong because a project ResourceQuota caps aggregate namespace consumption and can cause builds to fail if exhausted, but it is not where you set per-build memory limits. Option D is wrong because the Deployment object governs the runtime application pods, not the build pods that compile/assemble the image.

Full explanation →

39

MCQhard

An administrator troubleshoots a failing NetworkPolicy and wants to verify if the OpenShift SDN or OVN-Kubernetes controller has successfully applied the rules. Where are the controller operator logs examined?

A.In the openshift-apiserver namespace

B.In the openshift-network-operator or openshift-ovn-kubernetes namespaces

C.In the kube-system namespace under core-dns logs

D.In the openshift-ingress namespace under router pods

AnswerB

The network operator and OVN-Kubernetes controller run as pods within the openshift-network-operator and openshift-ovn-kubernetes namespaces respectively, so their logs reveal whether NetworkPolicy rules were successfully applied. Examining these namespaces satisfies the stem's requirement to verify controller application of rules.

Why this answer

In OpenShift, the network controller components that apply NetworkPolicy rules run in specific namespaces: the network operator itself runs in openshift-network-operator, and the OVN-Kubernetes control plane runs in openshift-ovn-kubernetes. To verify if the controller has successfully applied NetworkPolicy rules, you must examine the logs of the operator and the ovn-kubernetes pods in these namespaces. The openshift-network-operator manages the overall network configuration, while the ovn-kubernetes pods (like ovnkube-master and ovnkube-node) handle the actual implementation of network policies.

Exam trap

EX280 often tests the misconception that network policy controllers run in kube-system or openshift-apiserver, but in OpenShift they are specifically in openshift-network-operator and openshift-ovn-kubernetes namespaces.

How to eliminate wrong answers

Option A is wrong because the openshift-apiserver namespace contains the API server pods, which handle API requests but do not apply NetworkPolicy rules. Option C is wrong because kube-system namespace and core-dns logs are related to DNS services, not network policy enforcement; OpenShift SDN/OVN-Kubernetes controllers are not in kube-system. Option D is wrong because the openshift-ingress namespace contains router pods that handle ingress traffic, not the network policy controller.

Full explanation →

40

Multi-Selecthard

An administrator is troubleshooting an OAuth authentication failure where users receive an error indicating invalid credentials against an HTPasswd provider. Which TWO steps or checks are critical for resolving this issue? (Choose TWO)

Select 2 answers

A.Verify that the Secret containing the htpasswd file is located in the openshift-config namespace.

B.Restart the kube-apiserver static pods to apply the new password file.

C.Verify that all users have cluster-admin privileges assigned automatically.

D.Ensure the password hashes in the htpasswd file use a supported hashing algorithm such as bcrypt.

E.Check that the Secret is labeled with security.openshift.io/htpasswd-provider=true.

AnswersA, D

The HTPasswd identity provider requires its Secret to reside in the openshift-config namespace; the OAuth server only reads credentials from there. A Secret placed elsewhere leaves the provider unable to validate passwords, producing the invalid credentials error. Confirming this namespace satisfies the stem's configuration constraint.

Why this answer

Option A is correct because in OpenShift, the OAuth provider configuration references the htpasswd Secret by name, and that Secret must reside in the openshift-config namespace for the OAuth server to read and use it; a Secret placed elsewhere will not be picked up and authentication will fail. Option D is correct because the htpasswd file must contain password hashes in a format the OAuth htpasswd identity provider supports, such as bcrypt (or the other supported crypt/SSHA variants), and an unsupported or malformed hash causes credential validation to fail even when the username is correct. Option B is not required because the OAuth server reads the referenced Secret dynamically, so restarting the kube-apiserver static pods is neither necessary nor the correct remediation.

Option C is wrong because cluster-admin privileges are unrelated to credential validation and are not assigned automatically to all users. Option E is wrong because there is no such required label on the htpasswd Secret; the provider is bound to the Secret through the OAuth custom resource's htpasswd configuration, not through that label.

Exam trap

EX280 often tests the namespace requirement for identity provider Secrets (openshift-config) and the supported hash algorithm (bcrypt) — candidates incorrectly assume any namespace works or that MD5/crypt hashes are fine.

Full explanation →

41

MCQmedium

An administrator is managing an OpenShift Container Platform 4.14 cluster on AWS. The administrator wants to configure the cluster so that when a worker node is terminated due to a spot instance interruption, the MachineSet automatically replaces it. Which MachineSet configuration parameter should the administrator verify to ensure that new Machines are created to replace terminated ones?

A.selector

B.deletePolicy

C.template

D.replicas

AnswerD

The `replicas` field defines the desired number of Machines. When a Machine is terminated, the MachineSet controller notices the difference between the desired replicas and the actual number of running Machines and creates a new Machine to reconcile. Ensuring that `replicas` is set to the desired count is essential for automatic replacement. This parameter directly controls the self-healing behavior.

Why this answer

The MachineSet controller continuously monitors the number of Machines matching its selector. When a Machine is terminated (e.g., due to a spot instance interruption), the actual count falls below the desired `replicas`. The controller then creates a new Machine based on the `template` to bring the count back to the desired state.

Therefore, the `replicas` parameter is the key to ensuring automatic replacement.

Exam trap

The trap here is thinking that the `template` or `selector` controls replacement, when in fact the `replicas` count drives the reconciliation loop.

Full explanation →

42

MCQmedium

What is the primary function of a CSI (Container Storage Interface) Driver Operator in OpenShift?

A.To deploy, upgrade, and manage the CSI driver components (controller and node plugins) in the cluster.

B.To automatically back up etcd data onto persistent volumes.

C.To act as an NFS server running directly on control plane nodes.

D.To convert emptyDir volumes into encrypted block devices.

AnswerA

The CSI Driver Operator automates lifecycle management of CSI driver components, deploying and upgrading the controller and node plugins across the OpenShift cluster. This satisfies the requirement for consistent, operator-managed storage driver installation rather than manual DaemonSet and Deployment configuration.

Why this answer

A CSI Driver Operator in OpenShift is responsible for deploying, upgrading, and managing the lifecycle of a CSI driver's components — specifically the controller plugin (Deployment) and node plugin (DaemonSet) — in the cluster. It packages the driver as an Operator so that installation, configuration, and upgrades are handled declaratively via the Operator Lifecycle Manager (OLM).

Exam trap

EX280 often tests the misconception that a CSI Driver Operator is the storage backend itself — candidates may pick answers about NFS servers or encryption, but the operator's job is lifecycle management of the CSI driver components (controller and node plugins), not providing the storage or encrypting volumes.

How to eliminate wrong answers

Option B is wrong because etcd backup is handled by the etcd Operator and cluster-backup.sh, not by CSI Driver Operators; CSI drivers provide storage, not control-plane backup. Option C is wrong because a CSI Driver Operator does not run an NFS server on control plane nodes — it deploys storage driver pods (controller/node plugins) that consume storage backends, and NFS is just one possible backend. Option D is wrong because emptyDir volumes are ephemeral node-local storage and are not converted into encrypted block devices by CSI; encryption is a property of the underlying storage backend or a StorageClass parameter (e.g., encrypted: 'true' on AWS EBS).

Full explanation →

43

MCQeasy

A developer wants to expose an application using a secure Route that terminates TLS on the pod itself, avoiding decryption at the router layer. Which TLS termination type should be selected?

A.reencrypt

B.edge

C.none

D.passthrough

AnswerD

Passthrough forwards encrypted traffic straight to the pod, so the router never holds TLS keys and decryption occurs only inside the application container. This satisfies the requirement to terminate TLS on the pod itself, unlike edge or re-encrypt termination.

Why this answer

Passthrough termination allows the router to forward encrypted traffic directly to the pod without decrypting it, so TLS is terminated at the pod itself. This meets the requirement of avoiding decryption at the router layer. Edge and reencrypt both involve decryption at the router, while 'none' means no TLS termination at all.

Exam trap

EX280 often tests the distinction between passthrough and reencrypt, where candidates might think reencrypt avoids router decryption, but only passthrough keeps the router from decrypting.

How to eliminate wrong answers

Option A is wrong because reencrypt decrypts at the router and then re-encrypts to the backend, so the router still handles decryption. Option B is wrong because edge termination decrypts at the router and sends plain HTTP to the pod. Option C is wrong because 'none' is not a valid termination type for secure Routes; it would mean no TLS, which does not meet the requirement.

Full explanation →

44

MCQhard

A developer has created a Kustomization file that applies a namespace prefix and some patches to base Kubernetes manifests. How can the developer apply these manifests to an OpenShift cluster using standard oc tooling without installing standalone Kustomize?

A.oc create -f kustomization.yaml

B.oc run -k ./directory

C.oc apply -k ./directory

D.oc kustomize apply ./directory

AnswerC

The -k flag tells oc to build and apply resources from a Kustomization directory, invoking the Kustomize functionality built into oc. This applies the namespace prefix and patches without installing standalone Kustomize, satisfying the standard-tooling constraint.

Why this answer

The `oc apply -k ./directory` command uses the integrated Kustomize support in the oc CLI to build and apply the Kustomization. This is the standard way to apply Kustomize manifests in OpenShift without installing standalone Kustomize.

Exam trap

The trap is thinking you need to install Kustomize separately or use a different command like `oc kustomize apply`; candidates may not know that `oc apply -k` is the correct integrated approach.

How to eliminate wrong answers

Option A is wrong because `oc create -f kustomization.yaml` would try to create a resource from the Kustomization file itself, which is not a valid Kubernetes resource. Option B is wrong because `oc run -k` is not a valid command; `oc run` is for creating a single pod, and -k is not a flag for it. Option D is wrong because `oc kustomize apply` is not a valid subcommand; `oc kustomize` builds the manifests but does not apply them.

Full explanation →

45

Multi-Selecthard

Which THREE methods can be used to pass parameters or configuration values into a Helm chart installation in OpenShift? (Choose three.)

Select 3 answers

A.Relying on the default values defined in the chart's values.yaml file

B.Directly modifying the deployed Kubernetes Pod annotations via oc patch

C.Passing individual key-value pairs using the --set flag on the CLI

D.Supplying a custom YAML configuration file using the --values flag

E.Injecting values through the cluster-wide OAuth configuration map

AnswersA, C, D

Values from values.yaml supply defaults when no override is given, so installation proceeds with chart-defined configuration. This satisfies the requirement of passing configuration into the release without external flags, though overrides via --set or custom values files take precedence when supplied.

Why this answer

Option A is correct because Helm automatically loads the chart's built-in values.yaml file as the base set of default configuration values whenever a chart is installed, so relying on those defaults is a legitimate way configuration is supplied to the release. Option C is correct because the --set flag lets you override individual values as key-value pairs directly on the command line (e.g., helm install myrelease mychart --set image.tag=latest), which is a standard method for injecting parameters at install time. Option D is correct because the --values (or -f) flag lets you supply a custom YAML file whose keys are merged over the chart defaults, enabling structured, reusable configuration input.

Option B does not belong because oc patch modifies live Kubernetes objects after deployment and has no role in Helm's templating or value-passing mechanism. Option E does not belong because the cluster-wide OAuth configuration map governs OpenShift authentication settings, not Helm chart parameter injection.

Exam trap

EX280 often tests the distinction between pre-installation value injection and post-deployment modifications; candidates may pick `oc patch` as a way to pass values, but it does not affect Helm's templating.

Full explanation →

46

MCQeasy

An administrator needs to expose an internal application running on port 8080 via an OpenShift Route using edge termination. Which object configuration correctly defines this Route?

A.kind: Route metadata: name: my-app spec: to: kind: Service name: my-service port: targetPort: 8080 tls: termination: edge

B.kind: Route metadata: name: my-app spec: to: kind: Service name: my-service port: targetPort: 8080 tls: termination: passthrough

C.kind: Route metadata: name: my-app spec: to: kind: Service name: my-service port: targetPort: 8080

D.kind: Route metadata: name: my-app spec: to: kind: Service name: my-service port: targetPort: 8080 tls: termination: reencrypt

AnswerA

Edge termination requires the tls stanza with termination set to edge, so TLS is decrypted at the router before forwarding plain HTTP to the Service. The spec.to reference and targetPort 8080 correctly direct traffic to the internal application, satisfying the exposure requirement.

Why this answer

The correct Route configuration for edge termination includes the tls stanza with termination: edge, which instructs the router to terminate TLS at the router and forward plain HTTP to the backend service on port 8080. The other options either use incorrect termination types or omit TLS entirely, which would not provide edge termination.

Exam trap

EX280 often tests the details of Route YAML, and candidates might mistakenly choose passthrough or reencrypt when edge is required, or forget to include the tls stanza altogether.

How to eliminate wrong answers

Option B is wrong because termination: passthrough expects the backend to handle TLS, and the router does not decrypt, which contradicts edge termination. Option C is wrong because it lacks any tls stanza, resulting in an unsecured Route (no TLS termination). Option D is wrong because termination: reencrypt requires additional certificate configuration and is used when the router re-encrypts to the backend, not for edge termination.

Full explanation →

47

MCQeasy

What is the primary function of the 'self-provisioner' cluster role in OpenShift?

A.It allows users to scale deployments automatically.

B.It allows users to provision persistent storage volumes.

C.It allows authenticated users to create new projects.

D.It allows users to generate their own OAuth tokens.

AnswerC

The self-provisioner cluster role is bound by default to the authenticated-users group, permitting any logged-in user to create new projects without administrator intervention. This satisfies the requirement that authenticated users can self-service their own namespaces.

Why this answer

The self-provisioner cluster role in OpenShift is a default cluster role bound to authenticated users, allowing them to create new projects (namespaces) on demand. This enables developers to self-service project creation without requiring an administrator to create namespaces for them. It is a key part of OpenShift's multi-tenant model.

Exam trap

EX280 often tests the confusion between cluster roles that allow project creation (self-provisioner) and those that allow resource creation within a project (admin/edit/view) — candidates may incorrectly associate self-provisioner with storage or scaling.

How to eliminate wrong answers

Option A is wrong because scaling deployments is controlled by roles like edit or admin within a project, not by the self-provisioner cluster role. Option B is wrong because provisioning persistent storage volumes is typically an administrator or storage-provisioner function, not granted by self-provisioner. Option D is wrong because generating OAuth tokens is handled by the OAuth server and is not related to the self-provisioner role.

Full explanation →

48

MCQeasy

An administrator needs to create a service that exposes an application externally via an IP address allocated from an external cloud provider load balancer. Which service type must be used?

A.NodePort

B.LoadBalancer

C.ClusterIP

D.ExternalName

AnswerB

The LoadBalancer service type provisions an external load balancer from the underlying cloud provider and assigns it a public IP address, exposing the application externally. NodePort and ClusterIP do not allocate provider-managed IPs, so they cannot satisfy the external cloud load balancer requirement.

Why this answer

A Service of type LoadBalancer instructs the cloud provider's controller (or OpenShift's cloud provider integration) to provision an external load balancer with a public or private IP address, and the Service is exposed through that IP. This is the standard way to expose an application externally via a cloud LB in OpenShift/Kubernetes. The LoadBalancer type builds on NodePort and ClusterIP, adding the external IP allocation.

Exam trap

EX280 often tests whether candidates confuse NodePort (node IP + static port) with LoadBalancer (cloud-allocated external IP), so pick LoadBalancer whenever the question mentions an IP from an external cloud provider load balancer.

How to eliminate wrong answers

Option A is wrong because NodePort exposes the service on a static port on every node's IP, not via a cloud provider-allocated load balancer IP. Option C is wrong because ClusterIP only provides an internal virtual IP reachable within the cluster, with no external exposure. Option D is wrong because ExternalName maps a service to a DNS CNAME (e.g., an external database), not to a cloud load balancer IP.

Full explanation →

49

MCQmedium

An administrator creates a new custom Security Context Constraint (SCC) named restrict-root. After creating the SCC resource, users complain that pods using a ServiceAccount tied to this SCC are still falling back to the restricted-v2 SCC. What is the most likely cause?

A.The SCC object is missing the metadata.labels.openshift.io/scc label set to restrict-root.

B.Custom SCCs are disabled by default in OpenShift Container Platform 4.14 and require an operator configuration change.

C.The ServiceAccount lacks the RBAC permission to use the restrict-root SCC via a ClusterRoleBinding or RoleBinding to the system:openshift:scc:restrict-root ClusterRole.

D.The Pod Security Standards admission plugin is blocking custom SCC creation at the namespace level.

AnswerC

The SCC's admission check requires the pod's ServiceAccount to hold `use` permission on that specific SCC, granted through the `system:openshift:scc:restrict-root` ClusterRole. Without a RoleBinding or ClusterRoleBinding conferring it, authorisation fails and the pod silently falls back to `restricted-v2`, satisfying the stem's fallback symptom.

Why this answer

In OpenShift, an SCC is only usable by a ServiceAccount if that ServiceAccount has been granted permission to use it. This is done by binding the ServiceAccount to the ClusterRole named system:openshift:scc:<scc-name> (or the equivalent RoleBinding in the namespace). Without that RBAC binding, the SCC admission controller ignores the custom SCC and the pod falls back to the default SCC assigned to the ServiceAccount (restricted-v2 in OCP 4.x).

Exam trap

EX280 often tests the misconception that creating an SCC resource is sufficient to make it apply — candidates forget that SCCs must be explicitly granted to a ServiceAccount via RBAC (system:openshift:scc:<name>), and that the admission controller otherwise falls back to default SCCs like restricted-v2.

How to eliminate wrong answers

Option A is wrong because the openshift.io/scc label is set automatically by the SCC admission controller on the pod, not on the SCC object itself — SCCs are matched by name, not by that label. Option B is wrong because custom SCCs are fully supported in OCP 4.14; no operator configuration change is required to enable them. Option D is wrong because Pod Security Standards admission operates at the namespace level and does not block creation of SCC resources — SCCs and PSA coexist, and SCC creation is not gated by PSA.

Full explanation →

50

MCQhard

A developer reports they cannot deploy applications because their deployment quota is exhausted. Upon inspecting the 'LimitRange' object in the namespace, you notice default limits are set. However, a specific container in their deployment YAML fails validation during creation with an admission webhook error stating 'container exceeds minimum cpu request'. Where must the adjustment be made to allow this specific deployment?

A.Update the container resource requests in the deployment YAML to meet or exceed the LimitRange minimums, or adjust the LimitRange object.

B.Modify the ClusterQuota object to increase the CPU limit.

C.Create a ClusterRoleBinding giving the developer cluster-admin rights to bypass admission webhooks.

D.Add the developer to the 'system:masters' group to override resource constraints.

AnswerA

Admission validation compares each container's requests against the LimitRange minimums, so the fix lies either in raising the container's cpu request in the deployment spec or lowering the LimitRange floor; the LimitRange alone does not grant the pod.

Why this answer

The admission webhook error 'container exceeds minimum cpu request' comes from the LimitRange's min constraint, which is enforced at pod admission time. To resolve it, the container's `resources.requests.cpu` must be raised to at least the LimitRange minimum, or the LimitRange's min value must be lowered to accommodate the container. Both are valid fixes, and the option correctly names both.

Exam trap

EX280 often tests whether candidates understand that LimitRange admission is not bypassable via RBAC — the trap is picking cluster-admin or system:masters as a way to override resource constraints.

How to eliminate wrong answers

Option B is wrong because ClusterQuota (ClusterResourceQuota) governs aggregate namespace consumption across projects — it does not set per-container minimums and cannot override a LimitRange min constraint. Option C is wrong because cluster-admin rights do not bypass LimitRange admission; LimitRange is enforced by the LimitRanger admission plugin for all users regardless of RBAC. Option D is wrong because adding a user to system:masters grants cluster-admin but still does not exempt them from LimitRange admission — resource constraints are not RBAC-gated.

Full explanation →

51

MCQeasy

Which command is used to remove a role binding named 'dev-binding' from a namespace named 'development'?

A.oc revoke rolebinding dev-binding -n development

B.oc delete rolebinding dev-binding -n development

C.oc drop rolebinding dev-binding -n development

D.oc remove rolebinding dev-binding -n development

AnswerB

`oc delete rolebinding` targets the namespaced RoleBinding resource directly, and the `-n development` flag scopes the operation to the required namespace, satisfying the stem's constraint. RoleBindings exist within a namespace, so this combination removes exactly the named binding without affecting cluster-scoped ClusterRoleBindings.

Why this answer

RoleBindings are standard Kubernetes/OpenShift resources, so they are removed with the generic 'oc delete' verb followed by the resource type and name. The command 'oc delete rolebinding dev-binding -n development' deletes the named RoleBinding from the development namespace, immediately revoking the permissions it granted. There is no dedicated 'revoke', 'drop', or 'remove' verb for rolebindings in oc.

Exam trap

EX280 often tests whether candidates invent non-existent oc verbs like 'revoke', 'drop', or 'remove' instead of using the universal 'delete' verb that applies to all resources.

How to eliminate wrong answers

Option A is wrong because 'oc revoke' is not a valid oc subcommand — there is no revoke verb in the CLI; permissions are removed by deleting the binding or using 'oc adm policy remove-role-from-user'. Option C is wrong because 'oc drop' does not exist as a subcommand in oc; it is a fabricated verb. Option D is wrong because 'oc remove' is not a valid oc subcommand either — removal of rolebindings is done via delete or the 'oc adm policy remove-*' helpers.

Full explanation →

52

MCQeasy

Which command is used to create a new cluster role named 'storage-reader' that permits getting and listing PersistentVolumes cluster-wide?

A.oc new clusterrole storage-reader --permissions=pv:get,list

B.oc create role storage-reader --cluster --verb=get,list --resource=persistentvolumes

C.oc adm create-role storage-reader --cluster-wide --verbs=get,list --resources=pv

D.oc create clusterrole storage-reader --verb=get,list --resource=persistentvolumes

AnswerD

`oc create clusterrole` builds a ClusterRole, which grants permissions cluster-wide rather than within a namespace. Specifying `--verb=get,list` with `--resource=persistentvolumes` matches the required read operations on PersistentVolumes, satisfying the stem's cluster-wide scope constraint that a namespaced Role could not provide.

Why this answer

The correct command is `oc create clusterrole storage-reader --verb=get,list --resource=persistentvolumes`. This uses the `oc create clusterrole` subcommand, which is the standard OpenShift/Kubernetes imperative command for creating a ClusterRole resource. The `--verb` flag specifies the allowed actions (get, list), and `--resource` specifies the target resource type (persistentvolumes).

This directly creates a ClusterRole named 'storage-reader' with the desired permissions cluster-wide.

Exam trap

EX280 often tests the distinction between namespaced Roles and cluster-scoped ClusterRoles, and candidates may mistakenly use `oc create role` with a `--cluster` flag, which does not exist.

How to eliminate wrong answers

Option A is wrong because `oc new clusterrole` is not a valid subcommand; `oc new` is used for creating applications from source code, not RBAC resources. Option B is wrong because `oc create role` creates a namespaced Role, not a ClusterRole; the `--cluster` flag does not exist for this subcommand. Option C is wrong because `oc adm create-role` is not a valid command; `oc adm` has subcommands like `policy` but not `create-role`, and the flags `--cluster-wide` and `--resources` are incorrect.

Full explanation →

53

Multi-Selecteasy

When setting up authentication and user provisioning in OpenShift 4, which THREE identity providers are natively supported out-of-the-box by the OAuth server configuration? (Choose THREE)

Select 3 answers

A.OpenID Connect (OIDC)

B.Local Linux /etc/passwd direct sync daemon

C.HTPasswd

D.Active Directory Domain Services native kernel module

E.LDAP

AnswersA, C, E

OpenShift 4 ships an OpenID Connect identity provider as a built-in OAuth server configuration type. It maps claims from an OIDC issuer to OpenShift identities and groups, requiring only a client secret and issuer URL to configure natively.

Why this answer

OpenShift 4's OAuth server natively supports several identity providers configured through the OAuth custom resource, and OpenID Connect (OIDC) (A) is one of them, allowing integration with any OIDC-compliant provider such as Keycloak or Okta via the oidc identity provider type. HTPasswd (C) is also natively supported, using a secret containing an htpasswd-formatted file (created with htpasswd -c -B -b) to authenticate users against a static user list. LDAP (E) is natively supported as well, with the ldap identity provider type supporting direct binds, search-and-bind, and URL-based configurations against directory servers.

The unmarked options do not belong because there is no 'Local Linux /etc/passwd direct sync daemon' identity provider (B) in OpenShift, and there is no 'Active Directory Domain Services native kernel module' identity provider (D); AD is integrated indirectly via LDAP or OIDC, not through a kernel module.

Exam trap

EX280 often tests whether candidates can identify the real OpenShift identity provider types versus fabricated ones like 'Local Linux /etc/passwd direct sync daemon' or 'Active Directory Domain Services native kernel module' that sound technical but do not exist.

Full explanation →

54

Multi-Selectmedium

Which TWO methods can an administrator use to inspect or troubleshoot Security Context Constraint (SCC) assignments for a specific ServiceAccount in a namespace?

Select 2 answers

A.Examine the /etc/origin/master/scc.yaml file on control plane nodes.

B.Use oc auth can-i create pods --as=system:serviceaccount:<namespace>:<serviceaccount-name> to test permissions.

C.Inspect the service account's annotations for the kubernetes.io/scc-assignment-override key.

D.Run oc adm policy who-can use scc restricted-v2 to see which users and service accounts have access to the SCC.

E.Check the logs of the kube-apiserver static pod for SCC admission failures.

AnswersB, D

The can-i command with impersonation tests whether a specific ServiceAccount can create pods, revealing effective permissions granted through its SCC and role bindings. This satisfies the requirement to troubleshoot a named ServiceAccount's actual authorisation in its namespace.

Why this answer

Option B is correct because `oc auth can-i` with the `--as=system:serviceaccount:<namespace>:<serviceaccount-name>` flag performs a SubjectAccessReview impersonating the ServiceAccount, letting an administrator verify whether that ServiceAccount can perform an action (such as creating pods) that is gated by SCC admission, which directly tests effective SCC-derived permissions. Option D is correct because `oc adm policy who-can use scc restricted-v2` queries the RBAC rules bound to the SCC's `use` verb and lists exactly which users, groups, and ServiceAccounts (including those in the target namespace) are authorized to use that SCC, which is the standard way to inspect SCC assignments. Option A is not correct because SCCs are stored as cluster-scoped API objects (retrievable via `oc get scc`), not in a static `/etc/origin/master/scc.yaml` file on control plane nodes.

Option C is not correct because SCC assignment is not controlled by a `kubernetes.io/scc-assignment-override` annotation on the ServiceAccount; it is determined by RBAC bindings to the SCC's `use` verb. Option E is not correct because kube-apiserver static pod logs may show admission denials but do not enumerate or inspect SCC assignments for a specific ServiceAccount.

Exam trap

EX280 often tests whether candidates rely on OpenShift 3 artifacts (scc.yaml files) or invented annotations instead of the supported oc auth can-i and oc adm policy who-can commands for SCC inspection.

Full explanation →

55

MCQeasy

An administrator needs to view the current list of active Security Context Constraints installed in an OpenShift cluster. Which command should be executed?

A.oc get securityconstraints

B.oc get scc

C.oc adm policy list-constraints

D.oc describe clustersecurity

AnswerB

`oc get scc` queries the cluster's SecurityContextConstraints resource type directly, returning every SCC currently defined. This satisfies the stem's requirement to list active SCCs, since `oc get` retrieves resources of the named type from the API server without modifying them.

Why this answer

The `oc get scc` command is the correct way to list Security Context Constraints in an OpenShift cluster. SCC is the official short name (singular/plural) registered for the securitycontextconstraints resource in the OpenShift API, so `oc get scc` returns the full list of active SCCs such as restricted, anyuid, hostaccess, and privileged.

Exam trap

EX280 often tests whether candidates know the registered short name for OpenShift API resources — 'scc' for securitycontextconstraints — versus inventing plausible-sounding resource names like 'securityconstraints' or fake subcommands like 'list-constraints'.

How to eliminate wrong answers

Option A is wrong because 'securityconstraints' is not a valid resource name — the actual API resource is 'securitycontextconstraints' (short name 'scc'), so this command returns a 'resource not found' error. Option C is wrong because 'oc adm policy list-constraints' is not a real subcommand; oc adm policy supports add-scc-to-user, add-scc-to-group, remove-scc-from-user, and similar verbs, but not list-constraints. Option D is wrong because 'clustersecurity' is not an OpenShift resource type at all — there is no such API object to describe.

Full explanation →

56

MCQmedium

You want to restore an existing VolumeSnapshot into a new PersistentVolumeClaim. Which field in the PVC specification must reference the VolumeSnapshot?

A.claimRef

B.snapshotName

C.dataSource

D.volumeName

AnswerC

The dataSource field names the VolumeSnapshot as the source for provisioning, so the CSI driver restores its contents into the new PVC. Setting dataSource to a VolumeSnapshot kind satisfies the requirement to restore an existing snapshot rather than bind an empty volume.

Why this answer

In Kubernetes/OpenShift, restoring a VolumeSnapshot into a new PVC is done by setting the PVC's spec.dataSource field to reference the VolumeSnapshot object (apiGroup: snapshot.storage.k8s.io, kind: VolumeSnapshot, name: <snapshot-name>). This tells the CSI provisioner to create the new volume from the snapshot's contents rather than provisioning an empty volume. The dataSource field is the standard, GA mechanism for both snapshot restore and volume cloning.

Exam trap

EX280 often tests whether candidates confuse PVC dataSource (for snapshot/clone restore) with PV claimRef (for binding) or PVC volumeName (for static binding), so pick dataSource whenever the question mentions restoring from a snapshot.

How to eliminate wrong answers

Option A is wrong because claimRef is a PersistentVolume field used to bind a PV to a specific PVC, not a PVC field for sourcing data. Option B is wrong because snapshotName is not a valid PVC spec field — the snapshot reference must be nested under dataSource, not a top-level key. Option D is wrong because volumeName statically binds a PVC to an existing PersistentVolume by name; it does not trigger snapshot-based provisioning.

Full explanation →

57

MCQhard

An administrator needs to modify the default Ingress controller configuration to change its replica count and adjust the router deployment parameters. Which resource should the administrator edit?

A.ingresscontroller.operator.openshift.io named 'default'

B.deployment named router-default in openshift-ingress namespace

C.configmap named router-config in openshift-ingress-operator

D.service named router-default-http in openshift-ingress

AnswerA

The IngressController operator resource is the cluster-scoped configuration object that the ingress operator reconciles; editing its spec changes replica count and router deployment parameters, which the operator then applies. Editing the router deployment directly would be overwritten, since the operator enforces the declared state.

Why this answer

The Ingress controller configuration in OpenShift is managed by the IngressController operator resource named 'default' in the openshift-ingress-operator namespace. To change replica count and router deployment parameters, the administrator edits this ingresscontroller.operator.openshift.io custom resource. The operator then reconciles the changes into the router Deployment.

Exam trap

EX280 often tests the operator pattern — candidates may choose to edit the router Deployment directly, not realizing that the IngressController CR is the supported and persistent way to change replica count and router parameters.

How to eliminate wrong answers

Option B is wrong because editing the router-default Deployment directly is not supported; the operator will revert manual changes, and the Deployment is a generated resource. Option C is wrong because there is no configmap named router-config in openshift-ingress-operator that controls replica count; configuration is via the IngressController CR. Option D is wrong because a Service named router-default-http exposes the router but does not define replica count or deployment parameters.

Full explanation →

58

MCQeasy

An application pod requires concurrent read and write access to the same storage volume from multiple worker nodes simultaneously. Which access mode must be specified in the PersistentVolumeClaim to satisfy this requirement?

A.ReadWriteMany

B.ReadWriteOnce

C.ReadOnlyMany

D.WriteOncePod

AnswerA

ReadWriteMany permits a volume to be mounted read-write by many nodes concurrently, matching the requirement for simultaneous access from multiple worker nodes. ReadWriteOnce and ReadWriteOncePod restrict access to a single node, so they cannot satisfy this constraint.

Why this answer

ReadWriteMany (RWX) allows a volume to be mounted as read-write by many nodes simultaneously, which is required when multiple pods on different worker nodes need concurrent read/write access. It is supported by shared filesystems like NFS, CephFS, or GlusterFS, but not by block storage such as EBS or most local volumes.

Exam trap

EX280 often tests access mode semantics — candidates confuse ReadOnlyMany with ReadWriteMany or assume RWO permits multi-node access.

How to eliminate wrong answers

Option B is wrong because ReadWriteOnce (RWO) allows read-write mounting by only a single node at a time, so pods on multiple nodes cannot concurrently write. Option C is wrong because ReadOnlyMany (ROX) permits multi-node mounting but only read-only, not read-write. Option D is wrong because WriteOncePod restricts the volume to a single pod cluster-wide, the strictest mode, and does not allow multi-node concurrency.

Full explanation →

59

MCQeasy

An administrator needs to view the rollout history of a DeploymentConfig named web-frontend. Which command accomplishes this?

A.oc rollout history dc/web-frontend

B.oc describe dc/web-frontend

C.oc get revisions dc/web-frontend

D.oc log rollout dc/web-frontend

AnswerA

The 'oc rollout history' command with the dc/web-frontend resource argument queries the deployment configuration's revision history, listing each rollout with its revision number and change cause, directly satisfying the administrator's need to view rollout history.

Why this answer

The `oc rollout history` command is specifically designed to display the revision history of a DeploymentConfig (or Deployment). When used with the resource type and name (`dc/web-frontend`), it lists all revisions, their change causes, and the current active revision. This directly fulfills the requirement to view rollout history.

Exam trap

EX280 often tests the distinction between commands that show current state versus historical state; candidates might confuse `oc describe` (which shows current details) with `oc rollout history` (which shows past revisions).

How to eliminate wrong answers

Option B is wrong because `oc describe dc/web-frontend` provides detailed status and configuration information about the DeploymentConfig, but does not list the historical revisions or their change causes. Option C is wrong because `oc get revisions dc/web-frontend` is not a valid command; `revisions` is not a standalone resource type in OpenShift, and `oc get` cannot retrieve revision history in this manner. Option D is wrong because `oc log rollout dc/web-frontend` is not a valid command; `oc log` is used to retrieve logs from pods or builds, not to view rollout history.

Full explanation →

60

Multi-Selecteasy

Which TWO of the following are valid built-in default project roles in OpenShift that can be assigned to users within a namespace? (Choose TWO)

Select 2 answers

A.admin

B.security-admin

C.edit

D.node-admin

E.cluster-admin

AnswersA, C

The `admin` role is a built-in OpenShift project role granting full control over resources within a namespace, including managing quotas and viewing or modifying most objects, but excluding cluster-scoped changes. It satisfies the stem's requirement for a default role assignable to users inside a single project.

Why this answer

In OpenShift, the built-in default project (namespace-scoped) roles that can be bound to users within a namespace include admin and edit, so options A and C are correct. The admin role grants full control over a project, including managing roles and bindings within that namespace, while the edit role allows creating, modifying, and deleting most resources in the project but not managing roles or bindings. These roles are part of the standard OpenShift RBAC set (admin, edit, view, and sometimes self-provisioner) applied per namespace.

Option B (security-admin) is not a built-in default project role; security context constraints are managed via cluster roles such as system:cluster-admin or specific SCC-related roles. Option D (node-admin) is not a built-in project role; node management is a cluster-level concern handled by cluster roles. Option E (cluster-admin) is a cluster-scoped role, not a namespace-scoped default project role, so it does not fit the scenario.

Exam trap

EX280 often tests whether candidates confuse project-scoped roles (admin, edit, view) with cluster-scoped roles (cluster-admin, node-admin), leading them to pick cluster-admin as a namespace role when it is not.

Full explanation →

61

MCQeasy

Which namespace houses the core Cluster Version Operator (CVO) in an OpenShift 4.14 cluster?

A.openshift-machine-api

B.openshift-operator-lifecycle-manager

C.openshift-cluster-version

D.openshift-config

AnswerC

The Cluster Version Operator runs as a cluster-scoped workload in the openshift-cluster-version namespace, where it reconciles the desired OpenShift release version against cluster state. That namespace is the fixed location for CVO components in OpenShift 4.14.

Why this answer

The Cluster Version Operator (CVO) runs in the openshift-cluster-version namespace, where it manages cluster updates by orchestrating the rollout of new versions. This namespace is dedicated to the CVO and its associated resources, such as the ClusterVersion object.

Exam trap

EX280 often tests the namespaces of core components, and candidates might confuse the CVO with OLM or the Machine API Operator, leading to wrong namespace choices.

How to eliminate wrong answers

Option A is wrong because openshift-machine-api houses the Machine API Operator and related components for managing machines. Option B is wrong because openshift-operator-lifecycle-manager is for the Operator Lifecycle Manager (OLM) which manages operators. Option D is wrong because openshift-config contains cluster-wide configuration resources, not the CVO.

Full explanation →

62

MCQeasy

An administrator needs to deploy a containerized web application using a Git repository as the source without writing a Dockerfile. Which OpenShift build strategy should be used?

A.Source-to-Image (S2I) strategy

B.Docker strategy

C.Custom strategy

D.Pipeline strategy

AnswerA

Source-to-Image builds inject application source directly into a builder image, which detects the runtime and assembles the final image without a Dockerfile. This satisfies the stem's constraint of using a Git repository as source while avoiding manual Dockerfile authoring, unlike Docker or custom strategies.

Why this answer

The Source-to-Image (S2I) strategy builds application images by combining builder images with source code, without requiring a Dockerfile. OpenShift injects the source into the builder image, runs assemble/run scripts, and produces a runnable image. This is the standard approach for deploying from Git when no Dockerfile exists.

Exam trap

EX280 often tests the distinction between build strategies, and candidates confuse S2I (no Dockerfile needed) with the Docker strategy (Dockerfile required).

How to eliminate wrong answers

Option B is wrong because the Docker strategy requires a Dockerfile in the repository to define the build. Option C is wrong because the Custom strategy requires the user to supply their own builder image with custom assemble/run logic, which is more complex than needed. Option D is wrong because Pipeline strategy uses Jenkins pipelines for CI/CD orchestration, not for building from source without a Dockerfile.

Full explanation →

63

MCQmedium

An administrator is troubleshooting a failed cluster upgrade in OpenShift 4.14. The upgrade channel is set to 'stable-4.14', but the cluster refuses to update to the latest target version. The administrator runs 'oc get clusterversion' and notes that a specific ClusterOperator reports 'Degraded=True'. What is the recommended next step?

A.Switch the upgrade channel to 'fast-4.14' to bypass the degraded check.

B.Delete the Cluster Version Operator deployment to force a reset of the upgrade state machine.

C.Force the upgrade by running 'oc adm upgrade --to=<version> --force-ignore-degraded'.

D.Describe or inspect the degraded ClusterOperator to identify the root cause and resolve its configuration or resource issues.

AnswerD

A ClusterOperator reporting Degraded=True blocks the upgrade because the Cluster Version Operator refuses to proceed while an operator is unhealthy. Inspecting that operator's status and logs reveals the underlying configuration or resource fault, which must be resolved before the update can continue.

Why this answer

The Cluster Version Operator (CVO) blocks upgrades when any ClusterOperator reports Degraded=True because a degraded operator indicates an unhealthy cluster component that could cause the upgrade to fail or leave the cluster in an unstable state. The correct next step is to investigate the specific degraded operator using 'oc describe clusteroperator <name>' or 'oc get clusteroperator <name> -o yaml' to identify the root cause, such as misconfiguration, missing resources, or failing pods. Once the underlying issue is resolved and the operator reports Available=True and Degraded=False, the upgrade can proceed normally.

This aligns with OpenShift's design principle that upgrades should only occur on a healthy cluster.

Exam trap

EX280 often tests the misconception that you can bypass or force an upgrade despite degraded operators, but the correct approach is always to resolve the underlying degradation first.

How to eliminate wrong answers

Option A is wrong because switching to 'fast-4.14' does not bypass the degraded check; the CVO still blocks upgrades if any ClusterOperator is degraded, regardless of channel. Option B is wrong because deleting the Cluster Version Operator deployment is destructive and does not reset the upgrade state machine; the CVO is a critical component that will be recreated by the cluster, but the degraded condition persists and the action may cause further instability. Option C is wrong because 'oc adm upgrade --to=<version> --force-ignore-degraded' is not a valid command in OpenShift 4.x; there is no supported flag to force an upgrade while ignoring degraded operators, and attempting to do so is unsupported and risky.

Full explanation →

64

MCQeasy

An administrator needs to grant read-only access to pods across all namespaces to a specific service account named 'monitor-sa' in the 'monitoring' project. Which RBAC resource configuration is required?

A.A SecurityContextConstraints object assigned to the ServiceAccount

B.A ClusterRole and a RoleBinding in the monitoring namespace

C.A ClusterRole and a ClusterRoleBinding

D.A Role and a RoleBinding in the monitoring namespace

AnswerC

A ClusterRole defines permissions cluster-wide, and binding it via ClusterRoleBinding to the 'monitor-sa' service account grants read-only pod access across every namespace. A Role with RoleBinding would only apply within the 'monitoring' namespace, failing the all-namespaces constraint.

Why this answer

To grant read-only access to pods across all namespaces, the permissions must be cluster-scoped. A ClusterRole defines the permissions (e.g., get, list, watch on pods), and a ClusterRoleBinding binds that ClusterRole to the service account, granting access cluster-wide. This is the correct RBAC configuration for cross-namespace access.

Exam trap

EX280 often tests the distinction between RoleBinding and ClusterRoleBinding for cross-namespace access, causing candidates to choose namespace-scoped bindings when cluster-wide access is required.

How to eliminate wrong answers

Option A is wrong because SecurityContextConstraints control pod security, not RBAC permissions for reading pods. Option B is wrong because a RoleBinding in the monitoring namespace only grants permissions within that namespace, not across all namespaces. Option D is wrong because a Role and RoleBinding are namespace-scoped and cannot grant cluster-wide access.

Full explanation →

65

Multi-Selecthard

Which THREE actions are required when manually setting up a pre-provisioned PersistentVolume backed by an existing storage asset?

Select 3 answers

A.Set allowVolumeExpansion to false on all namespaces.

B.Specify spec.accessModes to match expected claim requirements.

C.Provide the specific volume source configuration (e.g., csi or nfs parameters).

D.Define spec.capacity.storage matching the underlying storage size.

E.Create a matching VolumeSnapshotClass before defining the PV.

AnswersB, C, D

Specifying `spec.accessModes` ensures the PersistentVolume advertises exactly the access the underlying storage asset supports, such as ReadWriteOnce or ReadWriteMany. This satisfies the stem's requirement to match expected claim requirements, so a PersistentVolumeClaim binding to this pre-provisioned volume succeeds rather than failing on incompatible access mode constraints.

Why this answer

When manually creating a pre-provisioned PersistentVolume, you must define the storage capacity in spec.capacity.storage (option D) so the PV advertises the correct size that a PVC can request and bind to. You must also set spec.accessModes (option B) such as ReadWriteOnce, ReadOnlyMany, or ReadWriteMany so the PV's supported modes match the PVC's requested access mode for binding. Finally, you must provide the volume source configuration (option C), e.g., csi with driver/volumeHandle or nfs with server/path, because this tells Kubernetes which existing storage asset to attach and how to mount it.

Option A is wrong because allowVolumeExpansion is a StorageClass field, not a per-namespace setting, and it is irrelevant to a manually created PV. Option E is wrong because VolumeSnapshotClass is only needed for snapshot operations, not for defining a pre-provisioned PV.

Exam trap

EX280 often tests the required fields of a manually created PV, tricking candidates into selecting StorageClass or snapshot-related options that are irrelevant to pre-provisioned volume setup.

Full explanation →

66

Multi-Selecteasy

Which TWO components are core parts of the OpenShift DNS architecture for cluster resolution? (Choose TWO)

Select 2 answers

A.CoreDNS

B.Cluster DNS Operator

C.BIND9

D.HAProxy DNS module

E.Keepalived DNS plugin

AnswersA, B

CoreDNS runs as the cluster DNS operator's managed component, resolving service names and pod FQDNs for internal cluster traffic. It satisfies the stem's requirement for a core OpenShift DNS component, operating alongside the node resolver to handle the cluster domain's forward and reverse lookups.

Why this answer

CoreDNS (A) is correct because OpenShift uses CoreDNS as the actual DNS server that runs in the cluster and resolves names for services, pods, and internal cluster resources. The Cluster DNS Operator (B) is correct because it is the OpenShift operator responsible for deploying, configuring, and managing the CoreDNS instances and their DNS configuration across the cluster. BIND9 (C) is not part of the core OpenShift DNS architecture; it is a general-purpose DNS server not used as the cluster's internal resolver.

HAProxy DNS module (D) is incorrect because HAProxy is used for routing/load balancing, not as a core DNS resolution component in OpenShift. Keepalived DNS plugin (E) is incorrect because Keepalived provides VRRP-based high availability and is not a DNS resolution component of OpenShift.

Exam trap

EX280 often tests the confusion between general DNS servers (BIND9) and OpenShift-specific components (CoreDNS and DNS Operator), leading candidates to pick familiar but incorrect tools.

Full explanation →

67

MCQeasy

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

A.oc adm diagnose

B.oc adm must-gather

C.oc cluster-info dump

D.oc get clusteroperators -o yaml

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

68

Multi-Selectmedium

When managing application lifecycles and rollouts using standard Kubernetes Deployments in OpenShift 4.14, which TWO parameters are explicitly configurable under the rollingUpdate strategy settings? (Choose two.)

Select 2 answers

A.maxSurge

B.minReadySeconds

C.timeoutSeconds

D.rollbackWindow

E.maxUnavailable

AnswersA, E

maxSurge specifies how many extra Pods beyond the desired replica count may be created during a rolling update. It is one of the two parameters configurable under the rollingUpdate strategy, controlling rollout capacity alongside maxUnavailable.

Why this answer

In a Kubernetes Deployment's spec.strategy.rollingUpdate, the two explicitly configurable parameters are maxSurge (option A) and maxUnavailable (option E). maxSurge defines how many extra Pods beyond the desired replica count can be created during an update, and maxUnavailable defines how many Pods below the desired count can be unavailable during the rollout; both accept an integer or percentage and are the only fields under rollingUpdate. minReadySeconds (option B) is a valid Deployment field, but it sits at spec.minReadySeconds, not under the rollingUpdate strategy settings. timeoutSeconds (option C) is not a Deployment rollingUpdate parameter (it appears in probes and other APIs), and rollbackWindow (option D) is not a standard Kubernetes Deployment field at all, so neither belongs here.

Exam trap

EX280 often tests the distinction between parameters that belong to the rollingUpdate strategy (maxSurge, maxUnavailable) and those that are separate Deployment fields (minReadySeconds) or unrelated (timeoutSeconds, rollbackWindow).

Full explanation →

69

MCQmedium

An application pod in OpenShift needs to determine its own IP address and the cluster DNS servers dynamically. Where does CoreDNS look or how are pods configured to resolve cluster DNS?

A.By querying the OpenShift API server directly on port 6443 for DNS records

B.Through an environment variable named CLUSTER_DNS injected into every container

C.By parsing the /etc/hosts file updated dynamically by the OpenShift SDN controller

D.Via the /etc/resolv.conf file automatically managed inside the pod container

AnswerD

The kubelet writes the pod's /etc/resolv.conf at creation, pointing nameserver at the CoreDNS ClusterIP service and setting search domains and ndots. Applications read this file to obtain cluster DNS resolution, so no manual configuration or API query is needed.

Why this answer

Every pod in OpenShift has its /etc/resolv.conf automatically populated by the kubelet with the cluster DNS service IP (typically 172.30.0.10) and search domains. CoreDNS listens on that service IP and answers queries for cluster-internal names like service.namespace.svc.cluster.local. The pod does not query the API server directly; it simply uses the resolver configuration injected at container start.

Exam trap

The trap here is assuming pods get DNS via environment variables or API calls; candidates must remember that Kubernetes/OpenShift DNS is delivered through the standard /etc/resolv.conf mechanism managed by the kubelet.

How to eliminate wrong answers

Option A is wrong because pods do not query the API server on 6443 for DNS; CoreDNS is the resolver, and the API server is not a DNS endpoint. Option B is wrong because there is no CLUSTER_DNS environment variable injected into containers by default; DNS is configured via resolv.conf, not env vars. Option C is wrong because /etc/hosts is not dynamically updated by the SDN controller for DNS resolution; it only contains static entries like the pod's own hostname.

Full explanation →

70

MCQeasy

An administrator needs to test DNS resolution from inside a running pod. Which command run inside a container uses the standard Linux DNS lookup utility?

A.nslookup backend.production.svc.cluster.local

B.route lookup backend

C.oc get dns

D.ping -dns backend.production.svc.cluster.local

AnswerA

nslookup is the standard Linux DNS lookup utility available inside the container image, querying the cluster DNS service for the fully qualified service name. It resolves backend.production.svc.cluster.local directly, confirming whether cluster DNS resolution works from the pod's network namespace.

Why this answer

nslookup is the standard Linux DNS lookup utility and can be run inside a container to query DNS resolution for a service FQDN such as backend.production.svc.cluster.local. Running it inside the pod tests the actual DNS path the application would use, including the cluster DNS service and any search domain configuration. This directly answers the requirement to test DNS resolution from inside a running pod.

Exam trap

EX280 often tests whether candidates know the standard in-container DNS utility (nslookup) versus cluster-level CLI commands (oc get dns) — candidates pick the oc command because it sounds authoritative, but it does not test resolution from inside the pod.

How to eliminate wrong answers

Option B is wrong because `route lookup` is not a standard Linux command for DNS resolution — route is a networking utility for the routing table, and there is no `route lookup` subcommand for DNS. Option C is wrong because `oc get dns` is an OpenShift CLI command that reads the cluster DNS operator configuration from outside the pod; it does not test resolution from inside a container. Option D is wrong because `ping -dns` is not a valid ping option — ping does not have a -dns flag, and while ping can resolve names, it is not the standard DNS lookup utility and may be blocked by ICMP policies.

Full explanation →

71

MCQeasy

What is the primary function of the Machine Config Operator (MCO) in OpenShift 4.14?

A.Managing operating system configurations, file system changes, and software updates for cluster nodes.

B.Handling external DNS records and cluster ingress routing.

C.Provisioning cloud provider virtual machines for cluster scaling.

D.Managing container image registries and secure image signing.

AnswerA

The MCO reconciles MachineConfig objects onto nodes, applying operating system configuration, file system changes and software updates, and rolling nodes when required. This matches the stem's requirement for managing node-level OS configuration and updates in OpenShift 4.14.

Why this answer

The Machine Config Operator (MCO) is a core OpenShift component that manages the operating system configuration and updates of cluster nodes. It uses MachineConfig objects to apply changes such as systemd units, files, and kernel arguments, and it orchestrates rolling updates to nodes via the Machine Config Daemon. This ensures nodes are configured consistently and updated safely.

Exam trap

EX280 often tests the misconception that the MCO handles cluster infrastructure provisioning or networking, when it is strictly focused on node OS configuration and updates.

How to eliminate wrong answers

Option B is wrong because external DNS records and ingress routing are handled by the DNS Operator and Ingress Operator, not the MCO. Option C is wrong because provisioning cloud provider virtual machines is the responsibility of the Cluster API (Machine API) and cloud provider integrations, not the MCO. Option D is wrong because container image registries and image signing are managed by the Image Registry Operator and related security features, not the MCO.

Full explanation →

72

MCQmedium

An administrator wants to inspect the ignition configuration generated for worker nodes by the Machine Config Operator. Which command or resource should the administrator examine?

A.Run 'oc adm inspect ignition-configs'.

B.Check the ConfigMap named 'ignition-worker' in the default namespace.

C.View the ClusterVersion status conditions.

D.Inspect the rendered MachineConfig objects (e.g., rendered-worker-*) managed by the MCO.

AnswerD

The Machine Config Operator renders cluster MachineConfigs into per-pool rendered-worker-* objects, which contain the final ignition config actually served to nodes. Inspecting these satisfies the stem's requirement to see the generated ignition configuration rather than the source MachineConfigPool.

Why this answer

The Machine Config Operator (MCO) generates rendered MachineConfig objects named rendered-worker-* (and rendered-master-*) that contain the final, merged ignition configuration for each machine pool. These rendered objects are the authoritative source for inspecting what ignition config will actually be applied to worker nodes, combining all MachineConfigs, kubelet configs, and container runtime settings. Inspecting these rendered objects via 'oc get machineconfig rendered-worker-<hash> -o yaml' reveals the complete ignition payload, including systemd units, files, and kernel arguments.

Exam trap

EX280 often tests the misconception that ignition configs are stored in ConfigMaps or accessible via generic oc adm commands, when in fact they are embedded in rendered MachineConfig objects managed by the MCO.

How to eliminate wrong answers

Option A is wrong because 'oc adm inspect ignition-configs' is not a valid oc adm inspect resource type — oc adm inspect works on namespaces, pods, nodes, and similar cluster resources, not on a nonexistent 'ignition-configs' resource. Option B is wrong because there is no ConfigMap named 'ignition-worker' in the default namespace; ignition configs are stored in MachineConfig objects, not ConfigMaps, and the MCO does not create such a ConfigMap. Option C is wrong because ClusterVersion status conditions report on cluster version and update progress, not on the ignition configuration content generated for worker nodes.

Full explanation →

73

Multi-Selectmedium

Which TWO options describe characteristics of OVN-Kubernetes compared to the legacy OpenShift SDN? (Choose TWO)

Select 2 answers

A.It provides native support for EgressIP and EgressFirewall custom resources.

B.It relies exclusively on traditional Linux iptables rules without OVS flow tables.

C.It requires the flannel CNI plugin to function.

D.It uses Open Virtual Network (OVN) with OVS for routing and switching.

E.It does not support NetworkPolicies.

AnswersA, D

OVN-Kubernetes implements EgressIP and EgressFirewall as native custom resources through its OVN northbound database, satisfying the stem's requirement for characteristics distinguishing it from OpenShift SDN. The legacy plugin relied on different mechanisms, such as iptables-based egress router pods, so native CRD support is a genuine architectural difference.

Why this answer

Option A is correct because OVN-Kubernetes natively implements EgressIP and EgressFirewall as custom resources managed through its OVN northbound database, giving cluster administrators first-class APIs for controlling egress traffic that the legacy OpenShift SDN handled differently or with limited functionality. Option D is correct because OVN-Kubernetes is built on Open Virtual Network (OVN) and Open vSwitch (OVS), using OVS flows and OVN logical flows for distributed routing and switching across nodes, which is the architectural foundation that distinguishes it from OpenShift SDN. Option B is incorrect because OVN-Kubernetes does not rely exclusively on iptables; it uses OVS flow tables and OVN logical flows for most dataplane forwarding, with iptables only for limited host-level functions.

Option C is incorrect because OVN-Kubernetes does not require the flannel CNI plugin; it is a self-contained CNI implementation. Option E is incorrect because OVN-Kubernetes fully supports Kubernetes NetworkPolicy objects, translating them into OVN ACLs.

Exam trap

EX280 often tests the confusion between OVN-Kubernetes and OpenShift SDN features, such as whether EgressIP is supported natively or whether iptables is the primary mechanism.

Full explanation →

74

MCQeasy

Which component in OpenShift is responsible for watching PersistentVolumeClaims and dynamically provisioning PersistentVolumes when supported by a StorageClass?

A.kube-scheduler

B.crio

C.etcd

D.kube-controller-manager

AnswerD

The kube-controller-manager runs the PersistentVolume controller, which watches PersistentVolumeClaims and triggers dynamic provisioning through the StorageClass's provisioner when no matching PersistentVolume exists. This satisfies the stem's requirement for the component that watches PVCs and provisions PersistentVolumes dynamically.

Why this answer

The kube-controller-manager runs the PersistentVolume controller, which watches for PersistentVolumeClaims that reference a StorageClass with a provisioner and dynamically creates matching PersistentVolumes. This is the component that implements dynamic provisioning in both Kubernetes and OpenShift. Without it, PVCs would remain Pending unless an admin manually pre-provisioned a PV.

Exam trap

EX280 often tests whether candidates attribute dynamic provisioning to the scheduler or etcd — the correct answer is always kube-controller-manager, which hosts the PersistentVolume controller.

How to eliminate wrong answers

Option A is wrong because kube-scheduler only decides which node a pod runs on — it does not create or bind storage volumes. Option B is wrong because CRI-O is the container runtime that pulls images and runs containers; it has no role in storage provisioning. Option C is wrong because etcd is the distributed key-value store that persists cluster state — it stores PV/PVC objects but does not act on them.

Full explanation →

75

MCQhard

An administrator has modified a KubeletConfig resource to adjust the pod eviction thresholds on worker nodes. After applying the change, the administrator observes that some worker nodes are updating while others belonging to a custom worker pool are not. What is the most likely reason?

A.KubeletConfig objects are only supported on control plane nodes in OpenShift 4.14.

B.The cluster storage size is insufficient to hold the new kubelet configuration.

C.The kubelet service must be manually restarted on every node using SSH.

D.The KubeletConfig's machineConfigPoolSelector does not match the labels on the custom MachineConfigPool.

AnswerD

The MachineConfigPoolSelector inside the KubeletConfig must match labels on the target MachineConfigPool. When it does not match the custom pool's labels, the Machine Config Operator never renders the change to those nodes, leaving them unupdated.

Why this answer

The KubeletConfig resource uses a machineConfigPoolSelector to target specific MachineConfigPools (MCPs). If the selector does not match the labels on the custom worker pool's MCP, the KubeletConfig will not be applied to nodes in that pool. This is the most likely reason why some nodes update while others do not.

Exam trap

EX280 often tests the misconception that KubeletConfig changes apply cluster-wide automatically, but they are scoped by machineConfigPoolSelector, and mismatched labels cause silent failures.

How to eliminate wrong answers

Option A is wrong because KubeletConfig objects are supported on worker nodes, not just control plane nodes. Option B is wrong because cluster storage size is unrelated to kubelet configuration updates. Option C is wrong because the Machine Config Operator automatically handles kubelet restarts; manual SSH restarts are not required.

Full explanation →

Page 1 of 6

All pages

Practice EX280 by domain

Target a specific domain to shore up weak areas.

User And RBAC Management Troubleshooting And Diagnostics Networking And Network Policies Cluster Installation And Management Security And SCC Storage And Persistent Volumes Application Deployment And Lifecycle

See all domains with question counts →