Red Hat Certified OpenShift Administrator (EX280, OpenShift Container Platform 4.14+) (EX280) EX280 Questions 76–150 | Page 2/6

Multi-Selectmedium

An administrator wants to verify node configuration application status. Which TWO indicators show that a MachineConfigPool has successfully finished applying a new MachineConfig? (Choose TWO)

Select 2 answers

A.The 'ClusterVersion' status reads 'Updating'.

B.The 'UpdatedMachineCount' equals the 'MachineCount' in the pool status.

C.The 'Updating' condition status is False.

D.The pool status condition 'Paused' is set to True.

E.The 'DegradedMachineCount' is greater than zero.

AnswersB, C

When UpdatedMachineCount matches MachineCount, every node in the pool has rendered and applied the current MachineConfig, confirming the rollout completed. This directly satisfies the stem's requirement for an indicator that the pool has finished applying the new configuration.

Why this answer

Option B is correct because in a MachineConfigPool status, when UpdatedMachineCount equals MachineCount, every node in the pool has rendered and applied the current MachineConfig, indicating the rollout has completed. Option C is correct because the pool's Updating condition being False means the MachineConfigOperator is no longer actively applying a new MachineConfig to the pool, which is the definitive signal that the update process has finished. Option A is incorrect because ClusterVersion status 'Updating' refers to the cluster version operator applying an OpenShift release update, not a MachineConfigPool applying a MachineConfig.

Option D is incorrect because a Paused condition set to True means the pool's rollout is intentionally halted, so it cannot indicate successful completion. Option E is incorrect because a DegradedMachineCount greater than zero indicates nodes failed to apply the configuration, which is the opposite of a successful application.

Exam trap

EX280 often tests the distinction between cluster-wide update status (ClusterVersion) and node-level configuration application status (MachineConfigPool). Candidates may incorrectly select 'ClusterVersion' status 'Updating' as an indicator of MachineConfigPool completion, confusing the two layers of update management.

Full explanation →

Multi-Selecteasy

Which TWO commands or tools can an administrator use to inspect cluster logs or events when troubleshooting node or pod issues? (Choose TWO)

Select 2 answers

A.oc adm cluster-logs --tail=all

B.oc logs <pod-name>

C.oc system-log dump

D.oc adm tail-events

E.oc get events

AnswersB, E

oc logs <pod-name> retrieves a container's stdout and stderr, exposing application crashes, misconfigurations, and startup failures. It satisfies the requirement by revealing what the pod itself reported, complementing cluster-level events when diagnosing why a workload is not running correctly.

Why this answer

Option B, `oc logs <pod-name>`, is correct because it retrieves the stdout/stderr container logs for a specific pod (with flags like `-c` for a container, `-f` to follow, or `--previous` for a crashed container), which is the primary way to inspect application-level output when troubleshooting a pod. Option E, `oc get events`, is correct because it lists Kubernetes Events in the current namespace (or with `-A`/`--all-namespaces`), showing scheduling failures, image pull errors, probe failures, and node-related warnings useful for diagnosing node or pod issues. Option A, `oc adm cluster-logs --tail=all`, is not a valid OpenShift command for this purpose.

Option C, `oc system-log dump`, is not a real `oc` subcommand for collecting logs. Option D, `oc adm tail-events`, is not a valid command; events are viewed with `oc get events` or `oc describe`.

Exam trap

The trap is selecting plausible-sounding but nonexistent `oc adm` subcommands (cluster-logs, system-log dump, tail-events) instead of the real, simple commands `oc logs` and `oc get events`.

Full explanation →

MCQmedium

A DeploymentConfig in OpenShift has a Rolling strategy defined. Which parameter in the strategy configuration controls the maximum number of pods that can be created above the desired replica count during the update?

A.interval

B.maxSurge

C.updatePeriodSeconds

D.maxUnavailable

AnswerB

maxSurge defines how many pods may exceed the desired replica count during a rolling update, controlling extra capacity created above the target. maxUnavailable instead governs how many pods may be simultaneously unavailable, so maxSurge is the parameter requested.

Why this answer

In OpenShift's DeploymentConfig Rolling strategy, maxSurge specifies the maximum number of pods that can be created beyond the desired replica count during an update. This allows the deployment to temporarily exceed the desired number of replicas to ensure zero downtime. For example, if replicas=3 and maxSurge=1, the deployment can have up to 4 pods at once.

This parameter is defined in the strategy's rollingParams section.

Exam trap

EX280 often tests the distinction between maxSurge and maxUnavailable in rolling updates, where candidates might confuse which parameter controls extra pods versus unavailable pods.

How to eliminate wrong answers

Option A is wrong because interval is not a valid parameter in the Rolling strategy; it is not used to control pod creation. Option C is wrong because updatePeriodSeconds specifies the time to wait between individual pod updates, not the number of extra pods. Option D is wrong because maxUnavailable controls how many pods can be unavailable during the update, which is the opposite of maxSurge.

Full explanation →

MCQmedium

You need to ensure that a specific ServiceAccount named 'builder-sa' in the 'cicd' project can use the 'privileged' SecurityContextConstraints. Which command accomplishes this?

A.oc annotate serviceaccount builder-sa scc=privileged -n cicd

B.oc adm policy add-scc-to-user privileged system:serviceaccount:cicd:builder-sa

C.oc set scc privileged --serviceaccount=builder-sa -n cicd

D.oc create rolebinding privileged-binding --clusterrole=privileged --serviceaccount=cicd:builder-sa

AnswerB

`oc adm policy add-scc-to-user` binds the SCC directly to the ServiceAccount's user identity, `system:serviceaccount:cicd:builder-sa`, satisfying the requirement that only `builder-sa` in the `cicd` project gains `privileged`. This grants the SCC via a RoleBinding rather than altering the SCC's own user list, which is the supported OpenShift mechanism.

Why this answer

`oc adm policy add-scc-to-user privileged system:serviceaccount:cicd:builder-sa` is the correct command to grant the 'privileged' SCC to the 'builder-sa' ServiceAccount in the 'cicd' project. It adds the ServiceAccount to the SCC's users list, allowing pods running as that SA to request privileged access.

Exam trap

EX280 often tests whether candidates know the specific `oc adm policy add-scc-to-user` syntax for SCC assignment — the trap is confusing SCC assignment with RBAC RoleBindings or attempting to use annotations or `oc set` commands.

How to eliminate wrong answers

Option A is wrong because annotating a ServiceAccount with scc=privileged does not grant SCC permissions — SCCs are not selected via annotations on ServiceAccounts. Option C is wrong because `oc set scc` is not a valid command for assigning SCCs to ServiceAccounts. Option D is wrong because creating a RoleBinding to a ClusterRole named 'privileged' does not grant SCC access — SCCs are not RBAC ClusterRoles and require the `oc adm policy add-scc-to-user` or `add-scc-to-group` commands.

Full explanation →

Multi-Selecteasy

Which TWO namespaces are standard system namespaces in OpenShift 4.14 that contain core cluster operators and platform components? (Choose TWO)

Select 2 answers

A.openshift-user-workloads

B.kube-public-custom

C.openshift-cluster-version

D.openshift-machine-config-operator

E.openshift-custom-catalog

AnswersC, D

The openshift-cluster-version namespace hosts the Cluster Version Operator, which reconciles the cluster's desired release version against actual state. It is a standard platform namespace present in every OpenShift 4.14 installation, satisfying the stem's requirement for a system namespace containing core cluster operators.

Why this answer

Option C, openshift-cluster-version, is correct because it hosts the Cluster Version Operator (CVO) deployment, which reconciles the ClusterVersion resource and manages the update lifecycle of core cluster operators in OpenShift 4.14. Option D, openshift-machine-config-operator, is correct because it contains the Machine Config Operator, a core platform operator responsible for managing MachineConfig objects and node configuration (e.g., kubelet, CRI-O, and OS-level settings) across the cluster. Option A, openshift-user-workloads, is not a standard system namespace; user workload monitoring uses openshift-user-workload-monitoring, and application workloads typically run in user-created projects.

Option B, kube-public-custom, is not a standard OpenShift namespace; the built-in one is kube-public, and the '-custom' suffix denotes a non-default name. Option E, openshift-custom-catalog, is not a standard namespace; catalog sources are typically placed in openshift-marketplace or user-defined namespaces.

Exam trap

The trap is picking plausible-sounding but non-existent namespaces like openshift-user-workloads or openshift-custom-catalog — candidates must know the actual standard system namespaces in OpenShift 4.14.

Full explanation →

MCQmedium

An administrator wants to view the available recommended upgrade paths for an OpenShift 4.14 cluster from the command line. Which command should the administrator run?

A.oc adm upgrade

B.oc describe upgrade-channel

C.oc get clusterversion --recommendations

D.oc cluster-version check

AnswerA

The oc adm upgrade command queries cluster version information, listing the recommended and conditional update paths available for the current 4.14 release. It reads the update channel and returns valid target versions without performing the upgrade itself.

Why this answer

`oc adm upgrade` displays the current cluster version and the available recommended upgrade paths, including the next minor/major versions the cluster can move to. Running it without arguments shows the upgrade status and recommendations, making it the correct command to view upgrade paths from the CLI.

Exam trap

The trap is inventing flags or subcommands (--recommendations, upgrade-channel, cluster-version check) that sound plausible but do not exist; the real command is simply `oc adm upgrade`.

How to eliminate wrong answers

Option B is wrong because `oc describe upgrade-channel` is not a valid command — there is no UpgradeChannel resource in OpenShift; upgrade channels are configured via the ClusterVersion object's spec.channel field. Option C is wrong because `oc get clusterversion --recommendations` is not a valid flag; while `oc get clusterversion` shows version info, the recommendations come from `oc adm upgrade`. Option D is wrong because `oc cluster-version check` is not a real command — cluster version information is retrieved via `oc get clusterversion` or `oc adm upgrade`.

Full explanation →

MCQhard

An administrator needs to prune or reclaim dangling VolumeSnapshotContent objects whose parent VolumeSnapshots have already been deleted, but the reclaim policy was set incorrectly. How can this be resolved?

A.Recreate the deleted VolumeSnapshot with the exact same UID.

B.Restart the snapshot-controller deployment.

C.Run 'oc prune snapshots --force'.

D.Manually delete the orphaned VolumeSnapshotContent object or remove its finalizers if stuck.

AnswerD

When a VolumeSnapshot is deleted but its VolumeSnapshotContent retains a Retain reclaim policy, the content object becomes orphaned. Deleting it directly, or stripping finalizers when deletion hangs, reclaims the dangling resource and clears the stuck state.

Why this answer

Orphaned VolumeSnapshotContent objects left behind when their parent VolumeSnapshot is deleted (due to a misconfigured deletionPolicy of Retain instead of Delete) must be cleaned up manually. You delete the VolumeSnapshotContent object directly, or if it is stuck due to finalizers, remove the finalizers (e.g., snapshot.storage.kubernetes.io/volumesnapshotcontent-bound-protection) and then delete it.

Exam trap

EX280 often tests finalizer behavior — candidates assume restarting controllers or recreating objects fixes orphaned resources instead of manually clearing finalizers.

How to eliminate wrong answers

Option A is wrong because recreating a VolumeSnapshot with the same UID is impossible — UIDs are system-assigned and immutable, and the original snapshot is gone. Option B is wrong because restarting the snapshot-controller does not remove orphaned content objects; it only re-syncs state and will not delete retained content. Option C is wrong because oc prune snapshots --force is not a valid OpenShift command; there is no such prune subcommand for snapshots.

Full explanation →

MCQeasy

Which default OpenShift cluster role grants full administrative privileges to manage all resources within a specific project when bound via a RoleBinding?

A.edit

B.view

C.cluster-admin

D.admin

AnswerD

The `admin` cluster role grants full management of resources within a project, including roles and bindings, when bound through a RoleBinding. It is the default role intended for project administrators, unlike `edit` or `view`, which omit permission management.

Why this answer

The 'admin' cluster role is a default OpenShift role that grants full read/write access to most resources within a project, including the ability to manage roles and rolebindings inside that namespace. When bound via a RoleBinding (namespace-scoped), it confers project-level administrative rights without granting cluster-wide privileges. This is distinct from 'cluster-admin', which is a cluster-scoped role granting unrestricted access across all projects and cluster resources.

Exam trap

EX280 often tests the distinction between 'admin' (namespace-scoped full control) and 'cluster-admin' (cluster-wide full control) — candidates who equate 'full administrative privileges' with cluster-admin miss the 'within a specific project' qualifier.

How to eliminate wrong answers

Option A is wrong because 'edit' allows create/update/delete on most workload resources but explicitly denies access to roles, rolebindings, and resource quotas — it is not full administrative control. Option B is wrong because 'view' is read-only and cannot modify any resource. Option C is wrong because 'cluster-admin' is a cluster-scoped role that grants full control over the entire cluster, not just a specific project, and binding it via a RoleBinding is unusual and over-privileged for the stated requirement.

Full explanation →

MCQmedium

You need to verify whether a particular ServiceAccount in your project has permissions to read Secrets. Which command tests this authorization?

A.oc auth can-i get secrets --as=system:serviceaccount:<namespace>:<serviceaccount-name>

B.oc describe rolebinding --serviceaccount=<serviceaccount-name>

C.oc check secrets --serviceaccount=<serviceaccount-name>

D.oc adm verify-sa <serviceaccount-name>

AnswerA

`oc auth can-i` performs a SubjectAccessReview against the API server, returning yes or no for the specified verb and resource. The `--as` flag impersonates the ServiceAccount, so the check reflects that account's actual RBAC bindings in the namespace, directly answering whether it can read Secrets.

Why this answer

`oc auth can-i get secrets --as=system:serviceaccount:<namespace>:<serviceaccount-name>` submits a SubjectAccessReview to the API server impersonating the named service account, returning the effective allow/deny decision for the `get` verb on `secrets`. This is the only command among the options that actually evaluates RBAC rather than merely displaying configuration. It works regardless of whether the permission comes from a RoleBinding, ClusterRoleBinding, or an aggregated role.

Exam trap

EX280 often tests whether candidates pick a command that merely displays role bindings instead of one that actually evaluates effective permissions — only `oc auth can-i --as=system:serviceaccount:...` performs the authorization check.

How to eliminate wrong answers

Option B is wrong because `oc describe rolebinding` is not a valid subcommand form for querying a specific SA's permissions — you would need to list rolebindings and inspect each one, and even then you'd only see the binding, not the resolved effective permission. Option C is wrong because `oc check secrets` is not a real OpenShift CLI command; it is a fabricated verb. Option D is wrong because `oc adm verify-sa` does not exist — there is no such subcommand for verifying service account authorization in the oc CLI.

Full explanation →

Multi-Selecthard

An administrator is configuring automated node remediation and scaling in OpenShift 4.14. Which THREE objects or custom resources are involved in machine management, autoscaling, and health checking? (Choose THREE)

Select 3 answers

A.MachineSet

B.ClusterVersion

C.OperatorGroup

D.ClusterAutoscaler

E.MachineHealthCheck

AnswersA, D, E

MachineSet is a cluster API resource that maintains a desired number of Machines for a compute pool, providing the declarative foundation for scaling and remediation. MachineHealthCheck then deletes unhealthy Machines, prompting the MachineSet to recreate them.

Why this answer

MachineSet (A) is correct because it is the OpenShift Machine API resource that maintains a desired number of Machine replicas, enabling scaling and replacement of nodes within a cluster. ClusterAutoscaler (D) is correct because it is the custom resource that automatically adjusts the size of MachineSets (via MachineAutoscaler) based on pending pods and node utilization. MachineHealthCheck (E) is correct because it defines conditions for detecting unhealthy nodes and triggers remediation by deleting the Machine so the MachineSet recreates it.

ClusterVersion (B) is not involved in node remediation or scaling; it manages cluster version and update status. OperatorGroup (C) is an OLM resource that scopes operator installations to namespaces and has no role in machine management, autoscaling, or health checking.

Exam trap

EX280 often tests the distinction between machine management resources (MachineSet, ClusterAutoscaler, MachineHealthCheck) and unrelated cluster resources like ClusterVersion and OperatorGroup, causing candidates to select incorrect options.

Full explanation →

MCQmedium

A cluster administrator has created a custom ClusterRole named 'pod-debugger' with permissions to execute commands in pods. They want to ensure that only users in the 'development' group can utilize this role within the 'app-dev' project. How should they configure this?

A.Modify the 'pod-debugger' ClusterRole directly to include a namespace selector for 'app-dev'.

B.Create a Role in the 'app-dev' namespace and assign it to the 'pod-debugger' subject.

C.Create a RoleBinding in the 'app-dev' namespace referencing the 'pod-debugger' ClusterRole and the 'development' group.

D.Create a ClusterRoleBinding for the 'development' group pointing to 'pod-debugger'.

AnswerC

A RoleBinding in the 'app-dev' namespace grants the 'pod-debugger' ClusterRole's permissions solely within that project, satisfying the constraint that only the 'development' group may execute commands in pods there. Unlike a ClusterRoleBinding, which would extend access cluster-wide, this namespace-scoped binding correctly limits the group's permissions to 'app-dev'.

Why this answer

A RoleBinding can reference a ClusterRole, and when it does, the permissions defined in the ClusterRole are granted only within the namespace where the RoleBinding is created. By creating a RoleBinding in the 'app-dev' namespace that references the 'pod-debugger' ClusterRole and binds it to the 'development' group, the administrator ensures that only members of that group can use the role's permissions within that specific project. This is the standard OpenShift/Kubernetes pattern for scoping cluster-defined roles to a single namespace.

Exam trap

EX280 often tests the misconception that ClusterRoles can be namespace-scoped or that ClusterRoleBindings can be limited to a namespace; the key is remembering that only RoleBindings can scope a ClusterRole to a namespace.

How to eliminate wrong answers

Option A is wrong because ClusterRoles are cluster-scoped and do not support namespace selectors; they cannot be restricted to a specific namespace by modifying the ClusterRole itself. Option B is wrong because creating a Role in 'app-dev' and assigning it to the 'pod-debugger' subject is conceptually backwards—the subject should be the 'development' group, and the Role should define permissions, not be assigned to a ClusterRole. Option D is wrong because a ClusterRoleBinding grants permissions across the entire cluster, not just within the 'app-dev' namespace, which violates the requirement to limit access to that project.

Full explanation →

MCQhard

An administrator suspects a pod named 'cache-0' in namespace 'data' is being evicted due to node memory pressure. They want to confirm the eviction reason and see the kubelet's decision. Which command most directly provides the eviction evidence?

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

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

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

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

AnswerB

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

Why this answer

The kubelet records an eviction by updating the pod's status with reason Evicted and a message identifying the exhausted resource. Querying those status fields with JSONPath or reading the pod YAML yields unambiguous evidence, whereas logs, node conditions, and metrics each describe adjacent signals without tying the specific pod's termination to memory pressure.

Exam trap

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

Full explanation →

Multi-Selectmedium

An administrator is configuring authentication in OpenShift. Which TWO of the following identity provider types are natively supported by the OpenShift OAuth server? (Choose TWO)

Select 2 answers

A.HTPasswd

B.LDAP

C.CustomDatabaseProvider

D.LocalFileAuthService

E.ActiveDirectoryNativeProtocol

AnswersA, B

HTPasswd is a natively supported OpenShift identity provider that validates credentials against a locally generated htpasswd file. It satisfies the stem's native-support constraint, making it suitable for small or test clusters without external directory dependencies.

Why this answer

Option A (HTPasswd) is correct because the OpenShift OAuth server natively supports the HTPasswd identity provider, which validates users against a flat file of bcrypt-hashed credentials generated with htpasswd and referenced via the htpasswd secret. Option B (LDAP) is correct because OpenShift ships a built-in LDAP identity provider that binds and searches an LDAPv3 directory (for example via ldap:// or ldaps:// URLs) using configured bindDN, bindPassword, and attribute mappings. The remaining options are not real OpenShift identity provider types: CustomDatabaseProvider and LocalFileAuthService are fabricated names, and ActiveDirectoryNativeProtocol is not a provider — Active Directory is integrated through the LDAP identity provider rather than a dedicated native protocol.

Exam trap

EX280 often tests the list of supported identity providers, and candidates may mistakenly think that any database or file-based auth is natively supported, or confuse Active Directory with a separate provider when it's actually accessed via LDAP.

Full explanation →

MCQhard

An administrator needs to deploy a Helm chart into an OpenShift cluster while overriding specific chart values using a local YAML file. Which Helm CLI command should be executed?

A.helm push my-chart --override overrides.yaml

B.helm install my-release my-chart --values overrides.yaml

C.helm deploy my-release my-chart --values overrides.yaml

D.helm apply -f overrides.yaml my-chart

AnswerB

The --values flag supplies a local YAML file whose keys override the chart's default values during installation, which is exactly the stated requirement. helm install my-release my-chart --values overrides.yaml therefore deploys the chart with those overrides applied.

Why this answer

The Helm CLI command to install a chart with value overrides from a file is 'helm install <release-name> <chart> --values <file>'. The '--values' (or '-f') flag loads a YAML file whose keys override the chart's default values.yaml, and 'helm install' performs the initial deployment into the cluster.

Exam trap

EX280 often tests whether candidates confuse 'helm install' with kubectl-style verbs like 'apply' or 'deploy', or misremember the flag as '--override' instead of '--values'/'-f'.

How to eliminate wrong answers

Option A is wrong because 'helm push' uploads a chart to an OCI registry and does not accept '--override' or install charts. Option C is wrong because 'helm deploy' is not a Helm subcommand; the correct verb is 'install' (or 'upgrade' for existing releases). Option D is wrong because 'helm apply -f' is not a Helm command — that syntax resembles kubectl apply, and Helm does not use 'apply' for chart installation.

Full explanation →

MCQmedium

An OpenShift administrator needs to trigger a rollback of a Deployment to its previous working revision after a failed update. Which oc command should be used?

A.oc update deployment/my-app --revision=previous

B.oc rollout undo deployment/my-app

C.oc revert deployment/my-app

D.oc rollback deployment/my-app

AnswerB

oc rollout undo reverts the Deployment to its previous revision, restoring the last working state after the failed update. It directly satisfies the rollback requirement by targeting the Deployment's revision history rather than editing or recreating the resource.

Why this answer

The correct command to rollback a Deployment to its previous revision is oc rollout undo deployment/my-app. This command reverts the Deployment to the last successful revision.

Exam trap

EX280 often tests the correct syntax for rollback operations, so candidates must remember that 'oc rollout undo' is the command, not 'oc rollback' or 'oc revert'.

How to eliminate wrong answers

Option A is wrong because oc update deployment/my-app --revision=previous is not a valid command; oc update is used for updating resources but not for rollbacks. Option C is wrong because oc revert deployment/my-app is not a valid command; there is no revert subcommand. Option D is wrong because oc rollback deployment/my-app is not a valid command; the correct subcommand is rollout undo.

Full explanation →

MCQeasy

Which access mode specifies that a volume can be mounted as read-write by a single node?

A.WriteOnceMany

B.ReadOnlyMany

C.ReadWriteOnce

D.ReadWriteMany

AnswerC

ReadWriteOnce permits a volume to be mounted as read-write by a single node at a time, which is exactly the constraint the stem specifies. Unlike ReadWriteMany, which allows concurrent read-write mounts across multiple nodes, ReadWriteOnce scopes write access to one node, making it the precise match for this requirement.

Why this answer

ReadWriteOnce (RWO) is the access mode that allows a PersistentVolume to be mounted as read-write by a single node at a time. This is the most common mode for block-backed storage such as AWS EBS, GCE PD, and Ceph RBD, where the underlying device cannot be safely shared across nodes. It does not restrict the number of pods on that node — multiple pods on the same node can share the volume.

Exam trap

EX280 often tests the distinction between 'single node' and 'single pod' — candidates incorrectly assume RWO limits the volume to one pod, when it actually limits it to one node, allowing multiple pods on that node to share it.

How to eliminate wrong answers

Option A is wrong because 'WriteOnceMany' is not a valid Kubernetes access mode — the four valid modes are RWO, ROX, RWX, and RWOP. Option B is wrong because ReadOnlyMany allows many nodes to mount the volume read-only, which is the opposite of read-write single-node. Option D is wrong because ReadWriteMany allows many nodes to mount the volume read-write simultaneously, which requires shared filesystem storage like NFS or CephFS, not block storage.

Full explanation →

MCQhard

You are integrating an external LDAP identity provider. Which secret must be created to store the bind password for the LDAP server?

A.A secret in the 'openshift-authentication' namespace

B.A project-level secret in the target application namespace

C.A secret in the 'kube-system' namespace

D.A generic secret in the 'openshift-config' namespace

AnswerD

A generic secret in the 'openshift-config' namespace satisfies the requirement to store the LDAP bind password for an external identity provider. OpenShift's OAuth configuration references this secret by name, so the bind password must reside there for the identity provider to authenticate against the LDAP server during bind operations.

Why this answer

When configuring an LDAP identity provider in OpenShift, the bind password must be stored in a generic Secret created in the 'openshift-config' namespace. The OAuth custom resource (cluster-scoped) references this secret via the ldap.bindPassword.name field, and the openshift-config namespace is the designated location for cluster-wide identity provider configuration.

Exam trap

EX280 often tests the namespace boundary for cluster-wide configuration — candidates assume the secret goes in 'openshift-authentication' (where the OAuth server runs) rather than 'openshift-config' (where the OAuth CR and its referenced secrets live).

How to eliminate wrong answers

Option A is wrong because 'openshift-authentication' hosts the OAuth server pods and its own runtime secrets, not the user-supplied LDAP bind password — placing it there means the OAuth CR cannot reference it. Option B is wrong because identity providers are cluster-scoped, not project-scoped; a secret in an application namespace is invisible to the cluster OAuth configuration. Option C is wrong because 'kube-system' is a Kubernetes system namespace for control-plane components and is not where OpenShift expects identity provider secrets.

Full explanation →

MCQeasy

An administrator needs to inspect all StorageClasses available in an OpenShift cluster using the OpenShift CLI. Which command should be executed?

A.oc describe storageclasses

B.oc get pvc

C.oc get sc

D.oc get pv

AnswerC

`oc get sc` queries the cluster's StorageClass API resource, returning every StorageClass definition cluster-wide. The `sc` short name maps directly to `storageclasses.storage.k8s.io`, satisfying the requirement to inspect all available StorageClasses via the OpenShift CLI without namespace scoping, since StorageClasses are cluster-scoped objects.

Why this answer

The command 'oc get sc' is the correct and concise way to list all StorageClasses in an OpenShift cluster. 'sc' is the standard abbreviation for 'storageclasses' in the OpenShift CLI, and 'oc get' retrieves the list of resources. This command provides a quick overview of available StorageClasses, which is essential for administrators managing persistent storage.

Exam trap

EX280 often tests the difference between similar resource types like StorageClasses, PersistentVolumes, and PersistentVolumeClaims. Candidates may confuse the abbreviations or select 'oc get pv' thinking it lists StorageClasses, but 'pv' stands for PersistentVolumes.

How to eliminate wrong answers

Option A is wrong because 'oc describe storageclasses' requires a specific StorageClass name to describe; without a name, it will error or list all with verbose details, but it is not the standard command for listing. Option B is wrong because 'oc get pvc' lists PersistentVolumeClaims, not StorageClasses. Option D is wrong because 'oc get pv' lists PersistentVolumes, not StorageClasses.

Full explanation →

Multi-Selectmedium

An administrator is managing service accounts and wants to understand how tokens work in OpenShift 4.14+. Which TWO statements are correct regarding ServiceAccount tokens in this version? (Choose TWO)

Select 2 answers

A.Service accounts are now deprecated in favor of OAuth user objects.

B.Tokens must be stored in plaintext ConfigMaps for pods to read them.

C.Service accounts can no longer authenticate against the Kubernetes API server.

D.Long-lived API tokens are no longer automatically created as secrets when a new ServiceAccount is created.

E.Bound service account tokens are ephemeral and time-bound by default using TokenRequest API.

AnswersD, E

OpenShift 4.14 stopped auto-generating long-lived token secrets for new ServiceAccounts, so no legacy secret-backed token appears. This satisfies the stem's version-specific constraint: administrators must now create tokens explicitly via TokenRequest rather than relying on automatic secret creation.

Why this answer

Option D is correct because starting with OpenShift 4.14 (aligned with Kubernetes 1.24+ behavior), the legacy behavior of automatically generating a long-lived token Secret alongside every new ServiceAccount was removed, so no token Secret is created unless explicitly requested. Option E is correct because the modern mechanism uses the TokenRequest API to issue bound service account tokens that are audience-scoped, time-bound (expiring, typically via projected volumes), and ephemeral rather than permanent. Option A is wrong because ServiceAccounts remain a core, fully supported identity mechanism and are not deprecated in favor of OAuth user objects.

Option B is wrong because tokens are delivered via projected volumes or the TokenRequest API, not stored in plaintext ConfigMaps. Option C is wrong because ServiceAccounts still authenticate to the Kubernetes API server using their bound tokens.

Exam trap

EX280 often tests the misconception that service accounts are deprecated or that tokens are still automatically created as Secrets; candidates must remember that bound tokens are now ephemeral and generated on-demand.

Full explanation →

MCQeasy

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

A.oc get pvc --all-namespaces

B.oc describe storage-cluster

C.oc adm storage pending

D.oc get pv --status=Pending

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

Multi-Selecthard

An administrator is auditing Security Context Constraints and wants to identify which settings can be controlled within a custom SCC definition. Which THREE fields are valid configuration options inside an SCC resource? (Choose THREE)

Select 3 answers

A.routeAdmissionLimit

B.networkPolicyMode

C.requiredDropCapabilities

D.allowPrivilegedContainer

E.volumes

AnswersC, D, E

requiredDropCapabilities is a valid SCC field specifying Linux capabilities forcibly removed from containers, such as NET_RAW. It is a genuine configuration option, satisfying the stem's requirement to identify fields controllable within a custom SCC definition.

Why this answer

Option C, requiredDropCapabilities, is a valid SCC field that lists Linux capabilities (e.g., KILL, MKNOD, SYS_ADMIN) which are dropped from all containers, and it is commonly used to enforce a baseline of reduced privileges. Option D, allowPrivilegedContainer, is a valid boolean SCC field that determines whether a pod may request a privileged container, directly controlling a key privilege-escalation vector. Option E, volumes, is a valid SCC field that enumerates the volume plugin types (such as configMap, emptyDir, hostPath, persistentVolumeClaim) a pod is permitted to use, restricting host-level storage access.

The unmarked options do not belong because routeAdmissionLimit and networkPolicyMode are not fields in the OpenShift SecurityContextConstraints API; route and network policy behavior is governed by other resources like Route and NetworkPolicy objects, not by SCCs.

Exam trap

EX280 often tests the misconception that SCCs include networking or routing fields, when they are strictly about pod security contexts.

Full explanation →

MCQhard

An administrator must allow the ServiceAccount 'report-sa' in the 'metrics' namespace to list nodes cluster-wide, but must not grant any other cluster-level access. Which command accomplishes this?

A.oc adm policy add-cluster-role-to-user cluster-reader -z report-sa -n metrics

B.oc adm policy add-cluster-role-to-user node-viewer -z report-sa -n metrics

C.oc adm policy add-cluster-role-to-user system:node-reader -z report-sa -n metrics

D.oc create clusterrole node-lister --verb=list --resource=nodes, then oc adm policy add-cluster-role-to-user node-lister -z report-sa -n metrics

AnswerD

Creating a custom ClusterRole with only the list verb on nodes and binding it to the service account via 'add-cluster-role-to-user' gives exactly the required cluster-scoped permission. Because nodes are cluster-scoped, a ClusterRole and ClusterRoleBinding are necessary, and the narrow verb list enforces least privilege.

Why this answer

Only a custom ClusterRole containing the single list verb on nodes, bound with a ClusterRoleBinding to the service account, satisfies the constraint. Built-in read-oriented roles like 'cluster-reader' are too broad, and no default node-lister role exists. The 'oc adm policy add-cluster-role-to-user' command with the '-z' flag correctly targets the service account.

Exam trap

The trap here is assuming a built-in read role like cluster-reader is the least-privilege choice for node visibility, when it actually grants read access to almost everything cluster-wide.

Full explanation →

MCQhard

An administrator has added a new custom worker MachineConfigPool and wants existing worker nodes to be migrated into this new pool based on specific labels. How does an administrator move a node from the default worker pool to a custom MachineConfigPool?

A.Modify the cluster-wide node migration ConfigMap.

B.Apply the corresponding role label to the node (e.g., 'oc label node worker-01 node-role.kubernetes.io/custom-worker='').

C.Edit the MachineSet to change its target pool name.

D.Run 'oc adm migrate node worker-01 --to-pool=custom-worker'.

AnswerB

MachineConfigPool membership is driven by node role labels, not manual assignment. Applying the custom pool's role label to a node causes the MachineConfigOperator to move it out of the default worker pool into the custom pool automatically.

Why this answer

To move a node from the default worker pool to a custom MachineConfigPool, you apply the corresponding role label to the node. For example, labeling a node with 'node-role.kubernetes.io/custom-worker=' will make the MachineConfigOperator include it in the custom-worker pool. This is the standard method for node pool migration.

Exam trap

EX280 often tests the misconception that nodes are moved between pools by editing MachineSets or using a migration command, when in fact labeling the node is the correct method.

How to eliminate wrong answers

Option A is wrong because there is no cluster-wide node migration ConfigMap; node pool membership is determined by labels. Option C is wrong because editing the MachineSet to change its target pool name is not how nodes are moved; MachineSets define the desired state for machines, but existing nodes are moved by labeling. Option D is wrong because 'oc adm migrate node' is not a valid command; there is no such migration command.

Full explanation →

Multi-Selectmedium

Which TWO authentication methods are supported by the OpenShift OAuth server?

Select 2 answers

A.Htpasswd

B.Local file system user list

C.LDAP

D.Custom SSH keys

E.Direct database connection

AnswersA, C

OpenShift's OAuth server ships an identity provider that authenticates users against an htpasswd file of bcrypt-hashed credentials. It is a supported method for validating usernames and passwords, satisfying the question's requirement for a native OpenShift authentication mechanism.

Why this answer

The OpenShift OAuth server supports the Htpasswd identity provider (option A), which validates credentials against a flat file of bcrypt-hashed username/password entries, and the LDAP identity provider (option C), which binds to an external LDAP directory (e.g., Active Directory or OpenLDAP) to authenticate users. These are two of the built-in identity provider types configured via the OAuth custom resource, alongside others like BasicAuth, RequestHeader, GitHub, GitLab, Google, Keystone, and OpenID Connect. Option B is incorrect because OpenShift does not offer a generic 'local file system user list' provider — local users are managed through Htpasswd files or the OAuth access tokens, not by enumerating OS users.

Option D is incorrect because SSH keys are used for node/SSH access, not for OAuth authentication to the API. Option E is incorrect because the OAuth server does not connect directly to a database for user authentication; directory-based auth is done via LDAP or similar providers.

Exam trap

EX280 often tests whether candidates know the supported OAuth identity providers, so the trap is selecting plausible-sounding but unsupported methods like 'local file system user list' or 'direct database connection' instead of the actual providers HTPasswd and LDAP.

Full explanation →

100

MCQeasy

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

A.oc get nodes --metrics

B.oc adm top nodes

C.oc cluster-capacity

D.oc describe nodes --usage

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

101

MCQeasy

An application pod needs to discover other pods behind the same headless service. What characteristic defines a headless service?

A.It automatically creates an external Route resource.

B.It has spec.clusterIP set to None.

C.It does not have any selector defined in its specification.

D.It disables internal container DNS resolution entirely.

AnswerB

Setting spec.clusterIP to None tells Kubernetes not to allocate a virtual IP or load-balance, so DNS returns individual pod IPs directly. Clients then discover every backing pod themselves, which is precisely the discovery behaviour the application requires behind the headless service.

Why this answer

A headless service is defined by setting `spec.clusterIP` to `None`, which tells Kubernetes not to allocate a virtual IP. Instead, DNS returns the individual pod IPs associated with the service, allowing direct pod discovery. This is commonly used for stateful applications where clients need to connect to specific pods.

Exam trap

EX280 often tests the definition of a headless service, and candidates may incorrectly think it requires no selector or that it disables DNS, rather than focusing on the `clusterIP: None` setting.

How to eliminate wrong answers

Option A is wrong because headless services do not create external Routes; Routes are an OpenShift resource for exposing services externally. Option C is wrong because a headless service can still have a selector; the key characteristic is the `clusterIP: None`, not the absence of a selector. Option D is wrong because headless services do not disable DNS resolution; they change the DNS response to return pod IPs instead of a single service IP.

Full explanation →

102

MCQeasy

An administrator wants to expose a Deployment via a NodePort service. What is the default port range allocated for NodePort services in OpenShift if not explicitly configured otherwise?

A.1024-65535

B.80-443

C.30000-32767

D.8000-9000

AnswerC

OpenShift's default NodePort allocation is 30000-32767, inherited from Kubernetes' service-node-port-range. Unless the administrator edits that range in the kubelet or apiserver configuration, every NodePort service receives a port within these bounds, so this range is the correct default.

Why this answer

OpenShift (like Kubernetes) allocates NodePort services from the default range 30000–32767 unless the cluster is explicitly configured otherwise. This range is defined by the `service-node-port-range` parameter in the kube-apiserver configuration. When you create a NodePort service without specifying a nodePort, the controller picks a free port from this range.

Exam trap

EX280 often tests memorization of the default NodePort range — candidates confuse it with the ephemeral port range or the full non-privileged range (1024–65535).

How to eliminate wrong answers

Option A is wrong because 1024–65535 is the full range of non-privileged ports, not the NodePort allocation range — NodePorts are deliberately restricted to a high range to avoid collisions with system services. Option B is wrong because 80–443 are standard HTTP/HTTPS ports used by the router or application containers, not NodePort allocations. Option D is wrong because 8000–9000 is an arbitrary application port range with no special meaning in Kubernetes/OpenShift NodePort allocation.

Full explanation →

103

Multi-Selectmedium

An administrator wants to prevent automatic updates for an Operator installed via OLM while still allowing manual installation of new versions when desired. Which TWO actions or configurations should be performed? (Choose TWO)

Select 2 answers

A.Approve generated InstallPlans selectively using 'oc patch installplan' or via the web console when an update is desired.

B.Scale the OLM operator pods to zero.

C.Delete the CatalogSource resource entirely.

D.Set 'spec.installPlanApproval: Manual' in the Operator Subscription.

E.Annotate the Subscription with 'olm.openshift.io/block-updates=true'.

AnswersA, D

Selectively approving generated InstallPlans satisfies the manual-upgrade constraint: OLM creates an InstallPlan for each new version but leaves it unapproved, so no update proceeds until you patch its `approved` field to true. This preserves the existing Operator version while permitting deliberate installation when required.

Why this answer

Option D is correct because setting spec.installPlanApproval: Manual on the Operator's Subscription tells OLM to create InstallPlans for new versions but not apply them automatically, which is exactly the mechanism for preventing automatic updates while retaining the ability to upgrade later. Option A is correct because with Manual approval, each generated InstallPlan must be explicitly approved, either by patching it (e.g., oc patch installplan <name> --type merge -p '{"spec":{"approved":true}}') or by clicking Approve in the OpenShift web console, which is how an administrator manually installs a new version when desired. Option B is wrong because scaling OLM operator pods to zero disables the entire Operator Lifecycle Manager and would break InstallPlan generation and approval rather than selectively pausing updates.

Option C is wrong because deleting the CatalogSource removes the source of available Operator versions and would prevent discovering or installing new versions at all. Option E is wrong because olm.openshift.io/block-updates is not a valid OLM Subscription annotation for controlling update approval; the supported control is the installPlanApproval field.

Exam trap

EX280 often tests the difference between disabling OLM entirely (scaling down, deleting CatalogSource) versus selectively gating updates via installPlanApproval: Manual — candidates pick destructive options instead of the targeted configuration.

Full explanation →

104

MCQmedium

An administrator wants to pause rollouts on a DeploymentConfig named backend-api to make multiple configuration changes without triggering intermediate builds or rollouts. Which command pauses the rollout?

A.oc patch dc/backend-api --type=json -p='[{"op": "add", "path": "/spec/paused", "value": true}]'

B.oc suspend dc/backend-api

C.oc stop rollout dc/backend-api

D.oc rollout pause dc/backend-api

AnswerD

The oc rollout pause command with the dc/backend-api resource halts the DeploymentConfig's rollout process, letting the administrator apply multiple configuration changes without triggering intermediate builds or rollouts. Resuming later applies changes in a single coordinated rollout.

Why this answer

The 'oc rollout pause dc/backend-api' command sets spec.paused=true on the DeploymentConfig, which halts the rollout controller from creating new ReplicationControllers or scaling them during the pause window. This is the documented, first-class CLI verb for pausing rollouts and is the intended administrative action before making multiple template or trigger changes.

Exam trap

EX280 often tests whether candidates invent non-existent oc subcommands like 'suspend' or 'stop rollout' instead of recognizing the correct 'oc rollout pause' verb.

How to eliminate wrong answers

Option A is wrong because while patching spec.paused via JSON patch technically achieves the same state, it is not the standard command the question asks for and is error-prone (the path may already exist, requiring 'replace' instead of 'add'). Option B is wrong because 'oc suspend' is not a valid oc subcommand for DeploymentConfigs — suspend is a CronJob concept. Option C is wrong because 'oc stop rollout' does not exist; the correct verb is 'pause' (and its counterpart 'resume').

Full explanation →

105

MCQmedium

A developer deploys a headless service (ClusterIP set to None) in OpenShift. What is the primary characteristic of a headless service?

A.It prevents any external routes from binding to the service.

B.It routes traffic exclusively via NodePort across worker nodes.

C.It does not allocate a ClusterIP, and DNS returns the individual pod IPs directly.

D.It provisions an external cloud load balancer automatically.

AnswerC

With clusterIP: None, no virtual IP is allocated, so the service's DNS A records resolve straight to each backing pod's IP rather than a single load-balanced address. This satisfies the headless requirement, letting clients address individual pods directly for stateful or peer-discovery workloads.

Why this answer

A headless service in OpenShift/Kubernetes is defined by setting clusterIP: None, which means no virtual IP is allocated. Instead, DNS resolution for the service returns the individual pod IPs directly (A/AAAA records), allowing clients to connect to specific pods — commonly used for StatefulSets where each pod needs a stable identity.

Exam trap

EX280 often tests the confusion between headless services (clusterIP: None, DNS returns pod IPs) and NodePort/LoadBalancer services, causing candidates to incorrectly associate headless services with external exposure or NodePort routing.

How to eliminate wrong answers

Option A is wrong because headless services do not inherently prevent external routes from binding; Routes can still target the service, though headless services are typically used for internal discovery. Option B is wrong because headless services do not route traffic via NodePort — that is a separate service type (NodePort), and headless services bypass kube-proxy load balancing entirely. Option D is wrong because headless services do not provision cloud load balancers — that is the LoadBalancer service type, which is mutually exclusive with clusterIP: None.

Full explanation →

106

MCQhard

A security team requires that a specific ServiceAccount `app-sa` in project `prod` be allowed to run pods that use the `hostNetwork` namespace, while all other ServiceAccounts in `prod` must remain restricted. The administrator creates a new SCC `hostnet-scc` with `allowHostNetwork: true` and binds it only to `app-sa`. A developer then creates a pod using the `default` ServiceAccount with `hostNetwork: true` in its manifest. What is the result?

A.The pod is rejected because the `default` ServiceAccount is not bound to an SCC that allows `hostNetwork`.

B.The pod is rejected because `hostNetwork` requires the `privileged` SCC, which is not bound to any ServiceAccount.

C.The pod is admitted but runs without host networking, because the SCC silently strips the `hostNetwork` field.

D.The pod is admitted because SCCs are evaluated cluster-wide and any SCC allowing `hostNetwork` permits the pod.

AnswerA

SCC admission evaluates the pod against the SCCs bound to its ServiceAccount. The `default` ServiceAccount in `prod` is bound only to the restricted SCCs, which set `allowHostNetwork: false`. Since the pod requests `hostNetwork`, no bound SCC accepts it, and admission rejects the pod. Only pods using `app-sa` can leverage `hostnet-scc`.

Why this answer

SCC admission is scoped to the ServiceAccount used by the pod. Because the developer used the `default` ServiceAccount, which is bound only to restricted SCCs, the request for `hostNetwork` is rejected even though `hostnet-scc` exists. Only pods running under `app-sa` can use the custom SCC.

SCCs are not evaluated cluster-wide, and disallowed fields cause rejection rather than silent removal.

Exam trap

The trap here is believing that creating an SCC that allows a setting makes that setting available cluster-wide, when SCC access is granted per ServiceAccount through bindings.

Full explanation →

107

MCQmedium

A container inside a pod is failing with 'ImagePullBackOff'. The administrator verifies the image tag exists. What is the next most logical troubleshooting step to check authentication or registry access?

A.Inspect the etcd cluster operator status.

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

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

D.Restart the cluster version operator.

AnswerC

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

Why this answer

ImagePullBackOff with a verified image tag almost always indicates an authentication or registry-access problem, so the next step is to verify that a pull secret is correctly configured and bound to the service account used by the pod. OpenShift uses the service account's imagePullSecrets to authenticate to private registries, and a missing or misbound secret causes the kubelet to fail the pull.

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

108

MCQhard

An OpenShift administrator must give the user 'dana' permission to list and watch pods and services across every project in the cluster, but nothing else. The administrator decides to create a new ClusterRole named 'ns-reader' containing only those rules and bind it to dana. Which command correctly creates this ClusterRole?

A.oc adm policy add-cluster-role-to-user ns-reader dana --verb=list,watch --resource=pods,services

B.oc create role ns-reader --verb=list,watch --resource=pods,services -n default

C.oc create clusterrolebinding ns-reader --clusterrole=view --user=dana

D.oc create clusterrole ns-reader --verb=list,watch --resource=pods,services

AnswerD

The oc create clusterrole subcommand generates a ClusterRole (cluster-scoped, not namespaced) with the given verbs and resources. Because it is a ClusterRole, binding it via a ClusterRoleBinding later grants dana the list and watch verbs on pods and services in every project. This matches the requirement exactly without granting create, delete, or other verbs.

Why this answer

The task requires a new cluster-scoped ClusterRole with only list and watch on pods and services. The oc create clusterrole subcommand is the direct imperative way to author that object from the CLI, producing a ClusterRole that can later be bound cluster-wide. Creating a namespaced Role, binding the broad view role, or using add-cluster-role-to-user all fail to produce the narrowly scoped ClusterRole described.

Exam trap

The trap here is confusing the namespaced oc create role with the cluster-scoped oc create clusterrole, since a Role cannot grant access across every project.

Full explanation →

109

MCQeasy

An administrator is troubleshooting a pod that fails to schedule and remains in `Pending` state. The administrator runs `oc describe pod` and sees the event `0/9 nodes are available: 9 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.` What is the most likely cause?

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

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

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

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

AnswerB

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

Why this answer

The event message directly indicates that the scheduler could not place the pod because all nodes had a taint that the pod did not tolerate. In OpenShift, master nodes carry the `node-role.kubernetes.io/master` taint by default, so regular pods must either target worker nodes or include a toleration. The other options would produce different event messages, making the taint explanation the clear cause.

Exam trap

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

Full explanation →

110

Multi-Selecthard

An administrator is managing cluster machine configurations and needs to understand how Ignition configuration files are processed. Which THREE statements are correct regarding Ignition and the Machine Config Operator in OpenShift 4.14? (Choose THREE)

Select 3 answers

A.The Machine Config Daemon runs on every node to apply updates delivered by the MCO.

B.Ignition configuration is used by the operating system during initial node provisioning and first boot.

C.The Machine Config Operator merges multiple MachineConfigs into a single rendered MachineConfig for each pool.

D.Ignition files are stored directly inside etcd without encryption or serialization.

E.Ignition configs are dynamically parsed and executed continuously by a background daemon every 5 seconds during normal runtime.

AnswersA, B, C

The Machine Config Daemon runs as a daemon set on every node, including control-plane nodes, and applies rendered MachineConfig changes locally. This satisfies the scenario's requirement to understand how Ignition files reach each machine: the MCO renders configs, then each node's daemon reconciles them, triggering a reboot when the Ignition config changes.

Why this answer

Option A is correct because the Machine Config Daemon (MCD) runs as a DaemonSet on every node in the cluster and is responsible for applying MachineConfig changes delivered by the Machine Config Operator, including rebooting or draining nodes as needed. Option B is correct because Ignition is a provisioning-time utility used by RHCOS during initial node installation and first boot to perform disk partitioning, filesystem creation, and writing configuration files before the node joins the cluster. Option C is correct because the MCO renders a merged MachineConfig for each machine config pool by combining the appropriate MachineConfigs (including the rendered-worker or rendered-master configs) into a single Ignition config that the MCD applies.

Option D is incorrect because Ignition configs are not stored in etcd; they are served by the MCS and consumed by nodes during provisioning, and etcd stores Kubernetes objects, not raw Ignition files. Option E is incorrect because Ignition is not a continuously running daemon and does not re-parse configs every 5 seconds; it runs only during early boot/provisioning, while ongoing configuration changes are handled by the MCD.

Exam trap

EX280 often tests the lifecycle of Ignition configs and the role of the MCD, and candidates may incorrectly think Ignition runs continuously or that configs are stored unencrypted in etcd.

Full explanation →

111

Multi-Selecteasy

Which TWO of the following are valid OpenShift Service types? (Choose TWO)

Select 2 answers

A.NetworkPort

B.ClusterIP

C.RouteIP

D.ContainerPort

E.NodePort

AnswersB, E

ClusterIP allocates a virtual IP reachable only from inside the cluster, making it the default Service type. It satisfies the stem because it is a native Kubernetes Service type, unlike Route or Ingress, which are OpenShift API objects rather than Services.

Why this answer

Option B, ClusterIP, is a valid OpenShift/Kubernetes Service type: it exposes the Service on an internal cluster IP reachable only from within the cluster, and it is in fact the default Service type. Option E, NodePort, is also a valid Service type: it allocates a static port on each node's IP (default range 30000-32767) so the Service is reachable from outside the cluster via <NodeIP>:<NodePort>. The other options are not Service types: NetworkPort is not a Kubernetes/OpenShift Service type, RouteIP is not a Service type (OpenShift Routes are separate API objects that expose Services externally), and ContainerPort is a field within a Pod's container spec that declares the port the container listens on, not a Service type.

Exam trap

EX280 often tests whether candidates can distinguish valid Service types from similarly named Kubernetes fields (ContainerPort) or OpenShift resources (Route) — the trap is picking terms that sound plausible but are not Service types.

Full explanation →

112

MCQmedium

You need to deploy a Node.js application from a Git repository using Source-to-Image (S2I) on OpenShift 4.14, and you want to ensure the build triggers automatically whenever a new image is pushed to the dependent base ImageStream. Which BuildConfig strategy and configuration element achieves this?

A.Configure a Docker build with a ConfigChange trigger on the DeploymentConfig.

B.Configure a Source build with an ImageChange trigger on the input ImageStreamTag.

C.Configure a Pipeline build referencing a Tekton pipeline with manual execution parameters.

D.Configure a Custom build with a GitHub webhook trigger referencing the source repository.

AnswerB

An ImageChange trigger on the input ImageStreamTag causes OpenShift to start a new Source build automatically whenever the referenced base image is updated, satisfying the automatic rebuild requirement. The S2I builder image is the input, so the trigger must watch that ImageStreamTag rather than the output.

Why this answer

The Source build strategy is the S2I builder, which is designed to take application source code from a Git repository and combine it with a builder image to produce a runnable image. To automatically trigger a new build when the dependent base ImageStream is updated (e.g., a new version of the Node.js builder image is pushed), you must configure an ImageChange trigger that references the input ImageStreamTag used by the build. This trigger watches the specified ImageStreamTag and starts a build whenever the tag's image ID changes, ensuring the application is rebuilt with the latest base image.

Exam trap

EX280 often tests the difference between ImageChange triggers (for base image updates) and webhook triggers (for source code changes), and candidates may mistakenly select a webhook or ConfigChange trigger when the requirement is automatic rebuild on base image update.

How to eliminate wrong answers

Option A is wrong because a Docker build strategy does not use S2I and a ConfigChange trigger on a DeploymentConfig triggers deployment when the BuildConfig configuration changes, not when a base image is updated. Option C is wrong because a Pipeline build with Tekton does not inherently provide automatic image change triggers for base ImageStreams; it requires manual execution or separate triggers. Option D is wrong because a Custom build strategy allows arbitrary builder images but does not automatically trigger on base image changes; a GitHub webhook triggers on source code pushes, not on base image updates.

Full explanation →

113

MCQmedium

How do you view the history of deployments for a DeploymentConfig?

A.oc rollout history

B.oc show history

C.oc describe dc

D.oc get history

AnswerA

The oc rollout history command queries a DeploymentConfig's recorded revisions, listing each deployment with its revision number and change cause. This directly satisfies the requirement to view the deployment history, unlike oc status or oc describe, which show current state rather than revision timeline.

Why this answer

The `oc rollout history` command is specifically designed to display the revision history of a DeploymentConfig, showing each deployment's revision number, cause, and change details. It queries the DeploymentConfig's status and associated ReplicationControllers to present a chronological list of rollouts. This is the standard OpenShift CLI method for auditing deployment changes.

Exam trap

EX280 often tests the distinction between commands that show current state (like `oc describe`) and those that show historical revisions (like `oc rollout history`), so candidates must remember that only `oc rollout history` provides the full deployment revision list.

How to eliminate wrong answers

Option B is wrong because `oc show history` is not a valid oc command; there is no 'show' subcommand in the OpenShift CLI. Option C is wrong because `oc describe dc` provides detailed information about the current state of a DeploymentConfig, including its latest deployment, but does not list the full revision history. Option D is wrong because `oc get history` is not a valid command; 'history' is not a resource type that can be retrieved with `oc get`.

Full explanation →

114

MCQmedium

A cluster administrator wants to restrict a specific storage class so that only members of a designated OpenShift project can create PVCs referencing it. How is this typically enforced in OpenShift?

A.By assigning RBAC RoleBindings to the StorageClass object directly.

B.By setting accessMode: Restricted in the StorageClass metadata.

C.Using admission control policies or validation webhooks to restrict StorageClass usage by namespace.

D.By adding a namespaces array directly in the StorageClass spec.

AnswerC

Admission control policies and validating webhooks intercept PVC creation requests, evaluating the requesting namespace against rules tied to the StorageClass. This enforces namespace-scoped restrictions that RBAC alone cannot express, limiting usage to the designated OpenShift project.

Why this answer

OpenShift does not natively support per-namespace StorageClass restrictions in the StorageClass spec itself, so enforcement is typically done through admission control — either a ValidatingAdmissionPolicy, a custom validating webhook, or OPA/Gatekeeper constraints that inspect PVC creation requests and reject those referencing a restricted StorageClass from unauthorised namespaces. This is the standard pattern for multi-tenant storage isolation.

Exam trap

EX280 often tests whether candidates invent non-existent StorageClass fields (like 'namespaces' or 'accessMode: Restricted') instead of recognising that OpenShift relies on admission control for this kind of policy — the trap is assuming a declarative field exists when it does not.

How to eliminate wrong answers

Option A is wrong because RBAC RoleBindings cannot be attached to StorageClass objects — StorageClass is a cluster-scoped resource and RBAC does not support per-object bindings of this kind. Option B is wrong because 'accessMode: Restricted' is not a valid StorageClass metadata field; access modes belong on PVs and PVCs, not on the StorageClass metadata. Option D is wrong because the StorageClass spec has no 'namespaces' array — there is no built-in field for namespace scoping, which is precisely why admission control is needed.

Full explanation →

115

MCQmedium

What happens if a pod does not match any SCC?

A.The pod runs with no constraints

B.The pod is rejected

C.The pod is assigned the 'restricted' SCC by default

D.The pod is assigned the 'privileged' SCC

AnswerB

OpenShift's Security Context Constraints admission controller evaluates every pod against defined constraints; if no SCC matches the pod's requested security context, admission is denied. The pod is therefore rejected rather than defaulted or run with elevated privileges, enforcing cluster security policy.

Why this answer

If a pod does not match any SCC, the SCC admission controller rejects the pod outright — the API server returns a 'forbidden' error and the pod is never scheduled. There is no fallback to a default SCC; the pod's securityContext and volume definitions must satisfy at least one SCC bound to the pod's service account (or the creating user).

Exam trap

EX280 often tests the assumption that OpenShift falls back to a default SCC like 'restricted' — in reality, no match means hard rejection, and candidates who assume a fallback pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because OpenShift never runs pods without SCC evaluation — SCC admission is mandatory, not optional, so 'no constraints' is not a possible state. Option C is wrong because 'restricted' is not an automatic fallback; it is only applied if the pod's securityContext actually satisfies the restricted SCC's requirements (e.g., no privileged, no hostPath, runAsNonRoot). Option D is wrong because 'privileged' is never assigned by default — it must be explicitly bound to a service account, and assigning it automatically would defeat the purpose of SCCs.

Full explanation →

116

MCQhard

An administrator has successfully installed an Operator via OperatorHub, but the Operator's CSV (ClusterServiceVersion) status is stuck at 'Pending'. Upon investigating, the administrator discovers that the required CustomResourceDefinitions (CRDs) have conflicting versions with a previously deleted Operator. How can the administrator forcefully clean up orphaned CRDs if OLM fails to remove them?

A.Run 'oc adm prune crds --force' to automatically purge all stuck custom resources.

B.Edit the CRD definition and remove any lingering finalizers in 'metadata.finalizers' to allow deletion.

C.Restart the kube-apiserver pods to bypass CRD validation checks.

D.Delete the openshift-operator-lifecycle-manager namespace to reset all CRDs.

AnswerB

Orphaned CRDs often persist because finalizers in metadata.finalizers block deletion while OLM cannot complete cleanup. Removing those finalizers lets the API server finish removing the CRD, clearing the version conflict that keeps the new Operator's CSV at Pending.

Why this answer

When OLM fails to remove a CRD because it is stuck in Terminating, the usual cause is a lingering finalizer in metadata.finalizers. Editing the CRD to remove the finalizer allows the Kubernetes API server to complete deletion, clearing the orphaned CRD so the new Operator's CSV can proceed past Pending.

Exam trap

EX280 often tests finalizer behavior — candidates pick drastic options like deleting the OLM namespace or restarting API servers, not realizing that a single finalizer on the CRD is what blocks deletion.

How to eliminate wrong answers

Option A is wrong because oc adm prune crds --force is not a valid OpenShift command — there is no such prune subcommand for CRDs. Option C is wrong because restarting kube-apiserver pods does not bypass CRD validation or finalizer logic; finalizers are enforced by the API server's deletion path, not by pod state. Option D is wrong because deleting the openshift-operator-lifecycle-manager namespace would destroy OLM itself and all managed operators, causing far more damage than the original problem.

Full explanation →

117

MCQeasy

Which resource in OpenShift acts as an abstraction over a set of images to provide a stable reference?

A.DeploymentConfig

B.BuildConfig

C.Route

D.ImageStream

AnswerD

An ImageStream abstracts image repositories by tracking tags and automatically updating when new images are pushed. It provides the stable reference the stem requires, unlike a direct image pull spec, which pins a specific digest or tag.

Why this answer

An ImageStream in OpenShift is a named abstraction that points to one or more container images, tracking image updates via tags. It provides a stable reference (e.g., myapp:latest) that can be resolved to a specific image digest at deploy time, decoupling workloads from underlying registry locations. This allows builds and deployments to trigger automatically when new images are pushed to the stream.

Exam trap

EX280 often tests the distinction between resources that manage builds, deployments, and networking versus those that abstract images, so candidates may confuse ImageStream with BuildConfig or DeploymentConfig.

How to eliminate wrong answers

Option A is wrong because a DeploymentConfig defines how to deploy an application (replication, triggers, strategy) and does not abstract image sets. Option B is wrong because a BuildConfig defines how to build a container image from source, not a stable reference to images. Option C is wrong because a Route exposes a service externally via a hostname, providing network access rather than image abstraction.

Full explanation →

118

MCQmedium

You want to prevent a specific pod from being scheduled on nodes that are already running other pods of the same application. What should you configure?

A.Pod anti-affinity

B.Tolerations

C.Node selector

D.Resource quotas

AnswerA

Pod anti-affinity uses label selectors with topologyKey to repel pods from nodes already hosting matching pods, directly preventing co-location of the same application's replicas. This satisfies the constraint of keeping identical pods apart across the cluster.

Why this answer

Pod anti-affinity is the correct mechanism because it lets you express a scheduling rule that repels a pod from nodes already hosting pods with specified labels. By using topologyKey (e.g., kubernetes.io/hostname) and labelSelector matching the application, you ensure no two pods of the same app land on the same node. This is the native Kubernetes scheduling constraint designed exactly for spreading workloads apart.

Exam trap

EX280 often tests the confusion between node affinity/anti-affinity (pod-centric scheduling rules) and taints/tolerations (node-centric repulsion), so candidates pick tolerations when the question asks to keep same-app pods apart.

How to eliminate wrong answers

Option B is wrong because tolerations only allow a pod to be scheduled onto nodes with matching taints; they do not repel pods from nodes running other pods. Option C is wrong because a node selector only attracts a pod to nodes with specific labels and cannot express 'avoid nodes already running app X'. Option D is wrong because resource quotas limit aggregate CPU/memory/object counts in a namespace and have no influence on per-node scheduling placement.

Full explanation →

119

MCQmedium

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

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

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

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

D.The container exceeded its memory limit upon initialization.

AnswerC

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

Why this answer

`CreateContainerConfigError` occurs when the kubelet cannot create the container's configuration, most commonly because a referenced ConfigMap or Secret in the pod spec (via `envFrom`, `valueFrom`, or volume mounts) does not exist in the namespace. The kubelet fails to resolve the reference and reports this error. Administrators should verify the ConfigMap/Secret names and namespaces.

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

120

MCQeasy

An administrator needs to list all Services across all namespaces in the OpenShift cluster. Which command should be used?

A.oc get services --cluster

B.oc get svc -A

C.oc describe service --all

D.oc adm top services

AnswerB

The -A flag (equivalent to --all-namespaces) instructs oc to query Services cluster-wide rather than only within the current project, which is the constraint the administrator faces when needing a complete cross-namespace listing in one command.

Why this answer

The `-A` flag (short for `--all-namespaces`) is the standard OpenShift/Kubernetes flag that makes `oc get` query every namespace in the cluster. Running `oc get svc -A` returns all Services across all projects in a single table, which is exactly what the administrator needs. This flag is consistent across resource types and is the idiomatic way to perform cluster-wide listing.

Exam trap

EX280 often tests whether candidates invent non-existent flags like `--cluster` or `--all` for `oc get` instead of using the correct `-A` / `--all-namespaces` flag.

How to eliminate wrong answers

Option A is wrong because `--cluster` is not a valid flag for `oc get services`; there is no such option in the oc CLI, so the command would error out. Option C is wrong because `oc describe service --all` is not valid syntax — `describe` requires a specific resource name, and `--all` is not a supported flag for describe operations. Option D is wrong because `oc adm top services` is not a real command; `oc adm top` supports nodes and pods for metrics, not services, and it would not list Services at all.

Full explanation →

121

Multi-Selecthard

An administrator needs to troubleshoot an image pull failure caused by missing credentials. Which TWO locations or methods can be used to associate an image pull secret with a workload in OpenShift? (Choose TWO)

Select 2 answers

A.Defining the secret inside the cluster Ingress controller custom resource spec

B.Placing the pull secret in the global openshift-config ConfigMap

C.Annotating the Namespace with openshift.io/image-pull-secret-ref

D.Linking the image pull secret to the ServiceAccount referenced by the deployment's pod spec via oc secrets link

E.Adding the secret to the imagePullSecrets array within the pod template specification of a Deployment

AnswersD, E

Linking via `oc secrets link` attaches the pull secret to the ServiceAccount, so every pod using that account inherits the credentials automatically. This satisfies the scenario's requirement to associate a secret with a workload without editing each pod spec, and remains the standard cluster-wide approach for authenticating to private registries.

Why this answer

Option D is correct because `oc secrets link <serviceaccount> <secret> --for=pull` associates the pull secret with a ServiceAccount, and any pod that references that ServiceAccount in its pod spec automatically inherits the secret for image pulls. Option E is correct because a Deployment's pod template can explicitly list the secret under `spec.template.spec.imagePullSecrets`, which causes the kubelet to use those credentials when pulling the container image. Option A is incorrect because the Ingress controller custom resource spec configures routing/TLS behavior, not workload image pull credentials.

Option B is incorrect because the global pull secret is stored in the `openshift-config` namespace as the `pull-secret` Secret (referenced by cluster configuration), not as a ConfigMap. Option C is incorrect because there is no supported `openshift.io/image-pull-secret-ref` annotation on a Namespace for associating pull secrets with workloads.

Exam trap

EX280 often tests the distinction between cluster-wide pull secrets (openshift-config) and per-workload/ServiceAccount pull secrets — candidates may incorrectly choose a global ConfigMap or namespace annotation.

Full explanation →

122

MCQeasy

A PersistentVolumeClaim is stuck in Pending state. The administrator checks and finds that the requested StorageClass does not exist. What is the most likely cause?

A.The PVC's requested capacity exceeds the maximum allowed by the default StorageClass.

B.The cluster has no nodes with sufficient capacity to host the volume.

C.The PVC's storageClassName field references a non-existent StorageClass, so no provisioner can satisfy the claim.

D.The PVC's access mode is not supported by any available PersistentVolume.

AnswerC

If the storageClassName in the PVC does not match any existing StorageClass, the PersistentVolume controller cannot find a provisioner to dynamically create a volume. As a result, the PVC remains Pending. The administrator should verify the StorageClass name and create it if missing, or correct the PVC's storageClassName.

Why this answer

A PVC that references a non-existent StorageClass cannot be dynamically provisioned and remains Pending. The controller looks for a StorageClass with the specified name to determine the provisioner and parameters. If none exists, no provisioning occurs.

The administrator must create the StorageClass or update the PVC to use an existing one.

Exam trap

The trap here is assuming that node capacity or access modes cause the Pending state, when the explicit missing StorageClass is the direct cause.

Full explanation →

123

Multi-Selecthard

Which TWO statements are true regarding OpenShift Services of type LoadBalancer? (Choose TWO)

Select 2 answers

A.They interact with cloud provider APIs or MetalLB to provision an external IP address.

B.They are restricted to internal cluster communication only.

C.They replace the need for Ingress controllers completely.

D.They can only be created when running on bare-metal hardware without external integrations.

E.They automatically allocate a NodePort on every worker node to route traffic into the cluster.

AnswersA, E

LoadBalancer Services delegate external IP allocation to an infrastructure provider: on cloud platforms, the cloud controller calls the provider's API to create a load balancer; on bare metal, MetalLB assigns addresses from a configured pool. This satisfies the stem's requirement for provisioning an external IP without manual intervention.

Why this answer

Option A is correct because a Service of type LoadBalancer triggers OpenShift's cloud-provider integration (or the MetalLB operator on bare metal) to call the provider's API and provision an external load balancer with a routable external IP that forwards traffic to the service. Option E is correct because LoadBalancer builds on NodePort: OpenShift automatically allocates a NodePort (in the 30000-32767 range by default) on every node, and the external load balancer targets that NodePort to reach the backing pods. Option B is wrong because LoadBalancer services are specifically for external access, not internal-only communication (that is ClusterIP).

Option C is wrong because Ingress controllers and Routes provide HTTP/HTTPS host- and path-based routing that a LoadBalancer service does not replace. Option D is wrong because LoadBalancer services are supported on cloud platforms via provider APIs as well as on bare metal via MetalLB, so they are not limited to bare metal without integrations.

Exam trap

EX280 often tests the misconception that LoadBalancer Services replace Ingress or are internal-only, when in fact they are L4 external Services that complement L7 Ingress/Route objects.

Full explanation →

124

MCQmedium

An administrator is troubleshooting why a Pod in namespace `app-a` cannot reach a Pod in namespace `app-b` on TCP port 3306, even though both Pods are Running and the Services resolve correctly. A NetworkPolicy in `app-b` allows ingress only from Pods labeled `tier: frontend` in `app-a`. The source Pod in `app-a` has the label `tier: backend`. What is the most likely cause?

A.The cluster's DNS service is not resolving the destination Service name.

B.The source Pod's label does not match the NetworkPolicy's allowed source selector, so ingress is denied.

C.The destination Pod is not listening on port 3306, so the connection is refused.

D.The source namespace `app-a` lacks a matching egress NetworkPolicy allowing traffic to `app-b`.

AnswerB

The NetworkPolicy in `app-b` permits ingress only from Pods labeled `tier: frontend` in `app-a`. The source Pod carries `tier: backend`, so it does not match the allowed source selector. Since the policy explicitly restricts ingress, any traffic not matching an allow rule is dropped, making the label mismatch the direct cause of the connectivity failure.

Why this answer

NetworkPolicy ingress rules can restrict allowed sources by namespace and Pod label selectors. When a source Pod's labels do not match the allowed selector, its traffic is dropped even if the Pod is healthy and the destination Service resolves. In this case, the source Pod labeled `tier: backend` fails to match the policy's requirement for `tier: frontend`, so the ingress is denied by policy rather than by application or DNS failure.

Exam trap

The trap here is focusing on DNS or application port issues when the scenario already provides a NetworkPolicy whose source label selector clearly excludes the source Pod.

Full explanation →

125

MCQmedium

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

A.oc describe clusteroperator monitoring

B.oc logs deployment/prometheus-k8s

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

D.oc get prometheus-rules

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

126

Multi-Selecteasy

Which TWO of the following tasks can a user with the default OpenShift 'admin' role perform within their project? (Choose TWO)

Select 2 answers

A.Create, modify, and delete workloads and services within the project.

B.Modify cluster-wide ClusterRoles and ClusterRoleBindings.

C.Create and modify Roles and RoleBindings within the project.

D.Create new projects cluster-wide without restrictions.

E.Modify global SecurityContextConstraints.

AnswersA, C

The default OpenShift `admin` role grants full control over project-scoped resources, so creating, modifying and deleting workloads and services falls squarely within it. This satisfies the stem's constraint of actions performed within the user's own project, since the role binds to that namespace rather than the whole cluster.

Why this answer

Option A is correct because the default OpenShift 'admin' role is a project-scoped role that grants full control over resources inside the project namespace, including creating, modifying, and deleting workloads (Deployments, Pods, etc.) and Services. Option C is correct because the 'admin' role also includes permissions to manage project-local RBAC objects, i.e., create and modify Roles and RoleBindings within that project. Option B is incorrect because ClusterRoles and ClusterRoleBindings are cluster-scoped resources, and the 'admin' role does not grant cluster-level RBAC administration (that requires cluster-admin or similar).

Option D is incorrect because creating new projects cluster-wide is governed by the self-provisioner ClusterRoleBinding, not by the project 'admin' role. Option E is incorrect because SecurityContextConstraints are cluster-scoped resources, and modifying them requires cluster-level privileges, not the project 'admin' role.

Exam trap

EX280 often tests the boundary between project-scoped admin and cluster-scoped cluster-admin — candidates must remember that the admin role cannot touch ClusterRoles, ClusterRoleBindings, SCCs, or create projects cluster-wide.

Full explanation →

127

Multi-Selectmedium

Which THREE of the following objects can be used to enforce resource governance and consumption limits within an OpenShift project? (Choose THREE)

Select 3 answers

A.SecurityContextConstraints

B.LimitRange

C.NetworkPolicy

D.ResourceQuota

E.ClusterResourceQuota

AnswersB, D, E

A LimitRange sets default, minimum and maximum CPU and memory values per pod or container within a project, preventing unbounded requests. It enforces consumption limits at the individual workload level, satisfying the governance requirement in the stem.

Why this answer

LimitRange (B) is correct because it sets default, minimum, and maximum CPU/memory requests and limits for individual pods and containers within a project, enforcing per-object consumption boundaries. ResourceQuota (D) is correct because it caps the aggregate resource consumption of an entire project, such as total CPU/memory requests and limits, pod counts, and object counts. ClusterResourceQuota (E) is correct because it applies quota enforcement across multiple projects selected by label or annotation, governing total consumption at a cluster-scoped level.

SecurityContextConstraints (A) govern pod security privileges (e.g., allowed UIDs, SELinux, privileged mode), not resource consumption limits, and NetworkPolicy (C) controls pod-level network traffic, so neither enforces resource governance.

Exam trap

EX280 often tests the confusion between security and network policies (SCC, NetworkPolicy) and actual resource governance objects (LimitRange, ResourceQuota, ClusterResourceQuota).

Full explanation →

128

MCQhard

An OpenShift administrator needs to inspect how OVN-Kubernetes handles network flows and packet drops on a specific node. Which debugging utility installed in the OVN node container is most effective for viewing OpenFlow rules?

A.nmcli connection show

B.ethtool -S

C.ovs-ofctl

D.ovn-trace

AnswerC

ovs-ofctl queries and dumps OpenFlow flow tables from the Open vSwitch bridge that OVN-Kubernetes programs. Running it inside the OVN node container shows the exact match-action rules and drop counters for flows on that node.

Why this answer

OVN-Kubernetes uses Open vSwitch (OVS) as its data plane, and ovs-ofctl is the standard utility for inspecting and managing OpenFlow rules in the OVS bridge. It allows administrators to dump flows, view packet counters, and debug how traffic is being handled on a specific node. This makes it the most effective tool for viewing OpenFlow rules in the OVN node container.

Exam trap

EX280 often tests the distinction between OVN logical flow tracing (ovn-trace) and OpenFlow rule inspection (ovs-ofctl), so candidates must pick the tool that directly shows OpenFlow rules when asked about packet drops on a node.

How to eliminate wrong answers

Option A is wrong because nmcli is a NetworkManager CLI for managing host network connections, not OpenFlow rules. Option B is wrong because ethtool -S displays NIC statistics, not OpenFlow flows. Option D is wrong because ovn-trace simulates packet traversal through OVN logical flows, which is useful for logical debugging but does not display the OpenFlow rules installed in OVS.

Full explanation →

129

MCQhard

A developer's pod is stuck in ContainerCreating because its PersistentVolumeClaim is bound to a PersistentVolume that was previously attached to a node that has since gone offline without graceful detach. The CSI driver reports the volume as still attached to the failed node. Which action should the administrator take to allow the pod to start on a healthy node?

A.Cordon the healthy node and drain it to force the scheduler to place the pod on another node.

B.Delete the PersistentVolumeClaim and re-create it so a new PersistentVolume is provisioned.

C.Create a VolumeAttachment object for the healthy node to override the existing attachment.

D.Delete the stale VolumeAttachment object associated with the failed node to force the CSI driver to detach and allow reattachment.

AnswerD

The CSI external-attacher represents each volume attachment as a VolumeAttachment object. Removing the stale object tied to the offline node prompts the driver to release the attachment, after which the pod can attach the volume on a healthy node. This is the targeted remediation for an orphaned attachment.

Why this answer

A stale VolumeAttachment pointing at an offline node prevents the CSI driver from attaching the volume elsewhere. Deleting that orphaned VolumeAttachment object forces the external-attacher to reconcile the state, releasing the volume so it can attach to a healthy node and let the pod start.

Exam trap

The trap here is deleting the PVC to resolve the stuck pod, which risks data loss rather than clearing the stale attachment object that actually blocks reattachment.

Full explanation →

130

MCQeasy

An administrator needs to delete a Service named 'old-service' in the 'test' namespace. Which command accomplishes this?

A.oc remove svc old-service --namespace=test

B.oc prune service old-service -n test

C.oc destroy service old-service -n test

D.oc delete service old-service -n test

AnswerD

The oc delete command removes a named resource, with -n test scoping the operation to the test namespace. Specifying service old-service targets the correct resource type and name, satisfying the requirement to delete that Service in that namespace.

Why this answer

The correct command is `oc delete service old-service -n test` because `oc delete` is the standard OpenShift/Kubernetes verb for removing resources. It accepts the resource type (service, or its abbreviation svc) and the resource name, with the `-n` flag specifying the namespace. This directly deletes the Service object from the 'test' namespace.

Exam trap

EX280 often tests whether candidates confuse `oc delete` with non-existent verbs like `remove`, `destroy`, or `prune`, which are not part of the standard oc CLI for deleting specific resources.

How to eliminate wrong answers

Option A is wrong because `oc remove` is not a valid subcommand in the oc CLI; the correct verb is `delete`. Option B is wrong because `oc prune` is used to remove older resources based on criteria (e.g., builds, deployments) and does not target a specific named Service. Option C is wrong because `oc destroy` is not a valid subcommand; it might be confused with `oc delete` or `oc destroy` from other tools, but it does not exist in oc.

Full explanation →

131

MCQhard

A user reports that 'oc get pods -n analytics' returns a Forbidden error, but 'oc get pods -n analytics --as=system:admin' succeeds. The administrator confirms the user is a member of the LDAP group 'data-team' and that a ClusterRoleBinding grants 'view' to that group. What should the administrator check first to explain the discrepancy?

A.Whether the identity provider is sending group membership in the OAuth token, since missing group claims would prevent the ClusterRoleBinding from matching.

B.Whether the 'view' ClusterRole has been extended with an aggregationRule that removes get and list from pods.

C.Whether the 'analytics' namespace has a ResourceQuota that blocks read operations for non-admin users.

D.Whether the user authenticated to OpenShift via the 'kube:admin' identity rather than the LDAP identity provider.

AnswerA

OpenShift RBAC matches subjects by user, group, and service account. If the LDAP identity provider is not configured to map group membership into OAuth group claims, the user's token will not carry 'data-team', so the ClusterRoleBinding to that group never matches. Verifying group claims in the identity configuration is the most direct first check.

Why this answer

RBAC matches group subjects using the groups carried in the user's OAuth token. If the LDAP identity provider does not map group membership into group claims, the user is authenticated but lacks the 'data-team' group, so the ClusterRoleBinding never applies. Inspecting the identity provider's group mapping and the token's groups resolves the discrepancy.

Exam trap

The trap here is assuming that LDAP group membership alone satisfies a group-based binding, when OpenShift only matches groups that the identity provider actually places into the OAuth token.

Full explanation →

132

Multi-Selecteasy

Which TWO options are valid methods to check service endpoints in OpenShift? (Choose TWO)

Select 2 answers

A.oc adm inspect endpoints

B.oc get routes --show-endpoints

C.oc get pods --endpoints

D.oc get endpoints

E.oc describe service <service-name>

AnswersD, E

'oc get endpoints' queries the Endpoints API object directly, listing the pod IP addresses and ports backing each service. This satisfies the requirement to verify which pods a service currently routes to, exposing the actual endpoint set.

Why this answer

Option D, `oc get endpoints`, is correct because Endpoints objects are the native Kubernetes/OpenShift resource that lists the actual IP:port pairs backing a Service, so querying them directly shows whether the service has healthy endpoint addresses. Option E, `oc describe service <service-name>`, is correct because the describe output includes an `Endpoints:` field (e.g., `10.128.0.5:8080`) that reveals the currently selected pod endpoints for that Service. Option A is invalid because `oc adm inspect` is a must-gather/diagnostic command that collects cluster resources into a directory; it does not take `endpoints` as a subcommand to display them.

Option B is invalid because `oc get routes` has no `--show-endpoints` flag, and Routes are OpenShift ingress objects, not the Service endpoint mechanism. Option C is invalid because `oc get pods` has no `--endpoints` flag and pods do not expose endpoint lists in that manner.

Exam trap

EX280 often tests the correct CLI syntax for inspecting endpoints — candidates pick plausible-sounding but non-existent flags like --show-endpoints or --endpoints, when the valid commands are `oc get endpoints` and `oc describe service`.

Full explanation →

133

Multi-Selectmedium

Which TWO of the following are valid ways to secure a route?

Select 2 answers

A.Allowing all traffic on port 80

B.Using insecure edge termination

C.Using 'edge' termination with a custom certificate

D.Disabling TLS completely

E.Using 'reencrypt' termination to ensure end-to-end encryption

AnswersC, E

Edge termination stops TLS at the router using a certificate you supply, rather than the router's default. Supplying a custom certificate satisfies the stem's requirement for a valid way to secure a route, with traffic to the pod left unencrypted.

Why this answer

Option C is correct because configuring a route with 'edge' termination means TLS is terminated at the router (the ingress point), and supplying a custom certificate lets the router present a trusted certificate to external clients, which is a valid and common way to secure a route. Option E is correct because 'reencrypt' termination terminates TLS at the router and then re-encrypts the connection to the backend pod using a (possibly different) certificate, providing end-to-end encryption across the whole path, which is a valid secure route configuration. Option A is wrong because allowing all traffic on port 80 exposes plain HTTP with no encryption, so it does not secure the route.

Option B is wrong because 'insecure edge termination' leaves the external connection unencrypted (or without proper certificate validation), defeating the purpose of securing the route. Option D is wrong because disabling TLS removes encryption entirely, which is the opposite of securing a route.

Exam trap

EX280 often tests route termination types — candidates confuse 'edge' with 'passthrough' or assume any mention of TLS is automatically secure, missing that 'insecure edge' and 'disable TLS' are explicitly non-secure.

Full explanation →

134

MCQeasy

Which command allows an administrator to delete a user object named 'old-user' from the OpenShift cluster?

A.oc deactivate user old-user

B.oc delete user old-user

C.oc purge user old-user --force

D.oc remove user old-user

AnswerB

`oc delete user old-user` targets the cluster-scoped OpenShift User object directly, removing the identity record that grants cluster access. This satisfies the stem's requirement to delete the user object itself, rather than merely removing a project membership or identity provider entry.

Why this answer

The correct command is 'oc delete user old-user'. This command removes the user object from the OpenShift cluster. OpenShift users are represented as cluster-scoped resources, and the standard 'oc delete' verb is used to remove them.

Other options are not valid OpenShift commands.

Exam trap

The trap is confusing OpenShift user management with other systems that might use terms like 'deactivate' or 'remove', leading candidates to choose invalid commands.

How to eliminate wrong answers

Option A is wrong because 'oc deactivate' is not a valid command for user objects. Option C is wrong because 'oc purge' is not a valid command. Option D is wrong because 'oc remove' is not a valid command; the correct verb is 'delete'.

Full explanation →

135

MCQhard

A cluster administrator wants to restrict a specific group of developers from creating persistent volume claims (PVCs) larger than 50Gi in the 'data-tier' namespace, while still allowing smaller PVCs. How should this be implemented?

A.Configure a LimitRange object in the 'data-tier' namespace with max storage constraints for persistent volume claims.

B.Set a StorageClass default size restriction.

C.Apply a ClusterRole restricting PVC creation sizes.

D.Configure an egress firewall rule blocking large volume attachments.

AnswerA

A LimitRange with a `max` storage constraint on `persistentvolumeclaim` enforces the 50Gi ceiling at admission time within the 'data-tier' namespace, rejecting oversized PVCs while permitting smaller requests. This satisfies the per-namespace, per-group restriction without altering cluster-wide quota behaviour.

Why this answer

A LimitRange object in the 'data-tier' namespace can enforce a maximum storage request for PersistentVolumeClaims, rejecting any PVC that requests more than 50Gi. This is the native Kubernetes mechanism for per-namespace resource constraints on PVCs.

Exam trap

EX280 often tests the distinction between LimitRange (per-object min/max) and ResourceQuota (aggregate namespace limits) — candidates pick ClusterRole or StorageClass because they conflate RBAC/provisioning with resource constraints.

How to eliminate wrong answers

Option B is wrong because StorageClasses define provisioning parameters (disk type, reclaim policy) and do not enforce per-PVC size caps. Option C is wrong because ClusterRoles govern API verb permissions (create, get, delete), not the content or size of the resource being created. Option D is wrong because egress firewall rules control network traffic, not storage provisioning, and would not prevent large PVC creation.

Full explanation →

136

MCQmedium

A cluster administrator has created a new ProjectRequest template to ensure that every newly created project automatically includes a predefined LimitRange. Where must this template be configured so that it applies cluster-wide to all new projects?

A.In the namespace openshift-config as a ConfigMap named project-request

B.In the kube-system namespace as a Secret named default-project-template

C.As an annotation on the default ProjectTemplate object in the openshift namespace

D.In the cluster resource project.config.openshift.io/cluster under the projectRequestTemplate field

AnswerD

Configuring the template in the cluster resource project.config.openshift.io/cluster under projectRequestTemplate applies it cluster-wide, satisfying the requirement that every newly created project automatically receives the predefined LimitRange. The ProjectRequest controller reads this cluster-scoped resource when provisioning projects, so the LimitRange is injected without per-project intervention.

Why this answer

The cluster-wide ProjectRequest template is configured by editing the project.config.openshift.io/cluster resource and setting the projectRequestTemplate field to reference a template in the openshift-config namespace. This is the documented, supported mechanism for customizing what every new project receives.

Exam trap

EX280 often tests whether candidates know the template must be referenced from the project.config.openshift.io/cluster CR, not merely created as a ConfigMap — the ConfigMap alone is inert.

How to eliminate wrong answers

Option A is wrong because while the template itself lives in openshift-config, simply creating a ConfigMap named project-request does not wire it into the cluster — the project.config.openshift.io/cluster resource must reference it. Option B is wrong because there is no such Secret-based mechanism in kube-system for project templates. Option C is wrong because annotations on a ProjectTemplate object are not how cluster-wide defaults are applied; the config CR is the authoritative source.

Full explanation →

137

Multi-Selecteasy

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

Select 2 answers

A.oc get clusteroperator network

B.oc get routes

C.oc adm top volume

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

E.oc describe pvc

AnswersA, D

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

Why this answer

Option A, `oc get clusteroperator network`, is correct because it reports the status, availability, and conditions of the OpenShift SDN/OVN-Kubernetes network operator, which directly reflects cluster networking and SDN health. Option D, `oc logs -n openshift-ovn-kubernetes -l app=ovnkube-node`, is correct because it retrieves logs from the ovnkube-node pods in the openshift-ovn-kubernetes namespace, providing detailed SDN/OVN diagnostic information about node-level networking. Option B, `oc get routes`, only lists OpenShift route objects for exposing services and does not diagnose cluster networking or SDN communication.

Option C, `oc adm top volume`, reports volume usage statistics and is unrelated to network diagnostics. Option E, `oc describe pvc`, shows details about a PersistentVolumeClaim and its binding/storage status, not SDN or network information.

Exam trap

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

Full explanation →

138

Multi-Selectmedium

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

Select 2 answers

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

B.oc describe clusteroperator storage

C.oc get routes --all-namespaces

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

E.oc describe clusterversion

AnswersB, D

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

Why this answer

Option B is correct because `oc describe clusteroperator storage` surfaces the ClusterOperator's status conditions, related objects, and the specific reason/message for the degraded state, which typically points to the failing CSI driver or provisioner component. Option D is correct because the cluster-storage-operator deployment in the openshift-cluster-storage-operator namespace manages the storage operators (including CSI driver operators), so its logs reveal reconciliation errors and the underlying cause of the degradation. Option A is not relevant since the openshift-apiserver logs concern API server behavior, not storage provisioning.

Option C is unrelated because routes expose services and have no bearing on CSI driver failures. Option E is also unrelated, as clusterversion tracks OpenShift version and update status rather than storage subsystem diagnostics.

Exam trap

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

Full explanation →

139

MCQhard

An administrator needs to configure custom container runtime parameters (such as the maximum pod log size or maximum number of processes per container) across all worker nodes in an OpenShift 4.14 cluster. Which custom resource should the administrator create?

A.MachineHealthCheck

B.KubeletConfig

C.ContainerRuntimeConfig

D.NodeNetworkConfigurationPolicy

AnswerC

ContainerRuntimeConfig is a MachineConfigPool-scoped custom resource that sets kubelet and CRI-O parameters such as maxPods, pidsLimit and log size. It satisfies the stem by applying runtime tuning across all worker nodes through the Machine Config Operator.

Why this answer

The ContainerRuntimeConfig custom resource is specifically designed to modify container runtime settings such as maximum pod log size (logSizeMax) and maximum processes per container (pidsLimit) on OpenShift 4.x worker nodes. It works by generating a MachineConfig that updates the CRI-O configuration on the targeted nodes. This resource is part of the Machine Config Operator's API and is the correct way to apply runtime-level tuning across a node pool.

KubeletConfig, while also a node-level configuration, handles kubelet parameters like pod density and eviction thresholds, not container runtime settings.

Exam trap

EX280 often tests the distinction between KubeletConfig and ContainerRuntimeConfig, as both are node-level custom resources; candidates may incorrectly choose KubeletConfig for runtime parameters like log size or pids limit, which are actually handled by ContainerRuntimeConfig.

How to eliminate wrong answers

Option A is wrong because MachineHealthCheck is used to automatically remediate unhealthy nodes by rebooting or replacing them, not to configure runtime parameters. Option B is wrong because KubeletConfig manages kubelet-specific settings such as maxPods, podPidsLimit, and eviction thresholds, but it does not control container runtime parameters like log size or pids limit. Option D is wrong because NodeNetworkConfigurationPolicy is a Kubernetes NMState resource for configuring network interfaces, bonds, VLANs, and routes on nodes, unrelated to container runtime settings.

Full explanation →

140

MCQhard

An administrator is configuring ephemeral storage limits for containers in a namespace. Where must these limits be defined to enforce maximum local scratch space usage per container?

A.ResourceQuota

B.StorageClass

C.LimitRange

D.PersistentVolumeClaim

AnswerC

LimitRange enforces per-container resource bounds within a namespace, including ephemeral-storage requests and limits. Defining the maximum local scratch space there caps each container's writable layer and emptyDir usage, which is exactly the per-container enforcement the administrator needs.

Why this answer

LimitRange objects define per-container (and per-pod) default, minimum, and maximum resource constraints — including ephemeral-storage — within a namespace. To enforce a maximum local scratch space per container, you set the ephemeral-storage max in a LimitRange, which the API server enforces at admission time. ResourceQuota, by contrast, caps aggregate namespace usage, not per-container limits.

Exam trap

EX280 often tests the LimitRange vs ResourceQuota distinction — candidates pick ResourceQuota for per-container limits when the question specifically asks about maximum per-container scratch space, which is a LimitRange responsibility.

How to eliminate wrong answers

Option A is wrong because ResourceQuota enforces total namespace-wide consumption (e.g., sum of all ephemeral-storage requests/limits), not per-container maximums. Option B is wrong because StorageClass defines how persistent volumes are dynamically provisioned, not ephemeral storage limits. Option D is wrong because PersistentVolumeClaim is a request for persistent storage and has no role in limiting container ephemeral (local) storage.

Full explanation →

141

MCQmedium

An administrator is reviewing PersistentVolumes and notices several PVs stuck in a Terminating state. What is the most common reason a PV cannot be deleted immediately?

A.etcd disk space is full.

B.The volume attachment object still holds an active lock, or a finalizer prevents deletion until unmounted.

C.The project quota has been exceeded.

D.The apiserver cache is corrupted and requires a cluster reboot.

AnswerB

A PersistentVolume stays in Terminating because its finalizer, `kubernetes.io/pv-protection`, blocks removal while the volume remains bound or attached. The VolumeAttachment object must release its lock once the node confirms unmounting; only then does the controller clear the finalizer and allow deletion.

Why this answer

A PersistentVolume in a Terminating state is almost always waiting on the Kubernetes volume lifecycle controller to finish detaching the volume from any node that still has it mounted. The VolumeAttachment object holds a lock, and the PV carries the `kubernetes.io/pv-protection` finalizer, which the controller removes only after the volume is fully unmounted and detached. Until that happens, the API server cannot complete deletion, so the PV remains stuck in Terminating.

Exam trap

EX280 often tests whether candidates understand that PV deletion is gated by volume detachment and finalizers, not by generic cluster health issues like etcd space or apiserver cache corruption.

How to eliminate wrong answers

Option A is wrong because a full etcd disk would cause cluster-wide write failures and API server errors, not a targeted PV stuck in Terminating. Option C is wrong because project quota limits the number of objects and resource consumption in a namespace; it does not block PV deletion and would surface as quota admission errors, not a Terminating PV. Option D is wrong because apiserver cache corruption is not a real condition that requires a cluster reboot — the apiserver cache is rebuilt from etcd, and no supported Kubernetes operation requires rebooting the cluster to fix a PV.

Full explanation →

142

MCQeasy

An administrator needs to deploy a StorageClass that automatically provisions volumes only when a PersistentVolumeClaim is created and consumed by a Pod. Which StorageClass parameter determines this behavior?

A.reclaimPolicy: Retain

B.provisioningMode: Immediate

C.volumeBindingMode: WaitForFirstConsumer

D.allowVolumeExpansion: true

AnswerC

WaitForFirstConsumer defers volume provisioning until a Pod using the PVC is scheduled, satisfying the stem's requirement that provisioning occur only on Pod consumption. Immediate mode would provision at PVC creation instead, so this binding mode is the deciding parameter.

Why this answer

'volumeBindingMode: WaitForFirstConsumer' in a StorageClass delays dynamic provisioning and PV binding until a Pod using the PVC is scheduled. This ensures the volume is created in the same topology zone/node as the Pod, which is essential for local storage and topology-constrained cloud volumes. 'Immediate' (the default) provisions as soon as the PVC is created, which can cause scheduling failures if the volume lands in an incompatible zone.

Exam trap

EX280 often tests the exact StorageClass field name and value — candidates pick plausible-sounding but non-existent fields like 'provisioningMode: Immediate' instead of the real 'volumeBindingMode: WaitForFirstConsumer'.

How to eliminate wrong answers

Option A is wrong because reclaimPolicy: Retain controls what happens to the PV after the PVC is deleted (keep vs delete), not when provisioning occurs. Option B is wrong because 'provisioningMode: Immediate' is not a valid StorageClass field — the correct field is volumeBindingMode with values Immediate or WaitForFirstConsumer. Option D is wrong because allowVolumeExpansion: true only permits resizing PVCs after creation; it has nothing to do with provisioning timing.

Full explanation →

143

MCQhard

An administrator configures an EgressFirewall in a namespace to deny all external traffic except for a specific CIDR block. In what order are the rules in an EgressFirewall evaluated?

A.Allow rules are evaluated first, followed by deny rules.

B.Deny rules always take precedence over allow rules regardless of order.

C.In sequential order (top to bottom), stopping at the first matching rule.

D.Alphabetically by rule description.

AnswerC

EgressFirewall rules are evaluated sequentially from top to bottom, with evaluation halting at the first rule that matches the traffic. This deterministic first-match behaviour satisfies the scenario's requirement to deny all external traffic except the specified CIDR block, so the allow rule for that block must precede any broader deny rule.

Why this answer

EgressFirewall rules are evaluated in sequential order from top to bottom, and the first rule that matches the traffic is applied. Once a match is found, no further rules are evaluated. This is similar to firewall rule processing in traditional firewalls.

Therefore, the order of rules is critical for achieving the desired allow/deny behavior.

Exam trap

EX280 often tests the evaluation order of EgressFirewall rules, and candidates may assume that deny rules always win or that allow rules are processed first, leading to incorrect rule placement.

How to eliminate wrong answers

Option A is wrong because there is no implicit priority for allow rules; evaluation is strictly by order. Option B is wrong because deny rules do not automatically take precedence; a deny rule only takes effect if it is encountered before any matching allow rule. Option D is wrong because rules are not evaluated alphabetically by description; descriptions are for human readability only.

Full explanation →

144

Multi-Selecthard

An administrator is troubleshooting an OpenShift Container Platform 4.14 cluster that is failing to upgrade. The Cluster Version Operator (CVO) reports that the upgrade is blocked due to an unhealthy ClusterOperator. Which TWO commands should the administrator use to identify the specific ClusterOperator and its error condition? (Choose two.)

Select 2 answers

A.oc describe clusteroperator <operator-name>

B.oc get clusterversion

C.oc get clusteroperators

D.oc logs -n openshift-cluster-version cluster-version-operator-<pod>

E.oc get pods -n openshift-cluster-version

AnswersA, C

This command provides detailed information about a specific ClusterOperator, including its conditions, related resources, and recent events. It helps the administrator understand why the operator is degraded or not available, such as misconfigured resources or failing pods.

Why this answer

To identify the unhealthy ClusterOperator, the administrator should first list all ClusterOperators with 'oc get clusteroperators' to spot the one with a degraded or unavailable status. Then, 'oc describe clusteroperator <operator-name>' provides in-depth details, including conditions and events, to pinpoint the root cause. The other commands are either too broad or focus on the CVO rather than the specific operator.

Exam trap

The trap here is relying on 'oc get clusterversion' to find the problematic operator, but it only shows the overall upgrade status, not the individual operator health.

Full explanation →

145

Multi-Selecteasy

Which TWO commands are used to check the health and status of the cluster networking operator? (Choose TWO)

Select 2 answers

A.oc get routes --all-nodes

B.oc describe clusteroperator network

C.oc adm network status

D.oc get clusteroperators

E.oc top network

AnswersB, D

`oc describe clusteroperator network` reports the network operator's conditions, versions and reconciliation messages, directly satisfying the stem's requirement to check health and status. Unlike `oc get`, it exposes the detailed condition reasons and last transition times needed to diagnose a degraded cluster networking operator.

Why this answer

Option B, `oc describe clusteroperator network`, is correct because it shows the detailed status of the network ClusterOperator, including its conditions (Available, Progressing, Degraded), related messages, and version, which directly reflects the health of the cluster networking operator. Option D, `oc get clusteroperators`, is correct because it lists all ClusterOperators with their AVAILABLE, PROGRESSING, and DEGRADED columns, letting you quickly verify whether the network operator is healthy. Option A, `oc get routes --all-nodes`, is invalid since `--all-nodes` is not a valid flag for `oc get routes` and routes are not the operator's status object.

Option C, `oc adm network status`, is not a real OpenShift command for checking the network operator. Option E, `oc top network`, is not a valid subcommand of `oc top`, which supports resources like pods and nodes, not network operator health.

Exam trap

EX280 often tests whether candidates know the correct oc subcommands for operator health — fabricated commands like 'oc adm network status' or 'oc top network' look plausible but do not exist, so candidates must recognize the real ClusterOperator inspection commands.

Full explanation →

146

Multi-Selecteasy

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

Select 2 answers

A.oc get storageclass

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

C.oc get clusteroperator kube-apiserver

D.oc adm top storage

E.oc get routes --all-namespaces

AnswersB, C

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

Why this answer

Option B, `oc get pods -n openshift-kube-apiserver`, is correct because in OpenShift the static api-server pods run in the `openshift-kube-apiserver` namespace, so listing pods there shows the running status of each kube-apiserver instance. Option C, `oc get clusteroperator kube-apiserver`, is correct because the `kube-apiserver` ClusterOperator reports the aggregated availability, progressing, and degraded status of the API server across the cluster. Option A, `oc get storageclass`, only lists storage classes and has nothing to do with API server health.

Option D, `oc adm top storage`, is not a valid command for checking API server instances (top subcommands target nodes/pods). Option E, `oc get routes --all-namespaces`, lists OpenShift routes and is unrelated to api-server status.

Exam trap

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

Full explanation →

147

MCQhard

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

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

B.The OAuth client secret is invalid.

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

148

MCQeasy

A developer deploys an application using a Route that terminates TLS using the Edge termination strategy. The developer wants to ensure that all insecure HTTP traffic to the route is automatically redirected to HTTPS. Where must this setting be configured?

A.By modifying the haproxy.config global template ConfigMap in the openshift-ingress namespace.

B.In the Route resource spec.tls.insecureEdgeTerminationPolicy field set to Redirect.

C.In the IngressController custom resource under spec.routeAdmission.wildcardPolicy.

D.In the Service resource annotations using route.openshift.io/termination: redirect.

AnswerB

With edge termination, the router handles TLS, so redirection of plain HTTP must be declared on the Route itself. Setting spec.tls.insecureEdgeTerminationPolicy to Redirect makes the router issue an HTTP 301 to HTTPS for insecure requests.

Why this answer

For an edge-terminated Route, the redirect of insecure HTTP to HTTPS is controlled by spec.tls.insecureEdgeTerminationPolicy set to Redirect. The router (HAProxy) reads this field and issues a 301/302 redirect for any plain HTTP request hitting the route. This is the supported, declarative way to enforce HTTPS on a Route.

Exam trap

EX280 often tests whether candidates reach for global router ConfigMap edits or Service annotations instead of the Route's own spec.tls.insecureEdgeTerminationPolicy field, which is the only supported per-route redirect control.

How to eliminate wrong answers

Option A is wrong because editing the haproxy.config template ConfigMap in openshift-ingress is a global, unsupported hack that affects all routes and is overwritten by the ingress operator. Option C is wrong because spec.routeAdmission.wildcardPolicy on the IngressController governs subdomain/wildcard admission, not HTTP-to-HTTPS redirection. Option D is wrong because route.openshift.io/termination is a Service annotation used for certain load-balancer integrations, not the mechanism that sets redirect behaviour on a Route's TLS spec.

Full explanation →

149

Multi-Selecthard

An administrator must determine why a namespace named 'batch' is stuck in the Terminating state and has remained so for over an hour. They need to identify what is blocking finalization so it can be cleared. (Choose two.)

Select 2 answers

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

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

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

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

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

AnswersA, B

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

Why this answer

A namespace lingers in Terminating only while its spec.finalizers list is non-empty, and the namespace controller holds that finalizer until every namespaced object is gone. The two productive checks are reading the namespace's finalizers to confirm the condition and enumerating surviving API objects to find the resource whose own finalizer is never being cleared, which is typically a custom resource or a Pod.

Exam trap

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

Full explanation →

150

Multi-Selectmedium

Which THREE parameters are commonly found in the SCC 'spec' section?

Select 3 answers

A.seLinuxContext

B.namespaceSelector

C.runAsUser

D.imagePullPolicy

E.allowedCapabilities

AnswersA, C, E

`seLinuxContext` sits in the SCC `spec` section, defining the SELinux context (user, role, type, level) that OpenShift applies to containers in matching pods. It satisfies the stem's requirement for a commonly found `spec` parameter, alongside `seccompProfiles` and `allowedCapabilities`, which govern mandatory access controls.

Why this answer

The SCC (SecurityContextConstraints) 'spec' section defines the security settings that pods may use, and seLinuxContext (A) is a valid spec field that specifies the SELinux context strategy (MustRunAs, RunAsAny) and required level/role/type/user for containers. runAsUser (C) is also a valid spec field that controls the UID strategy (MustRunAsRange, MustRunAsNonRoot, RunAsAny) and the allowed UID range for containers. allowedCapabilities (E) is likewise a valid spec field listing the Linux capabilities containers are permitted to add beyond the default set. namespaceSelector (B) is not an SCC spec parameter—it belongs to NetworkPolicy, PodAffinity, or admission webhook configurations—and imagePullPolicy (D) is a container image field in a Pod spec, not part of SecurityContextConstraints.

Exam trap

EX280 often tests whether candidates can distinguish SCC spec fields (seLinuxContext, runAsUser, allowedCapabilities) from unrelated Kubernetes fields like namespaceSelector and imagePullPolicy — the trap is picking fields that sound security-related but belong to other objects.

Full explanation →

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