Courseiva

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

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

Page 2

Page 3 of 6

Page 4
151
MCQmedium

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

A.--allow-local-volumes
B.--ignore-daemonsets=false
C.--delete-emptydir-data
D.--force-local-storage
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

152
MCQmedium

An administrator wants to check whether any worker nodes in an OpenShift 4.14 cluster are currently unschedulable (cordoned). Which command provides this information quickly?

A.oc get machineconfigpool --cordoned
B.oc describe clusteroperator scheduling
C.oc get nodes
D.oc adm show-cordoned
AnswerC

oc get nodes lists every node with its status column, showing SchedulingDisabled for cordoned nodes, so unschedulable workers are identified immediately without extra flags. This satisfies the quick-check constraint, unlike describe or machine-config inspection, which require per-node queries.

Why this answer

The `oc get nodes` command lists all nodes in the cluster along with their status, including a `SchedulingDisabled` flag that appears when a node is cordoned (unschedulable). This is the fastest and most direct way to check for cordoned worker nodes, as the output immediately shows which nodes have scheduling disabled. No additional flags or subcommands are needed.

Exam trap

EX280 often tests whether candidates know the correct `oc` command to inspect node schedulability, and a common trap is assuming that specialized subcommands like `oc adm show-cordoned` exist when the simple `oc get nodes` already provides the needed information.

How to eliminate wrong answers

Option A is wrong because `oc get machineconfigpool` does not support a `--cordoned` flag; machineconfigpools track MachineConfig application status, not node schedulability. Option B is wrong because `oc describe clusteroperator scheduling` describes the cluster scheduling operator's status, not individual node cordon states; it does not list nodes. Option D is wrong because `oc adm show-cordoned` is not a valid OpenShift command; there is no such subcommand under `oc adm`.

153
MCQeasy

An administrator needs to expose an existing deployment using a quick command without writing a YAML manifest. Which command exposes port 8080 of a deployment named 'my-app' as a Service?

A.oc expose deployment my-app --port=8080
B.oc expose pod my-app --port=8080
C.oc service create my-app --port=8080
D.oc create service my-app --port=8080
AnswerA

The oc expose command generates a Service object directly from an existing resource, with --port specifying the container port to expose. Naming the deployment my-app and port 8080 satisfies the stem's requirement to avoid writing a YAML manifest.

Why this answer

The 'oc expose' command creates a Service from an existing resource. Using 'oc expose deployment my-app --port=8080' generates a Service that targets the deployment's pods on port 8080, without requiring a YAML manifest. This is the standard imperative approach.

Exam trap

The trap is mixing up 'oc expose' with 'oc create service' — candidates forget that 'oc expose' is the imperative shortcut specifically designed for this use case.

How to eliminate wrong answers

Option B is wrong because 'oc expose pod' exposes a single pod, not a deployment, and would not provide the load-balanced Service behavior expected for a deployment. Option C is wrong because 'oc service create' is not a valid oc subcommand. Option D is wrong because 'oc create service' requires a manifest file or explicit parameters and is not the quick expose syntax; 'oc expose' is the correct imperative command.

154
MCQhard

An administrator is troubleshooting a service account named 'cicd-bot' in the 'ci-cd' namespace that is failing to read pods in the 'production' namespace, despite a RoleBinding existing. Upon inspection, the RoleBinding references a Role (not a ClusterRole) in the 'ci-cd' namespace. Why is the service account failing to access resources in 'production'?

A.Standard Roles are namespace-scoped and cannot grant permissions to resources in another namespace
B.Roles cannot reference service accounts as subjects unless they are in the openshift-infra namespace
C.Service accounts cannot use RoleBindings, they require ClusterRoleBindings for any authorization
D.The service account token has expired and must be manually regenerated using oc adm ca
AnswerA

Roles are namespace-scoped, so a Role in 'ci-cd' can only grant access to resources within 'ci-cd'. The RoleBinding therefore cannot extend permissions into 'production', regardless of the subject. To grant cross-namespace access, the binding must reference a ClusterRole combined with a RoleBinding in 'production', or a ClusterRoleBinding.

Why this answer

Roles in OpenShift are namespace-scoped and can only grant permissions to resources within their own namespace. A RoleBinding in the 'ci-cd' namespace referencing a Role in the same namespace cannot grant access to resources in the 'production' namespace. To grant cross-namespace access, a ClusterRole and ClusterRoleBinding (or RoleBinding referencing a ClusterRole) are required.

Exam trap

EX280 often tests the scope of Roles versus ClusterRoles, and candidates may incorrectly assume that a RoleBinding can grant cross-namespace permissions if the Role is defined elsewhere.

How to eliminate wrong answers

Option B is wrong because Roles can reference service accounts as subjects regardless of namespace; the restriction is on the resources, not the subjects. Option C is wrong because service accounts can use RoleBindings for namespace-scoped permissions; ClusterRoleBindings are only needed for cluster-wide access. Option D is wrong because token expiration would cause authentication failure, not authorization failure; the error is about permissions, not token validity.

155
Multi-Selecthard

An administrator needs to restrict a user group named 'contractors' so they can view pods and services, but cannot view secrets across the 'staging' namespace. Which THREE of the following steps or configurations are valid and necessary to achieve this? (Choose THREE)

Select 3 answers
A.Create a ClusterRoleBinding referencing the view ClusterRole and set an exclusion filter for secrets
B.Create a custom Role in the staging namespace that explicitly includes rules for verbs get, list, watch on resources pods and services
C.Bind the custom Role to the contractors group using a RoleBinding in the staging namespace
D.Assign the cluster-admin ClusterRole to the contractors group with a negative weight annotation
E.Omit 'secrets' from the resources list in the custom Role definition
AnswersB, C, E

A custom Role scoped to the staging namespace grants only get, list and watch on pods and services, satisfying the least-privilege constraint. Because RBAC is additive, omitting secrets from the rules denies access to them, as no ClusterRole binding grants it. A RoleBinding then binds this Role to the contractors group.

Why this answer

Option B is correct because a namespaced Role must explicitly grant the desired permissions, and listing resources pods and services with verbs get, list, watch provides exactly the read-only access required in the staging namespace. Option C is correct because a RoleBinding in the staging namespace binds that Role to the contractors group, scoping the permissions to only that namespace. Option E is correct because RBAC is additive and deny-by-default, so simply not including secrets in the Role's resources list ensures the group cannot view secrets.

Option A is incorrect because ClusterRoleBinding grants cluster-wide permissions and RBAC has no exclusion filter mechanism. Option D is incorrect because there is no negative weight annotation concept in Kubernetes RBAC, and cluster-admin would grant full access.

Exam trap

EX280 often tests the misconception that RBAC supports deny rules or exclusion filters — in reality, RBAC is purely additive, so you must omit resources to restrict access.

156
MCQeasy

When configuring an OAuth identity provider of type HTPasswd, which object type must be created to store the username and hashed password pairs?

A.A ServiceAccount with special token annotations
B.A Secret containing the htpasswd flat-file data
C.A ConfigMap containing plain-text user credentials
D.A custom resource of kind HTPasswdProvider in the openshift-config namespace
AnswerB

HTPasswd identity providers read username and bcrypt-hashed password pairs from a flat file, so OpenShift stores that file's contents in a Secret and mounts it into the OAuth pods. A ConfigMap would expose the credentials in plain text, violating the requirement to hold hashed password data securely.

Why this answer

In OpenShift, the HTPasswd identity provider requires a Secret of type Opaque that contains a key named 'htpasswd' holding the flat-file data generated by the htpasswd command. This Secret is created in the openshift-config namespace and referenced in the OAuth custom resource. The Secret stores the username and bcrypt-hashed password pairs, which the OAuth server uses to authenticate users.

Exam trap

EX280 often tests the misconception that ConfigMaps are used for authentication data or that a dedicated custom resource exists for HTPasswd, when in fact a Secret in the openshift-config namespace is required.

How to eliminate wrong answers

Option A is wrong because ServiceAccounts are used for pod identity and API access, not for storing user credential files; they do not hold htpasswd data. Option C is wrong because ConfigMaps store non-sensitive configuration data in plain text and are not used for authentication secrets; storing hashed passwords in a ConfigMap would be insecure and is not how the HTPasswd provider works. Option D is wrong because there is no custom resource kind called HTPasswdProvider; the HTPasswd provider is configured via the OAuth custom resource (kind: OAuth) that references a Secret, not a separate CRD.

157
MCQmedium

A security audit requires identifying all users who have direct cluster-admin privileges assigned via individual user bindings rather than groups. How can an administrator inspect the cluster-admin ClusterRoleBinding subjects?

A.oc describe clusterrolebinding cluster-admin --users-only
B.oc get users --filter='cluster-admin'
C.oc adm policy list-cluster-admins
D.oc get clusterrolebinding cluster-admin -o jsonpath='{.subjects[*]}'
AnswerD

The jsonpath filter extracts only the subjects array from the cluster-admin ClusterRoleBinding, revealing each User and Group entry. This directly satisfies the audit's need to distinguish individual user bindings from group bindings without parsing full YAML output.

Why this answer

The cluster-admin ClusterRoleBinding object stores its subjects (Users, Groups, ServiceAccounts) in the .subjects array of its JSON representation. Using 'oc get clusterrolebinding cluster-admin -o jsonpath="{.subjects[*]}"' extracts every subject entry, allowing the administrator to enumerate exactly which individual users, groups, and service accounts hold cluster-admin. This is the canonical way to audit direct user bindings versus group-derived bindings.

Exam trap

EX280 often tests whether candidates know the exact oc CLI syntax for RBAC inspection — the trap is inventing plausible-sounding flags like '--users-only' or subcommands like 'list-cluster-admins' that do not exist.

How to eliminate wrong answers

Option A is wrong because 'oc describe' does not support a '--users-only' flag — that flag does not exist in the oc CLI, so the command errors out. Option B is wrong because 'oc get users' lists User objects and has no '--filter' flag for role bindings; it cannot correlate users with cluster-admin privileges. Option C is wrong because 'oc adm policy list-cluster-admins' is not a valid subcommand of 'oc adm policy' — the real subcommands are add-cluster-role-to-user, remove-cluster-role-from-user, etc., so this command fails.

158
MCQeasy

Which command allows an administrator to view details of a specific project named 'web-app', including its annotations and status?

A.oc inspect project web-app
B.oc describe project web-app
C.oc show project web-app
D.oc get project web-app --details
AnswerB

`oc describe project web-app` queries the Project resource and renders its full human-readable description, including annotations, status phase, and metadata. Unlike `oc get`, which returns raw fields, `describe` aggregates related events and conditions, directly satisfying the stem's requirement to view annotations and status for the named project.

Why this answer

The `oc describe project web-app` command is correct because `oc describe` is the standard OpenShift/Kubernetes subcommand for retrieving detailed, human-readable information about a resource, including its annotations, status, labels, and related events. For a Project resource, this output aggregates metadata such as the project's display name, description, status phase (Active/Terminating), and any annotations. It is the only option that uses a valid `oc` verb (`describe`) to produce the verbose, multi-section output the question requires.

Exam trap

EX280 often tests the distinction between `oc get` (summary output) and `oc describe` (detailed output with annotations and status), and candidates may incorrectly assume a `--details` flag exists for `oc get` or that `inspect`/`show` are valid verbs.

How to eliminate wrong answers

Option A is wrong because `oc inspect` is not a valid `oc` subcommand; there is no `inspect` verb in the OpenShift CLI, so the command would fail with an unknown command error. Option C is wrong because `oc show` does not exist as an `oc` subcommand; while `show` appears in some other tools, it is not part of the `oc` CLI grammar. Option D is wrong because `oc get project web-app --details` is invalid: `--details` is not a supported flag for `oc get` (the correct flag for extra output is `-o wide` or `-o yaml`), and `oc get` alone returns only a summary table, not the full annotations and status details.

159
MCQmedium

An administrator notices that the Cluster Version Operator (CVO) is blocked during an upgrade because a cluster operator is missing version annotations. Which command allows checking the current status and payload version of the CVO?

A.oc get clusterversion
B.oc adm upgrade status
C.oc get clusteroperators
D.oc version
AnswerA

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

Why this answer

'oc get clusterversion' displays the ClusterVersion resource, which shows the current cluster version, the desired version, the upgrade channel, and the status of the CVO — including conditions like Failing, Progressing, and Available. This is the command that reveals whether the CVO is blocked and what payload version it is targeting.

Exam trap

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

How to eliminate wrong answers

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

160
MCQmedium

An administrator wants to check the status of all Certificate Signing Requests (CSRs) in an OpenShift 4.14 cluster, specifically looking for pending node certificates. Which command should be used?

A.oc adm certificate-status
B.oc get csr
C.oc describe clusteroperator pkcs
D.oc get certificates --all-namespaces
AnswerB

The oc get csr command lists all Certificate Signing Requests cluster-wide with their approval status, letting the administrator identify pending node certificates at a glance. Adding --no-headers or filtering by condition narrows output, but the base command satisfies the requirement to check every CSR's status.

Why this answer

The `oc get csr` command lists all Certificate Signing Requests in the cluster, showing their NAME, AGE, SIGNERNAME, REQUESTEDDURATION, and CONDITION. Pending node CSRs appear with a CONDITION of Pending, which is exactly what an administrator needs to identify certificates awaiting approval. This is the standard OpenShift 4.x command for inspecting CSR status.

Exam trap

The trap is confusing Kubernetes-native CSR objects (managed with `oc get csr`) with cert-manager Certificate CRDs (`oc get certificates`), or inventing plausible-sounding but nonexistent `oc adm` subcommands.

How to eliminate wrong answers

Option A is wrong because `oc adm certificate-status` is not a valid OpenShift subcommand — there is no such verb under `oc adm`. Option C is wrong because `oc describe clusteroperator pkcs` targets a ClusterOperator named 'pkcs', which does not exist; ClusterOperators are named things like kube-apiserver, openshift-apiserver, etc., and this command would return a not-found error. Option D is wrong because `oc get certificates --all-namespaces` retrieves cert-manager Certificate resources (a third-party CRD), not the Kubernetes CSR objects used for node bootstrap and client certificate approval in OpenShift.

161
Multi-Selectmedium

When configuring a NetworkPolicy in OpenShift, which THREE options represent valid components or fields within a NetworkPolicy specification? (Choose THREE)

Select 3 answers
A.podSelector
B.routeSelector
C.clusterIP
D.ingress
E.policyTypes
AnswersA, D, E

podSelector is a required field in the NetworkPolicy spec, defining which pods in the namespace the policy applies to via label matching. It satisfies the stem's requirement for a valid specification component, sitting alongside ingress/egress rules and policyTypes to scope enforcement.

Why this answer

Option A (podSelector) is correct because it is a core field of the Kubernetes/OpenShift NetworkPolicy spec that selects the pods to which the policy applies, using label selectors. Option D (ingress) is correct because ingress is a valid rule block that defines which inbound traffic is allowed to the selected pods, including from, ports, and protocol details. Option E (policyTypes) is correct because it explicitly lists which policy types the NetworkPolicy covers, valid values being Ingress, Egress, or both.

Option B (routeSelector) is not a NetworkPolicy field; routes are OpenShift Route objects and are not selected by NetworkPolicy. Option C (clusterIP) is not a NetworkPolicy field; it is a Service attribute assigned to a Service's virtual IP, not part of the NetworkPolicy specification.

Exam trap

EX280 often tests whether candidates confuse NetworkPolicy fields with Service or Route fields — clusterIP and routeSelector are deliberately planted as plausible-sounding but API-invalid options.

162
Multi-Selecthard

Which THREE items are contained within a Helm Chart structure?

Select 3 answers
A.Dockerfile
B.values.yaml
C.Chart.yaml
D.templates/ directory
E.ImageStream
AnswersB, C, D

values.yaml supplies the default configuration values that templates reference, letting users override settings without editing chart templates. It is a standard top-level file in a Helm chart structure, satisfying the question's requirement for contained items.

Why this answer

B (values.yaml) is correct because it is the default configuration file in a Helm chart that supplies values used to render the templates, allowing users to override settings at install time. C (Chart.yaml) is correct because it is the required chart metadata file containing fields such as apiVersion, name, version, and description that identify and version the chart. D (templates/ directory) is correct because it holds the Kubernetes manifest templates (e.g., deployment.yaml, service.yaml) that Helm renders with values into final YAML.

A (Dockerfile) is not part of the Helm chart structure; it is used to build container images, which Helm charts typically reference rather than contain. E (ImageStream) is an OpenShift-specific API object, not a Helm chart component, so it does not belong.

Exam trap

EX280 often tests the misconception that a Dockerfile is part of a Helm chart — candidates confuse image build artifacts with chart packaging structure.

163
MCQmedium

An administrator needs to verify that the cluster autoscaler is successfully scaling worker nodes in response to pending pods. Which custom resource should the administrator inspect to check the autoscaler configuration and status?

A.NodeScalingOperator resource
B.MachineConfigPool autoscaler status
C.ClusterAutoscaler and MachineAutoscaler
D.ClusterVersion autoscaling spec
AnswerC

Inspect both custom resources: ClusterAutoscaler defines cluster-wide scaling limits and behaviour, while MachineAutoscaler sets per-machine-set minimum and maximum replica bounds. Checking their status conditions confirms whether the autoscaler is actively provisioning nodes in response to pending pods, satisfying the verification requirement.

Why this answer

The ClusterAutoscaler and MachineAutoscaler custom resources are used to configure and check the status of the cluster autoscaler in OpenShift. The ClusterAutoscaler defines the overall autoscaling behavior, while MachineAutoscaler specifies which MachineSets are eligible for scaling. Inspecting these resources reveals whether scaling is occurring and any issues.

Exam trap

EX280 often tests the confusion between MachineConfigPool (which manages node configuration) and autoscaler resources, leading candidates to choose MachineConfigPool for autoscaling status.

How to eliminate wrong answers

Option A is wrong because there is no NodeScalingOperator resource in OpenShift; node scaling is managed by the ClusterAutoscaler and MachineAutoscaler. Option B is wrong because MachineConfigPool does not have an autoscaler status; it manages node configuration, not scaling. Option D is wrong because ClusterVersion does not have an autoscaling spec; it manages cluster version and upgrades.

164
MCQhard

An administrator needs to ensure that if a worker node freezes or becomes unresponsive for more than 5 minutes, the cluster automatically remediates it by deleting and recreating the underlying virtual machine instance. Which OpenShift 4.14 feature should the administrator configure?

A.NodeAutoscaler
B.MachineConfigPool
C.ClusterAutoscaler
D.MachineHealthCheck
AnswerD

MachineHealthCheck continuously monitors node conditions and, when a worker exceeds the configured five-minute unhealthy timeout, triggers the Machine API to delete and recreate the underlying VM instance. This satisfies the stem's automatic remediation constraint, unlike MachineConfigPool or ClusterAutoscaler, which manage configuration and capacity rather than node health.

Why this answer

MachineHealthCheck (MHC) is the OpenShift 4.x feature that monitors node conditions and, when a node is unhealthy beyond a configured timeout, triggers remediation by deleting the Machine object so the Machine API Operator recreates the underlying VM. Configuring 'maxUnhealthy' and 'nodeStartupTimeout' plus a selector for worker nodes achieves the 5-minute freeze remediation described.

Exam trap

EX280 often tests the confusion between ClusterAutoscaler (scales on demand) and MachineHealthCheck (remediates unhealthy nodes) — candidates pick the autoscaler because it sounds like it 'fixes' nodes.

How to eliminate wrong answers

Option A is wrong because NodeAutoscaler is not an OpenShift feature — the correct term is ClusterAutoscaler, and it scales node count based on pending pods, not health. Option B is wrong because MachineConfigPool manages OS-level configuration (Ignition, kubelet, kernel args) for groups of nodes, not health-based remediation. Option C is wrong because ClusterAutoscaler adds or removes nodes based on resource pressure and pod scheduling, not on node unresponsiveness.

165
MCQmedium

You need to assign the 'cluster-reader' ClusterRole to an LDAP group named 'ldap-auditors' across the entire cluster. Which command accomplishes this?

A.oc set cluster-role cluster-reader --group=ldap-auditors
B.oc adm policy add-role-to-group cluster-reader ldap-auditors --global
C.oc adm policy add-cluster-role-to-group cluster-reader ldap-auditors
D.oc create rolebinding ldap-auditors --clusterrole=cluster-reader --group=ldap-auditors --cluster
AnswerC

`oc adm policy add-cluster-role-to-group` binds the ClusterRole to an LDAP group via a ClusterRoleBinding, granting permissions cluster-wide rather than within a single namespace. This satisfies the stem's requirement to assign `cluster-reader` to `ldap-auditors` across the entire cluster, since the group name maps directly to the identity provider's group claim.

Why this answer

`oc adm policy add-cluster-role-to-group` is the canonical OpenShift command that binds a ClusterRole to a group at the cluster scope, creating a ClusterRoleBinding. Passing 'cluster-reader' as the role and 'ldap-auditors' as the group grants the LDAP group cluster-wide read access.

Exam trap

EX280 often tests the distinction between namespaced RoleBindings and cluster-scoped ClusterRoleBindings, so options using `add-role-to-group` or `create rolebinding` look similar but grant the wrong scope.

How to eliminate wrong answers

Option A is wrong because `oc set cluster-role` is not a valid oc subcommand — `set` manages images, env, resources, etc., not RBAC. Option B is wrong because `add-role-to-group` creates a namespaced RoleBinding, and the `--global` flag is not a valid flag for that command; it would not grant cluster-wide access. Option D is wrong because `oc create rolebinding` creates a namespaced RoleBinding and does not accept a `--cluster` flag; cluster-wide bindings require `oc create clusterrolebinding` or the `oc adm policy` command.

166
MCQmedium

An administrator is reviewing why a pod in the `legacy` namespace runs as UID 1000070000 even though the pod manifest does not specify a `runAsUser`. The namespace annotation `openshift.io/sa.scc.uid-range` is `1000070000/10000`. Which SCC behavior explains the observed UID?

A.The SCC's `runAsUser` strategy `MustRunAsRange` mutates the pod to use the first UID in the namespace's allocated range.
B.The SCC's `runAsUser` strategy `RunAsAny` allows the container runtime to pick a random UID from the host's user namespace.
C.The SCC's `fsGroup` strategy `MustRunAs` sets the pod's `runAsUser` to the namespace's supplemental group ID.
D.The SCC's `supplementalGroups` strategy `RunAsAny` causes the kubelet to assign the first UID in the namespace range.
AnswerA

When a pod omits `runAsUser`, an SCC using `MustRunAsRange` assigns a UID from the namespace's allocated range. The range is defined by the `openshift.io/sa.scc.uid-range` annotation, and the first UID in that range is used by default. This explains why the pod runs as 1000070000 without an explicit manifest value.

Why this answer

The `MustRunAsRange` user strategy mutates pods that omit `runAsUser`, assigning the first UID from the namespace's allocated range recorded in the `openshift.io/sa.scc.uid-range` annotation. That is why the pod runs as 1000070000 despite having no explicit user in its manifest. The other strategies either permit any UID, control groups rather than users, or do not assign UIDs at all.

Exam trap

The trap here is assuming the container runtime or kubelet chose the UID, when in fact the SCC admission plugin mutated the pod to the first UID in the namespace range.

167
MCQmedium

Which tool should be used to troubleshoot why an SCC is being rejected for a pod?

A.oc adm top scc
B.oc adm policy scc-review
C.oc get scc --debug
D.oc explain scc
AnswerB

The scc-review subcommand evaluates a pod specification against Security Context Constraints and reports exactly which fields cause rejection, directly satisfying the need to diagnose why an SCC is refused rather than merely listing or binding policies.

Why this answer

'oc adm policy scc-review' is the dedicated diagnostic command that evaluates whether a given pod (or a ServiceAccount with a given set of security context settings) would be admitted by any SCC. It reports which SCCs the subject can use and why a pod may be rejected, making it the correct tool for troubleshooting SCC rejection.

Exam trap

The trap is assuming that 'oc explain scc' or 'oc get scc' will diagnose admission failures — those only show schema or list SCCs. The exam expects you to know that 'oc adm policy scc-review' (and its sibling 'scc-subject-review') is the actual diagnostic command for SCC rejection.

How to eliminate wrong answers

Option A is wrong because 'oc adm top scc' is not a valid command — 'oc adm top' works for nodes and pods (metrics), not SCCs. Option B is correct. Option C is wrong because 'oc get scc --debug' is not a real flag combination for diagnosing admission; --debug is not a supported flag on 'oc get scc' for this purpose.

Option D is wrong because 'oc explain scc' only prints the API field documentation for the SecurityContextConstraints kind — it does not evaluate or diagnose a specific pod's SCC admission.

168
MCQmedium

You need to assign a custom ClusterRole named 'operator-viewer' to all authenticated users cluster-wide. Which command accomplishes this?

A.oc adm policy add-cluster-role-to-group operator-viewer system:authenticated
B.oc adm policy add-cluster-role-to-user operator-viewer --all-users
C.oc set role operator-viewer --cluster --to-all
D.oc create clusterrolebinding all-users --clusterrole=operator-viewer --user=system:everyone
AnswerA

Binding the ClusterRole to the `system:authenticated` group grants it to every authenticated user cluster-wide, satisfying the stem's requirement. `oc adm policy add-cluster-role-to-group` creates a ClusterRoleBinding, which is cluster-scoped, unlike a RoleBinding that would only apply within one namespace.

Why this answer

The command `oc adm policy add-cluster-role-to-group operator-viewer system:authenticated` correctly binds the custom ClusterRole `operator-viewer` to the `system:authenticated` group, which includes all authenticated users cluster-wide. This is the standard OpenShift way to grant a cluster role to a group, and `system:authenticated` is the built-in group automatically assigned to any user who has successfully authenticated. The `add-cluster-role-to-group` subcommand creates a ClusterRoleBinding, ensuring the role applies across all projects and namespaces.

Exam trap

EX280 often tests the distinction between `system:authenticated` and non-existent groups like `system:everyone`, and candidates may incorrectly assume that `--all-users` is a valid flag for `oc adm policy add-cluster-role-to-user`.

How to eliminate wrong answers

Option B is wrong because `oc adm policy add-cluster-role-to-user` does not support an `--all-users` flag; it requires a specific user or `--serviceaccount`, and there is no built-in mechanism to target all users via that subcommand. Option C is wrong because `oc set role` is not a valid command for role bindings; `oc set` is used for modifying resources like environment variables or images, not for policy management. Option D is wrong because `system:everyone` is not a valid user or group in OpenShift; the correct group for all authenticated users is `system:authenticated`, and `system:everyone` does not exist, so the binding would not apply to any real users.

169
MCQmedium

You need to create a Role that allows reading and writing ConfigMaps and Secrets only within the 'database' project. Which API groups and resource types should be included in the rules?

A.apiGroups: ['rbac.authorization.k8s.io'], resources: ['roles', 'rolebindings'], verbs: ['*']
B.apiGroups: [''], resources: ['configmaps', 'secrets'], verbs: ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']
C.apiGroups: [''], resources: ['pods/exec'], verbs: ['create']
D.apiGroups: ['apps'], resources: ['configmaps', 'secrets'], verbs: ['*']
AnswerB

ConfigMaps and Secrets belong to the core API group, represented by the empty string `''`, not `apps` or `batch`. Listing them under `apiGroups: ['']` with the required verbs restricts access to those two resource types within the database project.

Why this answer

ConfigMaps and Secrets belong to the core API group, represented as an empty string ('') in RBAC rules. The correct verbs for read and write access are get, list, watch (read) and create, update, patch, delete (write). This Role, when bound within the 'database' project via a RoleBinding, grants the intended permissions.

Exam trap

EX280 often tests whether candidates know that core Kubernetes resources like ConfigMaps and Secrets use an empty string for apiGroups — the trap is selecting a named API group like 'apps' or 'rbac.authorization.k8s.io' out of habit.

How to eliminate wrong answers

Option A is wrong because it targets the rbac.authorization.k8s.io API group and roles/rolebindings resources, which manage RBAC objects, not ConfigMaps or Secrets. Option C is wrong because pods/exec is a subresource of pods used for executing commands in containers, unrelated to ConfigMaps and Secrets. Option D is wrong because ConfigMaps and Secrets are not in the 'apps' API group — that group contains Deployments, StatefulSets, etc.

170
MCQmedium

An administrator is preparing a custom Security Context Constraint (SCC) that will be granted to a specific ServiceAccount used by a log-forwarding DaemonSet. The DaemonSet pods must be able to mount a hostPath volume at /var/log but must not run as UID 0 and must not use the host network. Which SCC field combination must the administrator set to allow only the hostPath mount while still blocking privileged escalation and host networking?

A.Set allowHostDirVolumePlugin: true, allowPrivilegedContainer: false, and allowHostNetwork: false in the custom SCC.
B.Set allowHostDirVolumePlugin: true, allowPrivilegedContainer: true, and allowHostNetwork: false in the custom SCC.
C.Set allowHostDirVolumePlugin: false, allowPrivilegedContainer: false, and allowHostNetwork: false in the custom SCC.
D.Set allowHostDirVolumePlugin: false, allowPrivilegedContainer: false, and allowHostNetwork: true in the custom SCC.
AnswerA

This combination directly enables the hostPath volume plugin through allowHostDirVolumePlugin while leaving privileged containers and host networking disallowed. It satisfies the requirement to mount /var/log without granting broader host access, and it keeps the SCC aligned with the principle of least privilege for the log-forwarding workload.

Why this answer

A custom SCC must explicitly enable the host directory volume plugin so the DaemonSet can mount /var/log, while privileged containers and host networking remain disabled to preserve isolation. The other combinations either grant excessive privileges that the scenario forbids or disable the hostPath plugin and break the workload's core function.

Exam trap

The trap here is assuming that allowing a hostPath volume automatically requires allowPrivilegedContainer to be true, when the two controls are independent and the host directory plugin alone is sufficient.

171
MCQmedium

You are examining a PersistentVolume in OpenShift and notice its status is Released. What does this indicate?

A.The PV is currently bound to an active PVC and is in use by a running pod.
B.The PV has failed its health check and has been quarantined by the CSI driver.
C.The PV is available for binding by any new incoming PVC request.
D.The PVC associated with the PV has been deleted, but the volume has not yet been reclaimed.
AnswerD

A Released status means the bound PersistentVolumeClaim was deleted, leaving the PersistentVolume without a claim. The volume retains its data and remains unavailable for new claims until an administrator manually reclaims it, either by deleting and recreating the PV or clearing its claimRef, depending on the configured persistentVolumeReclaimPolicy.

Why this answer

A PersistentVolume in Released state means its bound PersistentVolumeClaim was deleted, but the PV has not yet been reclaimed or recycled. The PV still holds the data and remains unavailable for new claims until an administrator manually intervenes (e.g., deletes and recreates the PV, or clears the claimRef). This is distinct from Available (ready for binding) and Bound (actively attached to a PVC).

Exam trap

EX280 often tests the distinction between Available, Bound, and Released PV phases — candidates confuse Released with Available and assume the volume is immediately reusable.

How to eliminate wrong answers

Option A is wrong because a PV actively bound to a PVC and used by a pod shows status Bound, not Released. Option B is wrong because there is no 'quarantined' PV status in Kubernetes/OpenShift; CSI failures surface as Failed or via events, not a Released state. Option C is wrong because Available is the status indicating a PV is free for binding by a new PVC; Released means the claim was deleted but the volume has not been reclaimed.

172
MCQhard

A developer deploys a pod with an emptyDir volume. The application running inside writes temporary files. What happens to these files when the container crashes and restarts within the same pod?

A.The files are backed up to the cluster control plane automatically.
B.The files are preserved because emptyDir lifetime is tied to the pod, not individual containers.
C.The files are deleted immediately because the container filesystem is ephemeral.
D.The volume is unmounted and reattached via the CSI driver.
AnswerB

emptyDir volumes are scoped to the pod's lifetime, not the container's, so a container crash and restart within the same pod leaves the directory intact. Data is only destroyed when the pod itself is deleted or rescheduled to another node.

Why this answer

An emptyDir volume in Kubernetes is created when a pod is assigned to a node and exists for the lifetime of that pod. If a container within the pod crashes and restarts, the emptyDir volume and its data persist because the pod itself has not been deleted. The files are preserved as long as the pod remains on the node.

Exam trap

EX280 often tests the misconception that emptyDir data is lost when a container restarts, but it actually persists until the pod is deleted, so candidates must distinguish between container restarts and pod deletion.

How to eliminate wrong answers

Option A is wrong because emptyDir volumes are not backed up to the control plane; they are local to the node and ephemeral. Option C is wrong because while the container filesystem is ephemeral, the emptyDir volume is separate and persists across container restarts within the same pod. Option D is wrong because emptyDir volumes do not use CSI drivers; they are node-local and managed by kubelet, not by a CSI plugin.

173
MCQhard

An administrator is managing a DeploymentConfig named frontend in an OpenShift 4.14 cluster. The DeploymentConfig has a ConfigChange trigger enabled. The administrator needs to update the container image in the DeploymentConfig without triggering an automatic rollout, so that multiple changes can be made before a manual rollout. Which action should the administrator take?

A.Run oc rollout cancel dc/frontend before making changes, then run oc rollout latest dc/frontend after changes.
B.Run oc edit dc/frontend and change the triggers section to disable the ConfigChange trigger, then apply the change.
C.Run oc rollout pause dc/frontend, make the changes, then run oc rollout resume dc/frontend.
D.Run oc set triggers dc/frontend --remove --from-config, make the changes, then re-add the trigger.
AnswerC

The oc rollout pause command prevents the DeploymentConfig from starting new rollouts, even when triggers fire. After making changes, oc rollout resume allows the rollout to proceed. This is the correct way to batch multiple changes without intermediate rollouts.

Why this answer

Pausing a DeploymentConfig with oc rollout pause is the standard method to temporarily prevent rollouts from starting, even when triggers fire. This allows an administrator to make multiple changes and then resume the rollout to apply them all at once. It is a reversible and non-destructive operation that does not alter the trigger configuration.

Exam trap

The trap here is confusing pausing a rollout with removing or disabling triggers, which permanently changes the DeploymentConfig configuration and is not easily reversible.

174
Multi-Selecteasy

Which THREE of the following are valid build strategies supported by OpenShift BuildConfigs? (Choose three.)

Select 3 answers
A.Jenkinsfile
B.Custom
C.Source
D.HelmBuild
E.Docker
AnswersB, C, E

Custom builds run user-supplied builder images defined in the BuildConfig, letting teams execute arbitrary build logic beyond the Source-to-Image, Docker and Pipeline strategies. This satisfies the stem's requirement for a valid OpenShift build strategy, since Custom is a first-class strategy type alongside the others.

Why this answer

Option B (Custom) is correct because OpenShift BuildConfigs support the Custom build strategy, which lets you define your own builder image that runs a user-supplied build logic and produces the resulting image. Option C (Source) is correct because the Source build strategy (Source-to-Image, S2I) uses a builder image with assemble/run scripts to compile source code into a runnable image. Option E (Docker) is correct because the Docker build strategy builds an image by executing a Dockerfile with the docker build process inside the cluster.

Option A (Jenkinsfile) is not a BuildConfig strategy; Jenkins pipelines are handled by OpenShift Pipelines/Jenkins, not by BuildConfig strategy types. Option D (HelmBuild) is not a supported OpenShift BuildConfig strategy; Helm is a package manager for Kubernetes manifests and is not a build strategy.

Exam trap

EX280 often tests the distinction between BuildConfig strategies and pipeline strategies, tricking candidates into selecting Jenkinsfile as a build strategy when it is actually a pipeline definition.

175
MCQeasy

Which command-line argument can you use to change the output format of 'oc get' to YAML?

A.-o yaml
B.--format yaml
C.--yaml
D.-f yaml
AnswerA

The `-o yaml` flag sets `oc get`'s output format to YAML, satisfying the stem's requirement for a command-line argument that changes the default table output. The `-o` (or `--output`) flag accepts format values including `yaml`, `json` and `wide`, making it the precise mechanism for this scenario.

Why this answer

The `-o` flag (short for `--output`) is the standard way to specify the output format for `oc get` and other `oc` commands. It accepts values like `yaml`, `json`, `wide`, `name`, etc. Therefore, `-o yaml` correctly changes the output to YAML.

Exam trap

EX280 often tests the difference between `-o` (output format) and `-f` (filename), as both are common flags but serve entirely different purposes.

How to eliminate wrong answers

Option B is wrong because `--format` is not a valid flag for `oc get`; the correct flag is `--output` or `-o`. Option C is wrong because `--yaml` is not a recognized flag; YAML output is specified via `-o yaml`. Option D is wrong because `-f` is used to specify a filename or directory (e.g., `-f file.yaml`), not to change output format.

176
MCQeasy

Which command allows you to view the logs of a specific build?

A.oc get build
B.oc describe build
C.oc logs [pod-name]
D.oc logs build/[build-name]
AnswerD

`oc logs build/[build-name]` targets the Build resource directly, streaming output from the build pod that OpenShift creates for each build. This satisfies the stem's requirement to view logs for a specific build, unlike pod- or deployment-scoped alternatives.

Why this answer

The `oc logs` command can target a build object directly by using the `build/[build-name]` syntax, which streams the logs from the build pod that OpenShift creates for that build. This is the canonical way to inspect build output without first looking up the generated pod name. The build name is the value shown in `oc get builds` output.

Exam trap

EX280 often tests whether candidates confuse `oc get`/`oc describe` (metadata and status) with `oc logs` (actual runtime output), and whether they know the `build/<name>` resource-qualified syntax instead of guessing a pod name.

How to eliminate wrong answers

Option A is wrong because `oc get build` only lists build objects and their status columns — it does not retrieve log output. Option B is wrong because `oc describe build` shows metadata, conditions, and events for the build object but not the container stdout/stderr logs. Option C is wrong because `oc logs [pod-name]` requires knowing the ephemeral build pod name, which is not the same as the build name and is not the intended abstraction for build logs.

177
Multi-Selectmedium

Which TWO methods can be used to populate data into a newly created PersistentVolumeClaim during provisioning?

Select 2 answers
A.Setting volumeMode to Populate in the PVC spec.
B.Mounting a container image registry directly via PVC metadata.
C.Referencing an existing PersistentVolumeClaim in the PVC dataSource field for cloning.
D.Referencing a VolumeSnapshot in the PVC dataSource field.
E.Specifying an emptyDir template in the PVC spec.
AnswersC, D

Cloning satisfies the provisioning-time population requirement by using the dataSource field to reference a source PVC, letting the CSI driver copy its contents into the new volume. This works only where the storage class and driver support volume cloning, and the source PVC must reside in the same namespace as the target.

Why this answer

Option C is correct because Kubernetes supports PVC cloning: a new PVC can specify an existing PVC in its spec.dataSource field (dataSource.kind: PersistentVolumeClaim), and the CSI driver then provisions the new volume with a copy of the source PVC's data. Option D is correct because a PVC can reference a VolumeSnapshot via spec.dataSource (dataSource.kind: VolumeSnapshot, apiGroup: snapshot.storage.k8s.io), which restores the snapshot's contents into the newly provisioned volume. Both mechanisms are standard ways to pre-populate a freshly created PVC at provisioning time.

Option A is wrong because volumeMode only accepts Filesystem or Block and has nothing to do with populating data. Option B is wrong because PVC metadata cannot mount or pull from a container image registry. Option E is wrong because emptyDir is a pod-level ephemeral volume type and cannot be specified as a template inside a PVC spec.

Exam trap

EX280 often tests whether candidates confuse Pod-level volume types (emptyDir, configMap, secret) with PVC-level data population mechanisms, or invent non-existent fields like volumeMode: Populate.

178
MCQmedium

An administrator needs to back up application data stored on an OpenShift PVC. Which object must be created to initiate the snapshot process via the CSI driver?

A.VolumeSnapshot
B.BackupCR
C.VolumeSnapshotContent
D.StorageSnapshot
AnswerA

VolumeSnapshot is the CSI snapshot custom resource that references a PersistentVolumeClaim and triggers the driver's CreateSnapshot call. Creating it initiates the snapshot; VolumeSnapshotContent is the resulting cluster-scoped object, and VolumeSnapshotClass defines the driver and deletion policy.

Why this answer

The VolumeSnapshot object is the user-facing custom resource that requests a snapshot of a PersistentVolumeClaim (PVC) when using a CSI driver that supports snapshotting. It is created by the administrator to initiate the snapshot process, and it triggers the creation of a VolumeSnapshotContent object that represents the actual snapshot on the storage backend. This is part of the Kubernetes CSI snapshot API, which OpenShift supports.

Exam trap

EX280 often tests the distinction between user-facing and cluster-scoped resources in the CSI snapshot API, causing candidates to confuse VolumeSnapshot with VolumeSnapshotContent.

How to eliminate wrong answers

Option B is wrong because BackupCR is not a standard Kubernetes or OpenShift object for initiating volume snapshots; it might be confused with backup solutions like Velero, but it is not part of the CSI snapshot mechanism. Option C is wrong because VolumeSnapshotContent is a cluster-scoped resource that represents the actual snapshot on the storage system, but it is not created by the user to initiate a snapshot; it is dynamically provisioned by the CSI driver when a VolumeSnapshot is created. Option D is wrong because StorageSnapshot is not a valid Kubernetes or OpenShift object; it is a distractor that sounds plausible but does not exist in the CSI snapshot API.

179
MCQeasy

You need to allow a specific service account to run pods as root. Which command should you use to associate the 'privileged' SCC with the 'default' service account in the 'web-apps' namespace?

A.oc add scc privileged default -n web-apps
B.oc adm policy add-scc-to-user privileged -z default -n web-apps
C.oc apply scc privileged --user=default -n web-apps
D.oc patch scc privileged -p '{"users": ["default"]}'
AnswerB

The add-scc-to-user subcommand binds an SCC to a service account, and the -z flag targets the 'default' service account while -n scopes it to the web-apps namespace. This grants the account permission to run pods requesting privileged access.

Why this answer

The correct command to associate a Security Context Constraint (SCC) with a service account in OpenShift is 'oc adm policy add-scc-to-user'. The '-z' flag specifies the service account name, and '-n' specifies the namespace. This command adds the 'privileged' SCC to the 'default' service account in the 'web-apps' namespace, allowing pods running under that service account to request privileged access and run as root.

This is the standard administrative operation for granting SCC permissions.

Exam trap

EX280 often tests the confusion between creating/modifying an SCC object and binding an SCC to a user or service account, leading candidates to choose 'oc apply' or 'oc patch' instead of the correct 'oc adm policy add-scc-to-user' command.

How to eliminate wrong answers

Option A is wrong because 'oc add scc' is not a valid OpenShift command; SCC management is done through 'oc adm policy' subcommands. Option C is wrong because 'oc apply scc' is used to create or update an SCC object from a file, not to associate an SCC with a service account, and the '--user' flag is not valid for this purpose. Option D is wrong because patching the SCC directly modifies the SCC's user list globally, which is not namespace-scoped and is not the recommended way to grant SCC access to a service account; it also bypasses the proper RBAC binding mechanism.

180
MCQmedium

An administrator is troubleshooting a pod that is repeatedly restarting in the 'app-prod' namespace. The pod's restart count is high, and the administrator needs to determine the exit code of the last terminated container to identify whether the process exited due to an application error or was killed by the OOM killer. Which single command provides this information most directly?

A.oc logs -n app-prod <pod-name> --previous
B.oc describe pod -n app-prod <pod-name>
C.oc get pod -n app-prod <pod-name> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'
D.oc exec -n app-prod <pod-name> -- cat /var/log/containers/<pod-name>.log
AnswerC

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

Why this answer

The pod's status object contains containerStatuses with lastState.terminated, which records the exit code and reason for the most recent terminated container instance. Querying that field with jsonpath returns the exact exit code, allowing the administrator to distinguish an OOM kill (commonly exit code 137) from an application error (other exit codes). This is more precise than logs or describe output because it reads the authoritative status field directly.

Exam trap

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

181
MCQeasy

An administrator wants to view the public URL assigned to an existing Route named 'webapp'. Which oc command is best suited to extract only the host URL value?

A.oc get route webapp --show-url
B.oc describe route webapp --url
C.oc extract route/webapp --field=host
D.oc get route webapp -o jsonpath='{.spec.host}'
AnswerD

The jsonpath output flag extracts only the host field from the Route object, returning the bare URL without headers or extra fields. This satisfies the requirement to isolate the host value rather than dumping the full YAML or JSON definition.

Why this answer

The `oc get route webapp -o jsonpath='{.spec.host}'` command uses JSONPath to extract exactly the value of the `spec.host` field from the Route object, which is the public URL assigned to the Route. This is the most precise and script-friendly way to retrieve only the host value without any additional formatting or metadata. The `-o jsonpath` output option is a standard Kubernetes/OpenShift mechanism for field-level extraction.

Exam trap

EX280 often tests the difference between `oc get` with output formatting (like `-o jsonpath`) and `oc describe`, as well as invalid flags that seem plausible but are not supported.

How to eliminate wrong answers

Option A is wrong because `--show-url` is not a valid flag for `oc get route`; the command would fail with an unknown flag error. Option B is wrong because `oc describe route` does not support a `--url` flag and would output the full human-readable description, not just the URL. Option C is wrong because `oc extract` is used to extract files from a container image or a ConfigMap/Secret, not to retrieve a single field from a Route resource; the `--field` flag is not valid for this purpose.

182
MCQmedium

A system administrator needs to revoke the 'admin' role from user 'bob' in the 'finance' project without deleting the project or affecting other users. Which command should be used?

A.oc revoke role admin bob --namespace=finance
B.oc delete user bob -n finance
C.oc remove-user bob --project=finance
D.oc adm policy remove-role-from-user admin bob -n finance
AnswerD

`oc adm policy remove-role-from-user` deletes only the named rolebinding entry for bob in the finance namespace, revoking the admin role without touching the project or other users' bindings. The `-n finance` flag scopes the change to that project.

Why this answer

The correct command to revoke a role from a user in a specific project is 'oc adm policy remove-role-from-user admin bob -n finance'. This command removes the role binding that grants the 'admin' role to user 'bob' in the 'finance' namespace, without affecting other users or the project itself.

Exam trap

EX280 often tests the confusion between deleting a user and revoking a role; candidates might think deleting the user is necessary, but that would remove the user entirely, not just the role in one project.

How to eliminate wrong answers

Option A is wrong because 'oc revoke role' is not a valid OpenShift command; the correct subcommand is 'oc adm policy remove-role-from-user'. Option B is wrong because 'oc delete user bob' would delete the user entirely from the cluster, which is not desired and would affect all projects. Option C is wrong because 'oc remove-user' is not a valid command; the correct approach is to remove the role binding, not the user from the project.

183
Multi-Selecthard

Which THREE items can be inspected using 'oc describe' when troubleshooting a failing storage attachment in OpenShift?

Select 3 answers
A.The cluster image registry configuration
B.The PersistentVolumeClaim (to check binding status and provisioner errors)
C.The Pod (to see scheduling or volume mount failure events)
D.The OAuth client credentials secret
E.The PersistentVolume (to verify node attachments and reclaim policies)
AnswersB, C, E

Describing the PVC reveals its binding phase, bound PV, and provisioner or CSI errors recorded as events, directly exposing why attachment stalled. This satisfies the scenario's need to inspect claim-level status during a failing storage attachment.

Why this answer

Option B is correct because 'oc describe pvc <name>' shows the PersistentVolumeClaim's status, bound volume, and provisioner-related events, which directly reveal binding failures or dynamic provisioning errors during a storage attachment problem. Option C is correct because 'oc describe pod <name>' surfaces scheduling decisions and volume mount events (such as FailedMount or FailedAttachVolume), pinpointing why a pod cannot attach or mount its storage. Option E is correct because 'oc describe pv <name>' reports the PersistentVolume's status, claim reference, reclaim policy, and node affinity/attachment details, helping verify whether the volume is available and attachable to the target node.

Option A is not applicable because the cluster image registry configuration is inspected via registry operator resources or configs (for example 'oc get configs.imageregistry.operator.openshift.io'), not as a storage attachment object. Option D is not applicable because OAuth client credentials are stored in a Secret and relate to authentication, not to diagnosing storage attachment failures.

Exam trap

EX280 often tests whether candidates confuse cluster-scoped operator configuration objects (like image registry config) with the specific namespaced resources that actually carry storage status and events.

184
MCQhard

A cluster administrator notices that a user 'bob' is unable to create new projects using the 'oc new-project' command, even though bob can view existing projects. What is the root cause and standard remediation?

A.bob needs an explicit RoleBinding for the 'admin' role in the default namespace
B.bob's user object is missing the 'project-creator' annotation
C.bob lacks the 'self-provisioner' cluster role, which can be granted via cluster-admin binding
D.bob must be added to the cluster-admin group in the oauth configuration
AnswerC

Granting bob the `self-provisioner` cluster role restores his ability to create projects, since OpenShift's project request API authorises creation through that role rather than ordinary namespace write access. A cluster-admin must bind it, typically via `oc adm policy add-cluster-role-to-user self-provisioner bob`, satisfying the stem's remediation requirement.

Why this answer

In OpenShift, the ability for authenticated users to create their own projects is controlled by the 'self-provisioner' ClusterRole, bound via the 'self-provisioners' ClusterRoleBinding to the 'system:authenticated' group by default. If an administrator removes or restricts this binding, users like bob lose the ability to run 'oc new-project' even though they can still view existing projects.

Exam trap

EX280 often tests whether candidates know that project self-provisioning is controlled by the 'self-provisioner' ClusterRole and its binding, not by namespace-level RoleBindings or user annotations.

How to eliminate wrong answers

Option A is wrong because a RoleBinding to 'admin' in the default namespace only grants namespace-scoped permissions there; it does not enable cluster-level project creation. Option B is wrong because there is no 'project-creator' annotation on user objects — project creation is governed by RBAC, not annotations. Option D is wrong because adding bob to cluster-admin would grant far more privilege than needed and is not the standard remediation; the correct fix is restoring the self-provisioner binding.

185
MCQmedium

You are using Kustomize to manage environment-specific configurations. Which file must be present in the base directory to define resources?

A.base.yaml
B.overlay.yaml
C.kustomization.yaml
D.resources.yaml
AnswerC

Kustomize requires a kustomization.yaml file in each directory it builds, including the base, since this file declares the resources, patches and configuration to apply. Without it, the base directory defines no resources and kustomize build fails.

Why this answer

Every Kustomize directory — base or overlay — must contain a kustomization.yaml file, which declares the resources, patches, and transformations for that layer. In the base directory, this file lists the Kubernetes manifests (Deployments, Services, ConfigMaps) that make up the common configuration. Without it, 'kubectl kustomize' or 'oc apply -k' cannot resolve the directory.

Exam trap

EX280 often tests the assumption that a file named after the directory (base.yaml, overlay.yaml) is required, when Kustomize always looks for the fixed name kustomization.yaml.

How to eliminate wrong answers

Option A is wrong because 'base.yaml' is not a recognized Kustomize file name — the tool looks specifically for kustomization.yaml (or kustomization.yml / Kustomization). Option B is wrong because 'overlay.yaml' is not a Kustomize file; overlays are directories that contain their own kustomization.yaml referencing the base. Option D is wrong because 'resources.yaml' is not a Kustomize control file — resources are listed inside kustomization.yaml under the 'resources:' field, not in a separate file by that name.

186
Multi-Selecthard

Which THREE pieces of data can an ImageStream reference?

Select 3 answers
A.Internal registry image
B.Specific image tag
C.Git repository
D.External registry image
E.DeploymentConfig
AnswersA, B, D

An ImageStream can reference an image held in the internal OpenShift registry, resolving it through the integrated registry's image metadata rather than an external source. This satisfies the stem's requirement for a valid reference target, since internal registry images are tracked directly by the ImageStream's tag and image objects.

Why this answer

An ImageStream in OpenShift tracks image references, and it can point to an image in the internal registry (option A), which is the typical case when builds push images to the integrated registry and deployments pull from it. It can also reference a specific image tag (option B), since ImageStreamTags are the mechanism by which an ImageStream maps a tag name to a concrete image ID. Additionally, an ImageStream can reference an image in an external registry (option D), allowing OpenShift to track and import images hosted outside the cluster.

Option C is incorrect because a Git repository is a source for builds (e.g., BuildConfig source), not something an ImageStream references. Option E is incorrect because a DeploymentConfig consumes ImageStreams via triggers or image change parameters; it is not a target that an ImageStream references.

Exam trap

EX280 often tests the confusion between ImageStreams and BuildConfigs, leading candidates to incorrectly select Git repository as an ImageStream reference.

187
MCQeasy

A cluster administrator wants to prevent any pod in the `finance` namespace from requesting the `NET_RAW` capability, which is not needed by the applications there. The administrator plans to modify the SCC bound to the namespace's default ServiceAccount. Which SCC field should be used to explicitly drop `NET_RAW`?

A.`defaultAddCapabilities: ["NET_RAW"]`
B.`seLinuxContext: MustRunAs` with a custom `seLinuxOptions` type of `net_raw`
C.`requiredDropCapabilities: ["NET_RAW"]`
D.`allowedCapabilities: ["NET_RAW"]`
AnswerC

`requiredDropCapabilities` forces the listed capabilities to be removed from every container admitted under the SCC. Putting `NET_RAW` there guarantees no pod using that SCC can retain it, even if the pod manifest requests it. This is the correct field for enforcing a capability restriction across a namespace.

Why this answer

Capability restrictions in an SCC are enforced through `requiredDropCapabilities`, which removes the listed capabilities from every container admitted under that SCC. Listing `NET_RAW` there prevents pods in the `finance` namespace from retaining it, regardless of what the pod manifest requests. The allow list and default-add list have the opposite effect, and SELinux fields govern labels rather than capabilities.

Exam trap

The trap here is confusing `allowedCapabilities` with `requiredDropCapabilities`, since both are lists of capability names but only one removes them.

188
Multi-Selecteasy

Which TWO commands can an administrator use to check the overall status or health of core OpenShift 4.14 cluster operators? (Choose TWO)

Select 2 answers
A.oc get machinesets
B.oc get machineconfigpools
C.oc get csv --all-namespaces
D.oc get clusteroperators
E.oc get clusterversion
AnswersD, E

`oc get clusteroperators` lists every ClusterOperator with its AVAILABLE, PROGRESSING, DEGRESSED and SINCE columns, giving an immediate cluster-wide health summary. It satisfies the stem's requirement to check overall status of core operators, unlike resource-specific or node-level commands.

Why this answer

Option D, `oc get clusteroperators`, is correct because it lists all ClusterOperators and their AVAILABLE, PROGRESSING, and DEGRADED status conditions, which is the primary way to assess the overall health of core OpenShift operators. Option E, `oc get clusterversion`, is correct because it shows the ClusterVersion operator's state, including the current version, update status, and whether the cluster is progressing or failing an upgrade, reflecting overall cluster health. Option A, `oc get machinesets`, only shows MachineSet replicas for machine management and does not report operator health.

Option B, `oc get machineconfigpools`, only reports MachineConfigPool readiness and node configuration status, not operator health. Option C, `oc get csv --all-namespaces`, lists ClusterServiceVersions for Operator Lifecycle Manager-installed operators, not the core cluster operators' health.

Exam trap

EX280 often tests the confusion between core ClusterOperators (managed by the CVO) and OLM-managed ClusterServiceVersions, leading candidates to pick 'oc get csv' as a cluster-health command.

189
MCQeasy

Which command is used to switch the active project context to a namespace named 'staging' in the OpenShift CLI?

A.oc config set-namespace staging
B.oc project staging
C.oc use project staging
D.oc switch-context staging
AnswerB

`oc project staging` changes the active namespace in your kubeconfig context, so subsequent `oc` commands target the staging namespace without repeated `-n` flags. This directly satisfies the stem's requirement to switch project context, since OpenShift projects map one-to-one onto Kubernetes namespaces.

Why this answer

The `oc project <name>` command is the documented OpenShift CLI method for switching the active project (namespace) context for subsequent commands. It updates the current context in the kubeconfig so that all future `oc` commands target the 'staging' namespace without needing `-n staging`. This is functionally equivalent to `oc config set-context --current --namespace=staging` but is the idiomatic OpenShift shortcut.

Exam trap

EX280 often tests whether candidates confuse the OpenShift-specific `oc project` shortcut with generic kubectl-style `oc config` subcommands, so options like `oc config set-namespace` look plausible but do not exist.

How to eliminate wrong answers

Option A is wrong because `oc config set-namespace` is not a valid subcommand — the correct form is `oc config set-context --current --namespace=<name>`. Option C is wrong because `oc use project` is not a real oc command; `use` is not an oc verb. Option D is wrong because `oc switch-context` does not exist; context switching is done via `oc config use-context` or `oc project`.

190
MCQhard

An administrator wants to verify which CSI driver plugins are registered and active in an OpenShift cluster. Which cluster-scoped resource should they query?

A.csidrivers.storage.k8s.io
B.volumesnapshotclasses.snapshot.storage.k8s.io
C.storageclasses.storage.k8s.io
D.csinodes.storage.k8s.io
AnswerA

Querying `csidrivers.storage.k8s.io` lists every registered CSI driver across the cluster, satisfying the cluster-scoped requirement in the stem. Each object records the driver's name and attached volume lifecycle operations, so the administrator can confirm which plugins are active without inspecting individual nodes or pods.

Why this answer

The cluster-scoped resource that lists registered CSI drivers is csidrivers.storage.k8s.io. This resource represents the CSI drivers that are registered with the Kubernetes cluster and provides information about their capabilities, such as whether they support attach/detach operations. Querying this resource shows which CSI drivers are active and available for use.

Exam trap

EX280 often tests the distinction between cluster-scoped and node-scoped CSI resources, and candidates may confuse CSIDriver with CSINode, leading them to choose the wrong resource.

How to eliminate wrong answers

Option B is wrong because volumesnapshotclasses.snapshot.storage.k8s.io defines classes for volume snapshots, not the CSI drivers themselves. Option C is wrong because storageclasses.storage.k8s.io defines storage classes that map to provisioners, but it does not list the CSI drivers directly; it only references them. Option D is wrong because csinodes.storage.k8s.io provides information about the CSI drivers available on each node, but it is not the cluster-scoped resource that lists all registered CSI drivers; it is node-specific.

191
MCQeasy

An administrator wants to pull container images from a private container registry that requires authentication for a specific deployment. Where must the image pull secret be referenced so that the deployment pods can successfully pull the image?

A.As an annotation on the cluster-scoped Namespace object
B.Inside the Route object spec under tls.imagePullSecret
C.In the Deployment configuration spec under template.spec.imagePullSecrets
D.As an environment variable named IMAGE_PULL_SECRET in the container specification
AnswerC

Specifying imagePullSecrets inside the pod template spec ensures pods created by the deployment use the credentials.

Why this answer

The image pull secret must be referenced in the pod template spec under template.spec.imagePullSecrets so that the kubelet uses those credentials when pulling the image for each pod. This field accepts a list of Secret names in the same namespace, and OpenShift injects them into the pod's service account context at pull time. Placing it in the Deployment's pod template ensures every replica created by the ReplicaSet inherits the credential reference.

Exam trap

EX280 often tests whether candidates know that imagePullSecrets belongs in the pod template spec (template.spec.imagePullSecrets), not at the Deployment top level or in unrelated objects like Routes or Namespaces.

How to eliminate wrong answers

Option A is wrong because Namespace annotations are metadata only and are never consumed by the kubelet or container runtime for image authentication. Option B is wrong because a Route object handles ingress traffic and TLS termination; it has no imagePullSecret field and is unrelated to registry authentication. Option D is wrong because IMAGE_PULL_SECRET as an environment variable is just a string passed to the container process and has no effect on the CRI image pull mechanism.

192
Multi-Selectmedium

When managing ImageStreams in OpenShift, which TWO tasks can an administrator perform using oc commands? (Choose two.)

Select 2 answers
A.Creating an alias or tag pointing one ImageStream tag to another using oc tag
B.Running unit tests against container image layers using oc test-image
C.Compiling raw source code into an executable binary using oc tag
D.Importing images from an external container registry into an ImageStream using oc import-image
E.Directly modifying kernel parameters on worker nodes via oc image
AnswersA, D

The oc tag command creates or updates an ImageStreamTag, letting an administrator point one tag at another's image or an external reference. This satisfies the stem's alias requirement, enabling promotion or rollback without rebuilding images.

Why this answer

Option A is correct because the `oc tag` command creates or updates tags and aliases within an ImageStream, allowing one tag to point to another tag or image (e.g., `oc tag myis:latest myis:stable`). Option D is correct because `oc import-image` imports image metadata from an external container registry into an ImageStream, creating or updating the ImageStream tags with the remote image's manifest and layers. Option B is incorrect because there is no `oc test-image` subcommand in OpenShift; unit testing of images is not an `oc` function.

Option C is incorrect because `oc tag` only manages image tag references and does not compile source code into binaries. Option E is incorrect because `oc image` does not modify kernel parameters on worker nodes; kernel tuning is done via MachineConfig or node-level tooling, not image commands.

Exam trap

EX280 often tests whether candidates can separate genuine oc ImageStream operations (tag, import-image) from fabricated commands (test-image, image for kernel tuning) that sound plausible but do not exist.

193
MCQmedium

An administrator needs to perform a graceful maintenance reboot on a worker node named worker-01 in an OpenShift 4.14 cluster without causing application downtime for stateless deployments. Which combination of actions should the administrator perform first?

A.Apply a MachineConfig to the worker MachineConfigPool pausing the updates, then reboot the node.
B.Run 'oc adm cordon worker-01' followed by 'oc adm drain worker-01 --delete-emptydir-data --ignore-daemonsets'.
C.Stop the kubelet service on worker-01 via systemctl and reboot the underlying operating system.
D.Run 'oc delete node worker-01' directly to force the cluster control plane to automatically reschedule workloads.
AnswerB

Cordoning marks worker-01 unschedulable, preventing new pods from landing there, while draining evicts existing pods so their ReplicaSet controllers reschedule them onto remaining nodes. The `--ignore-daemonsets` flag permits eviction despite DaemonSet pods, and `--delete-emptydir-data` clears emptyDir volumes, satisfying the no-downtime constraint for stateless workloads.

Why this answer

The correct sequence is to first cordon the node to mark it unschedulable, preventing new pods from being placed there, then drain it to evict existing pods gracefully. The flags --delete-emptydir-data and --ignore-daemonsets ensure that pods using emptyDir volumes are removed and daemonset pods are ignored, allowing the drain to complete without errors. This approach respects PodDisruptionBudgets and allows stateless workloads to be rescheduled onto other nodes, avoiding downtime.

Exam trap

EX280 often tests the misconception that deleting a node or stopping kubelet is a valid way to evacuate workloads, but the exam expects knowledge of the graceful cordon and drain procedure that respects PDBs and avoids downtime.

How to eliminate wrong answers

Option A is wrong because pausing MachineConfigPool updates only prevents automatic OS updates; it does not evict or reschedule workloads, so rebooting would still cause downtime. Option C is wrong because stopping kubelet abruptly makes the node NotReady, and the control plane will mark pods for deletion after a timeout, but this is not graceful and can cause downtime for stateful or non-replicated pods. Option D is wrong because deleting the node object forces immediate pod eviction without respecting graceful termination or PodDisruptionBudgets, leading to potential downtime and orphaned resources.

194
MCQhard

You have a Helm chart that requires custom values for different environments. Which flag allows you to pass a custom values file?

A.--override
B.--config
C.--set-file
D.--values
AnswerD

`--values` (or `-f`) supplies a YAML file whose keys override the chart's default `values.yaml`, letting you inject environment-specific settings at install or upgrade time. It directly satisfies the stem's requirement to pass custom values per environment, and multiple files can be layered with later ones taking precedence.

Why this answer

The --values flag (or -f) is used with Helm commands like helm install or helm upgrade to specify a YAML file containing custom values that override the chart's default values.yaml. This is the standard way to provide environment-specific configurations. The flag can be used multiple times, with later files taking precedence.

Exam trap

EX280 often tests the distinction between --values and --set-file, as candidates may confuse passing a full values file with setting individual values from files.

How to eliminate wrong answers

Option A is wrong because --override is not a valid Helm flag; Helm does not have an --override option for passing values files. Option B is wrong because --config is not a Helm flag; it might be confused with other tools' configuration flags, but Helm uses --values for this purpose. Option C is wrong because --set-file is used to set individual values from file contents (e.g., --set-file key=path), not to pass a complete values file; it's for specific values, not wholesale overrides.

195
MCQhard

An administrator creates a new project request template that includes a custom RoleBinding. However, when users create new projects, the RoleBinding fails to bind because it references a ClusterRole that does not exist in the template namespace. How are ClusterRoles referenced in project templates resolved?

A.ClusterRoles must be defined inside the same project request template YAML file.
B.ClusterRoles must be created cluster-wide prior to template instantiation because RoleBindings within the template reference them.
C.Project request templates do not support RoleBindings; only ResourceQuotas are allowed.
D.The RoleBinding must use a Namespaced Role instead of a ClusterRole.
AnswerB

ClusterRoles are cluster-scoped resources, so a RoleBinding inside a project template can only reference one that already exists cluster-wide. The template's namespace-scoped RoleBinding cannot create or resolve a missing ClusterRole, so the referenced ClusterRole must pre-exist before instantiation to satisfy the binding.

Why this answer

RoleBindings inside a project request template reference ClusterRoles by name, and those ClusterRoles must already exist cluster-wide before the template is instantiated. The template does not embed or create ClusterRoles; it only creates namespaced resources in the new project. If the referenced ClusterRole is missing, the RoleBinding fails to bind.

Exam trap

EX280 often tests the scope distinction between namespaced and cluster-scoped resources — candidates forget that ClusterRoles cannot be defined inside a namespaced project template and must pre-exist cluster-wide.

How to eliminate wrong answers

Option A is wrong because project request templates create namespaced objects in the new project — they cannot define cluster-scoped ClusterRoles inside the template YAML. Option C is wrong because project request templates do support RoleBindings (and RoleBindings referencing ClusterRoles) in addition to ResourceQuotas and LimitRanges. Option D is wrong because the issue is not the use of a ClusterRole — ClusterRoles are the correct, intended reference for shared permissions; the problem is that the ClusterRole does not exist yet.

196
Multi-Selecteasy

Which THREE of the following commands are valid OpenShift CLI commands for managing user policies and role assignments? (Choose THREE)

Select 3 answers
A.oc user modify-role
B.oc set policy-binding
C.oc adm policy add-role-to-user
D.oc adm policy remove-role-from-user
E.oc adm policy add-cluster-role-to-group
AnswersC, D, E

add-role-to-user binds a ClusterRole or local Role to a user within a namespace, creating a RoleBinding. It is a valid oc adm policy subcommand for granting role assignments, satisfying the requirement to manage user policies via the CLI.

Why this answer

Option C, `oc adm policy add-role-to-user`, is correct because it is the standard administrative command for binding a role to a user within a specific project namespace, granting that user the permissions defined by the role. Option D, `oc adm policy remove-role-from-user`, is correct because it is the counterpart command that removes an existing role binding from a user in a project, revoking those permissions. Option E, `oc adm policy add-cluster-role-to-group`, is correct because it binds a ClusterRole to a group at the cluster scope, which is the proper way to grant cluster-wide permissions to multiple users at once.

Option A, `oc user modify-role`, is not a valid OpenShift CLI command; user objects are managed with commands like `oc adm policy` or `oc create user`, and there is no `modify-role` subcommand. Option B, `oc set policy-binding`, is also invalid; the `oc set` command manages resources like env, image, and resources, not policy bindings, which are handled exclusively through `oc adm policy`.

Exam trap

EX280 often tests whether candidates can distinguish real `oc adm policy` subcommands from plausible-sounding but nonexistent commands like `oc user modify-role` or `oc set policy-binding` — memorizing the `oc adm policy` verb set is essential.

197
MCQeasy

An administrator wants to test network connectivity from a pod named 'app-pod-1' to a service port on 'backend-service' using TCP. Which tool is commonly available and ideal for testing TCP port connectivity inside a container?

A.ifconfig
B.traceroute
C.nc
D.ping
AnswerC

nc (netcat) opens a raw TCP connection to a host and port, so it directly verifies whether the service port accepts connections from inside the container. It is present in most images and needs no cluster-level tooling, unlike curl or ping.

Why this answer

'nc' (netcat) is the standard tool for testing TCP/UDP port connectivity from inside a container because it can open a raw TCP connection to a specific host and port, e.g., 'nc -zv backend-service 8080'. It is included in many base images and is the go-to utility for verifying that a Service port is reachable and that network policies or firewalls are not blocking traffic.

Exam trap

EX280 often tests the difference between ICMP-based tools (ping, traceroute) and TCP-based tools (nc, curl) — candidates pick ping because it's familiar, but ping cannot verify TCP port connectivity.

How to eliminate wrong answers

Option A (ifconfig) is wrong because it only displays network interface configuration (IP addresses, MTU, etc.) and cannot test connectivity to a remote port. Option B (traceroute) is wrong because it traces the network path hop-by-hop using ICMP/UDP and does not verify TCP port reachability — it also often fails in containers due to missing privileges. Option D (ping) is wrong because it uses ICMP echo requests, which test host reachability, not TCP port availability, and ICMP is frequently blocked in Kubernetes environments.

198
Multi-Selecthard

Which TWO of the following conditions must be met for a ServiceAccount from 'namespace-a' to successfully access API resources in 'namespace-b'? (Choose TWO)

Select 2 answers
A.The source namespace must disable its LimitRange objects.
B.An administrative override annotation must be placed on the target namespace.
C.A RoleBinding must exist in 'namespace-b' referencing the ServiceAccount as 'system:serviceaccount:namespace-a:sa-name'.
D.The ServiceAccount must be granted cluster-admin rights cluster-wide.
E.A Role or ClusterRole must grant the necessary API verb permissions.
AnswersC, E

A RoleBinding in 'namespace-b' grants permissions within that namespace only, satisfying the cross-namespace access constraint. Referencing the ServiceAccount as 'system:serviceaccount:namespace-a:sa-name' correctly identifies the subject from the foreign namespace, since RoleBindings can bind subjects from any namespace while their Role's permissions remain scoped to their own namespace.

Why this answer

Option C is correct because Kubernetes RBAC bindings are namespaced: to grant a ServiceAccount from namespace-a permissions in namespace-b, a RoleBinding must be created in namespace-b that references the subject as 'system:serviceaccount:namespace-a:sa-name'. Option E is correct because the RoleBinding only associates the subject with permissions; the actual API verb permissions (get, list, watch, create, etc.) on the target resources must be defined in a Role (namespaced) or ClusterRole that the binding references. Option A is incorrect because LimitRange objects only enforce resource quota defaults/limits on pods and containers and have no bearing on RBAC authorization.

Option B is incorrect because Kubernetes RBAC has no 'administrative override annotation' mechanism for namespaces; access is governed solely by Roles/ClusterRoles and their bindings. Option D is incorrect because cluster-admin is not required and would be excessive; a namespaced Role plus RoleBinding in namespace-b is sufficient and follows least privilege.

Exam trap

EX280 often tests the misconception that cross-namespace access requires cluster-admin or a special annotation, when in fact it is achieved with a namespaced RoleBinding referencing the fully qualified ServiceAccount name plus a Role granting the verbs.

199
MCQeasy

What is the primary function of a MachineSet in an OpenShift 4.14 cluster running on a cloud provider?

A.To load balance ingress traffic across worker nodes.
B.To ensure a specified number of identical machine instances are running and healthy.
C.To manage persistent volume claims across storage backends.
D.To group cluster nodes by operating system kernel version.
AnswerB

A MachineSet maintains a declared replica count of identical machines, reconciling actual state against desired state so the specified number stay running and healthy. This satisfies the stem's requirement for the primary function: managing machine replicas on a cloud provider, distinct from MachineConfig, which configures nodes rather than provisioning them.

Why this answer

A MachineSet's primary function is to maintain a declared number of identical Machine objects (and therefore Nodes) in an OpenShift 4 cluster. It is the cloud-provider-aware controller that reconciles desired replica count with actual running instances, replacing failed or deleted machines automatically.

Exam trap

EX280 often tests the confusion between MachineSets (infrastructure lifecycle) and MachineConfigPools (node configuration), so candidates pick answers about kernel versions or configuration grouping.

How to eliminate wrong answers

Option A is wrong because ingress traffic load balancing is handled by the Ingress Controller and cloud load balancers, not MachineSets. Option C is wrong because persistent volume claims are managed by the PersistentVolume subsystem and CSI drivers, not MachineSets. Option D is wrong because grouping nodes by kernel version is not a MachineSet function; MachineConfigPools handle node configuration grouping.

200
Multi-Selecthard

During etcd troubleshooting, an administrator suspects quorum loss or follower synchronization issues. Which THREE commands or etcdctl actions performed inside an etcd pod can verify etcd health and cluster state? (Choose THREE)

Select 3 answers
A.etcdctl snapshot restore
B.etcdctl defrag
C.etcdctl endpoint status
D.etcdctl member list
E.etcdctl endpoint health
AnswersC, D, E

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

Why this answer

Option C, `etcdctl endpoint status`, is correct because it queries each endpoint and returns the member ID, raft term, raft index, leader ID, and whether the endpoint is a leader or follower, which directly reveals quorum and follower synchronization state. Option D, `etcdctl member list`, is correct because it enumerates all cluster members with their IDs, peer URLs, client URLs, and names, allowing the administrator to confirm the expected member count and detect missing or unhealthy members that would cause quorum loss. Option E, `etcdctl endpoint health`, is correct because it probes each endpoint and reports whether the endpoint is healthy and able to respond, which is the standard way to verify etcd health across the cluster.

Option A, `etcdctl snapshot restore`, is not a verification action; it rebuilds a new data directory from a snapshot and is used for recovery, not for checking health or cluster state. Option B, `etcdctl defrag`, is not a verification action either; it compacts the backend database to reclaim space and can temporarily block reads, so it does not report health or cluster membership.

Exam trap

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

201
MCQhard

You need to perform a canary deployment by shifting traffic between two versions of your app. What is the standard way to accomplish this in OpenShift without using a Service Mesh?

A.Create two separate Routes
B.Modify the Deployment strategy
C.Use the 'oc scale' command
D.Use Route weights
AnswerD

Route weights let you split incoming traffic across multiple Services by assigning relative percentages, so you can gradually shift requests from the old version to the new one. This is the native OpenShift mechanism when no Service Mesh is available.

Why this answer

In OpenShift, a Route can be configured with multiple backends (services) and each backend can be assigned a weight. By setting different weights, you can split traffic between two versions of your application, enabling a canary deployment. This is the standard method without a Service Mesh because it leverages the built-in HAProxy router's weighted round-robin capabilities.

The weights are integers that represent relative proportions of traffic; for example, 80 and 20 would send 80% to one service and 20% to the other.

Exam trap

EX280 often tests the misconception that scaling replicas or using multiple Routes can achieve canary deployments, but the key is that only Route weights provide native traffic splitting without a Service Mesh.

How to eliminate wrong answers

Option A is wrong because creating two separate Routes would expose two different hostnames or paths, requiring clients to choose which version to access; it does not automatically split traffic between versions on the same endpoint. Option B is wrong because modifying the Deployment strategy (e.g., RollingUpdate) controls how pods are replaced during an update, not how traffic is distributed between two simultaneously running versions; it cannot achieve a canary release with fine-grained traffic control. Option C is wrong because 'oc scale' only adjusts the number of pod replicas for a Deployment or ReplicationController; while scaling can influence the proportion of pods, it does not directly control traffic routing and is not a reliable or standard way to split traffic between versions.

202
MCQhard

An administrator observes that pods in a specific namespace are unable to resolve external domain names (e.g., www.redhat.com) while internal service resolution works perfectly. What is the most likely cause of this issue in CoreDNS configuration?

A.The API server service is missing endpoint IPs.
B.NodePort range exhaustion prevents external DNS packets from traversing worker nodes.
C.The cluster ingress controller is blocking external UDP port 53.
D.The Corefile in the cluster DNS operator configuration has incorrect or missing forward plugins for external resolvers.
AnswerD

Internal names resolve because CoreDNS serves cluster zones locally, but external lookups require the forward plugin pointing to upstream resolvers. A missing or incorrect forward directive in the Corefile means external queries have no upstream, so only cluster-internal resolution succeeds.

Why this answer

CoreDNS handles all DNS resolution in OpenShift, and its behavior is driven by the Corefile managed by the DNS Operator. Internal service names resolve via the kubernetes plugin, but external names like www.redhat.com require the forward plugin pointing to upstream resolvers (e.g., /etc/resolv.conf or explicit IPs). If the forward plugin is missing or misconfigured, internal resolution still works while external lookups fail with SERVFAIL or NXDOMAIN.

Exam trap

EX280 often tests the misconception that DNS failures are always network or firewall issues, when in OpenShift the Corefile's forward plugin configuration is the usual culprit for selective external resolution failures.

How to eliminate wrong answers

Option A is wrong because missing API server endpoints would break cluster API access and internal service discovery, not selectively break external DNS resolution. Option B is wrong because NodePort range exhaustion affects Service exposure on nodes, not outbound UDP/53 traffic from pods to CoreDNS or upstream resolvers. Option C is wrong because the ingress controller handles HTTP/HTTPS ingress traffic, not pod DNS queries, which are resolved by CoreDNS via the cluster DNS service IP.

203
MCQmedium

An administrator needs to check the status of all MachineSets in an OpenShift 4.14 cluster to see how many worker machines are currently provisioned and running. Which command should be used?

A.oc adm get machines
B.oc get cluster-infrastructure
C.oc get machineconfigpools
D.oc get machinesets -A (or within openshift-machine-api)
AnswerD

MachineSets are namespaced custom resources under openshift-machine-api, so listing them across all namespaces with oc get machinesets -A reveals every MachineSet, its desired replicas and current machine count, showing how many worker machines are provisioned and running cluster-wide.

Why this answer

MachineSets are the OpenShift 4 resource that manages the desired and current number of machines per availability zone for a pool. Running 'oc get machinesets -A' (or scoped to openshift-machine-api) lists all MachineSets with their desired, current, and ready replica counts, which is exactly what the administrator needs to see how many worker machines are provisioned and running.

Exam trap

EX280 often tests the distinction between MachineSets (machine provisioning counts) and MachineConfigPools (node configuration rollout state), and candidates frequently pick machineconfigpools when asked about machine counts.

How to eliminate wrong answers

Option A is wrong because 'oc adm get machines' is not a valid command form — 'oc adm' does not have a 'get' subcommand for machines; the correct resource query is 'oc get machines'. Option B is wrong because 'oc get cluster-infrastructure' is not a real resource — the infrastructure object is 'oc get infrastructure cluster' and it describes platform type, not machine counts. Option C is wrong because MachineConfigPools report node configuration rollout state (UPDATED, UPDATING, DEGRADED), not the number of provisioned machines.

204
Multi-Selectmedium

An administrator needs to create a new OpenShift build using a BuildConfig. Which TWO build strategies are natively supported out-of-the-box by OpenShift? (Choose two.)

Select 2 answers
A.Source (S2I)
B.Ansible
C.Knative
D.Helm
E.Docker
AnswersA, E

Source-to-Image is a native OpenShift build strategy, compiling application source against a builder image to produce a runnable image without a Dockerfile. It satisfies the BuildConfig requirement directly, alongside Docker and custom strategies, and needs no additional operator installation.

Why this answer

Option A (Source, i.e., Source-to-Image/S2I) is correct because OpenShift natively supports the Source build strategy, which injects application source into a builder image and produces a runnable image without a Dockerfile. Option E (Docker) is correct because the Docker build strategy is a built-in OpenShift strategy that builds an image from a Dockerfile using the container runtime. These are two of the standard strategies available in a BuildConfig (alongside Custom and Pipeline).

Option B (Ansible) is not a native BuildConfig strategy; Ansible automation is typically run via Ansible Automation Platform or as a custom build, not as a built-in strategy. Option C (Knative) is a serverless/eventing platform, not a BuildConfig build strategy. Option D (Helm) is a package manager for Kubernetes manifests, not an OpenShift build strategy.

Exam trap

EX280 often tests the exact set of native build strategies — candidates may incorrectly include Helm or Ansible because they are common in DevOps toolchains, but only Source and Docker are BuildConfig strategies.

205
Multi-Selecthard

An OpenShift cluster node is reporting High CPU and Memory pressure. Which THREE commands or tools can an administrator use to investigate resource bottlenecks on that node? (Choose THREE)

Select 3 answers
A.oc describe node <node-name>
B.oc adm top nodes
C.oc get events --namespace=default
D.oc logs deployment/cluster-version-operator
E.oc debug node/<node-name> -- chroot /host top
AnswersA, B, E

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

Why this answer

Option A, `oc describe node <node-name>`, is correct because it surfaces the node's Conditions (MemoryPressure, DiskPressure, PIDPressure), Allocatable vs Capacity, and the resource requests/limits of every scheduled pod, which directly reveals what is consuming the node. Option B, `oc adm top nodes`, is correct because it queries the metrics pipeline (metrics-server) to show live CPU and memory usage and percentage per node, giving an immediate quantitative view of the bottleneck. Option E, `oc debug node/<node-name> -- chroot /host top`, is correct because it launches a privileged debug pod on the node, chroots into the host filesystem, and runs `top` against the host's processes, exposing the actual OS-level consumers of CPU and memory.

Option C, `oc get events --namespace=default`, is not appropriate because events are namespaced and scoped to workloads in that namespace, not node-level resource pressure. Option D, `oc logs deployment/cluster-version-operator`, is not appropriate because CVO logs concern cluster version upgrades and reconciliation, not node resource bottleneck diagnosis.

Exam trap

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

206
MCQmedium

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

A.oc network test db.example.com 3306
B.oc exec <pod-name> -- nc -zv db.example.com 3306
C.oc adm port-forward pod/<pod-name> 3306:3306
D.oc debug pod/<pod-name> -- test-connection
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

207
MCQhard

An administrator wants to configure a NetworkPolicy that allows incoming traffic only from pods with the label 'role=frontend' residing in any namespace, provided those namespaces have the label 'environment=production'. How should the namespaceSelector and podSelector be combined?

A.By referencing an external ClusterRole binding with label selectors
B.In the same ingress 'from' array item, combining namespaceSelector and podSelector
C.Using a peerSelector object that nests both labels
D.In separate ingress rules, where one rule has namespaceSelector and another has podSelector
AnswerB

Placing namespaceSelector and podSelector in the same from array item ANDs them, so traffic must originate from a pod labelled role=frontend within a namespace labelled environment=production. Separate array items would OR the conditions, breaking the requirement.

Why this answer

In Kubernetes NetworkPolicy, when you specify a single ingress rule with a 'from' array item that contains both namespaceSelector and podSelector, the two selectors are ANDed together. This means traffic is allowed only from pods that match the podSelector AND reside in namespaces that match the namespaceSelector. This exactly meets the requirement: pods with label 'role=frontend' in any namespace labeled 'environment=production'.

Exam trap

EX280 often tests the difference between AND and OR semantics in NetworkPolicy selectors, trapping candidates who assume that separate rules combine with AND instead of OR.

How to eliminate wrong answers

Option A is wrong because NetworkPolicy does not reference ClusterRole bindings; that is an RBAC concept, not a network policy selector. Option C is wrong because there is no 'peerSelector' object in the NetworkPolicy API; the correct fields are 'namespaceSelector' and 'podSelector' within a NetworkPolicyPeer. Option D is wrong because placing namespaceSelector and podSelector in separate ingress rules creates an OR condition, allowing traffic from any pod in the selected namespaces OR from pods with the label in any namespace, which is broader than intended.

208
MCQhard

An administrator wants to use raw block storage (Block Volume Mode) rather than a mounted filesystem for a high-performance database running on OpenShift. How should the volume mode be specified in the PersistentVolumeClaim?

A.mountOptions: [ "raw" ]
B.accessMode: RawBlock
C.storageType: Unformatted
D.volumeMode: Block
AnswerD

Setting `volumeMode: Block` in the PVC spec requests a raw block device, so OpenShift binds a PersistentVolume and presents it to the pod as an unformatted block device rather than mounting a filesystem. This satisfies the stem's requirement for raw block storage, letting the database manage its own I/O directly.

Why this answer

Raw block storage is requested by setting 'volumeMode: Block' in the PersistentVolumeClaim spec. This tells the CSI driver and kubelet to expose the volume as an unformatted block device (e.g., /dev/xvda) inside the pod rather than mounting a filesystem, which is required for databases that manage their own I/O and formatting.

Exam trap

EX280 often tests whether candidates know the exact field name 'volumeMode: Block' — distractors like 'accessMode: RawBlock' or 'mountOptions: ["raw"]' exploit confusion between access modes, mount options, and volume modes.

How to eliminate wrong answers

Option A is wrong because 'mountOptions: ["raw"]' is not a valid Kubernetes field for requesting block mode — mountOptions only apply to filesystem mounts and 'raw' is not a recognized mount option. Option B is wrong because 'accessMode: RawBlock' is invalid; accessModes are ReadWriteOnce, ReadOnlyMany, ReadWriteMany, and ReadWriteOncePod, none of which is 'RawBlock'. Option C is wrong because 'storageType: Unformatted' is not a Kubernetes PVC field at all — it's a fabricated key.

209
MCQmedium

An administrator needs to temporarily prevent the Machine Config Operator from applying pending MachineConfig changes to the worker nodes while performing troubleshooting. How should the administrator accomplish this?

A.Patch the worker MachineConfigPool to set 'spec.paused: true'.
B.Delete all pending MachineConfig objects from the cluster.
C.Scale down the machine-config-operator deployment in openshift-machine-config-operator to zero replicas.
D.Annotate all worker nodes with 'machineconfiguration.openshift.io/paused=true'.
AnswerA

Setting spec.paused to true on the worker MachineConfigPool halts the Machine Config Operator's rollout to those nodes, so pending MachineConfig changes are not applied during troubleshooting. Unpausing resumes rendering and application of the queued configurations.

Why this answer

Setting 'spec.paused: true' on the worker MachineConfigPool tells the Machine Config Operator to stop rendering and applying new MachineConfigs to that pool. This is the documented, supported way to temporarily halt MCO updates during troubleshooting without deleting configs or disrupting the operator itself. Once troubleshooting is complete, setting 'paused: false' resumes normal reconciliation.

Exam trap

EX280 often tests the assumption that you must delete or disable the MCO to stop updates — the trap is not knowing that 'spec.paused' on the MachineConfigPool is the supported, scoped mechanism.

How to eliminate wrong answers

Option B is wrong because deleting pending MachineConfig objects destroys the desired configuration and would require recreating them; it also doesn't prevent the MCO from applying other changes. Option C is wrong because scaling down the machine-config-operator deployment to zero replicas disables the entire MCO cluster-wide, affecting master and other pools, and is not a supported troubleshooting method. Option D is wrong because there is no 'machineconfiguration.openshift.io/paused' node annotation — pausing is controlled at the MachineConfigPool level, not per-node.

210
Multi-Selectmedium

Which TWO conditions will prevent a pod from successfully mounting a PersistentVolumeClaim?

Select 2 answers
A.The pod is running in the default project.
B.The PVC is in a Pending state because it failed to bind or provision.
C.The volume is already attached to another node and cannot be multi-attached (RWO constraint).
D.The StorageClass has allowVolumeExpansion set to true.
E.The pod namespace has excess CPU limits.
AnswersB, C

A Pending PVC has no bound PersistentVolume, so the kubelet cannot resolve the claim to a volume source when constructing the pod's volume mounts. The mount therefore fails, satisfying the stem's requirement that the pod cannot successfully mount the claim. Binding must complete before any pod referencing that claim can start.

Why this answer

Option B is correct because a PersistentVolumeClaim must be Bound before a pod can mount it; if the PVC remains Pending due to a binding or dynamic provisioning failure (e.g., no matching PV, missing StorageClass, or provisioner error), the kubelet cannot attach and mount the volume, so the pod stays in ContainerCreating. Option C is correct because a ReadWriteOnce (RWO) PersistentVolume can only be attached to a single node at a time; if the volume is already attached to another node, the new pod's mount fails with a Multi-Attach error until the volume is detached. Option A is wrong because running in the default namespace does not by itself prevent PVC mounting—namespaces only affect which PVCs/PVs are visible, and a valid PVC in the same namespace works fine.

Option D is wrong because allowVolumeExpansion=true merely permits resizing a PVC after creation and has no negative effect on mounting. Option E is wrong because CPU limits are a scheduling/resource concern and do not block volume attach or mount operations.

Exam trap

EX280 often tests whether candidates confuse PVC binding state and access mode constraints with unrelated factors like namespace, CPU limits, or StorageClass expansion settings.

211
Multi-Selectmedium

An administrator is preparing a custom SecurityContextConstraints (SCC) named app-scc to allow pods to run with a specific user ID and to use the host network. Which two fields must be set in the SCC to achieve these requirements? (Choose two.)

Select 2 answers
A.allowPrivilegedContainer: true
B.allowHostNetwork: true
C.readOnlyRootFilesystem: true
D.runAsUser: MustRunAs with a specific UID range
E.seLinuxContext: RunAsAny
AnswersB, D

The allowHostNetwork field, when set to true, permits pods to use the host's network namespace. This is necessary for the pods to bind to host ports or access host network interfaces. Without this field, the SCC will deny any pod that requests hostNetwork: true in its spec.

Why this answer

The runAsUser field with MustRunAs ensures the pod runs with a specific UID, and allowHostNetwork enables the use of the host network namespace. These two fields directly address the stated requirements. Other fields like allowPrivilegedContainer or seLinuxContext are unrelated and would unnecessarily broaden the SCC's permissions.

Exam trap

The trap here is confusing container-level securityContext fields with SCC fields, such as assuming readOnlyRootFilesystem is part of an SCC, when it is not.

212
MCQhard

A team runs a Deployment named catalog-api in project retail. After a configuration change, pods crash with an application error, and the administrator needs to return the Deployment to the last known-good revision. The administrator runs oc rollout history deployment/catalog-api and sees revision 7 as the current one. Which single command restores the previous working revision?

A.oc delete deployment/catalog-api && oc apply -f catalog-api-backup.yaml
B.oc rollout undo deployment/catalog-api --to-revision=6
C.oc rollout restart deployment/catalog-api
D.oc set image deployment/catalog-api catalog-api=registry.example.com/catalog-api:previous
AnswerB

This is correct because the undo subcommand with --to-revision restores the pod template recorded for the specified earlier revision and then triggers a rollout of that template. Revision 6 precedes the failing revision 7, so it represents the last known-good state. The Deployment controller creates a new ReplicaSet from the restored template, returning the application to service without manual editing.

Why this answer

Deployment revisions are retained in the controller's ReplicaSet history, so the last known-good pod template can be restored by undoing to a specific revision. Using the undo subcommand with the revision number that preceded the failure reinstates that template and starts a rollout, bringing the application back without manual manifest edits or loss of history.

Exam trap

The trap here is assuming that restarting a Deployment reverts its configuration, when a restart simply recreates pods from the same current, still-failing template.

213
MCQhard

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

A.oc exec -n openshift-monitoring prometheus-k8s-0 -c prometheus -- df -h
B.oc debug node/<node-name> -- df -h
C.oc logs -n openshift-monitoring deployment/prometheus-adapter
D.oc adm top volume
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

214
MCQmedium

An administrator wants to verify if the OpenShift cluster upgrade to version 4.14 has successfully completed for all core components. Which status field in the ClusterVersion resource should show 'True' for the progressing and available conditions?

A.Completed=True and Ready=True
B.Available=True and Progressing=False
C.Available=False and Progressing=True
D.Upgraded=True and Finished=True
AnswerB

ClusterVersion reports conditions as a status array. Available=True confirms all core components are healthy and serving, while Progressing=False confirms no upgrade work remains in flight. Together these two conditions verify the 4.14 upgrade finished across the cluster.

Why this answer

The ClusterVersion resource exposes two key conditions: Available and Progressing. When an upgrade finishes successfully, the cluster reports Available=True (the cluster is healthy and all components are operational) and Progressing=False (no upgrade or configuration change is currently in flight). This combination is the canonical signal that the OpenShift 4.14 upgrade has completed for all core components.

Exam trap

EX280 often tests whether candidates confuse the ClusterVersion condition names with intuitive-but-fake fields like Completed, Ready, Upgraded, or Finished, so the trap is picking a plausible-sounding pair instead of the actual Available/Progressing conditions.

How to eliminate wrong answers

Option A is wrong because Completed and Ready are not conditions exposed by the ClusterVersion resource — the actual condition names are Available, Progressing, Failing, and Retrieved, so these fields do not exist to query. Option C is wrong because Available=False and Progressing=True describes an upgrade still in progress (or a degraded cluster mid-update), which is the opposite of a successful completion. Option D is wrong because Upgraded and Finished are not valid ClusterVersion condition types; they are invented names that do not appear in the ClusterVersion status schema.

215
MCQhard

An OpenShift cluster integrates with an LDAP server where user attribute names differ from default settings (e.g., mail instead of preferredUsername). Where are these LDAP attribute mappings configured?

A.In the kube-apiserver ConfigMap under LDAP settings
B.In the GroupSync CRD resource settings
C.In the LDAP identity provider specification under the 'attributes' mapping fields
D.In the project request template annotations
AnswerC

LDAP attribute mappings belong in the identity provider's `attributes` section, where `id`, `preferredUsername`, `name` and `email` each map to a specific LDAP attribute. Defining `preferredUsername: mail` satisfies the stem's non-default naming constraint, since OpenShift reads these mappings directly from the OAuth identity provider configuration.

Why this answer

LDAP attribute mappings are configured in the LDAP identity provider specification under the `attributes` field. This section maps LDAP attributes (e.g., mail, uid) to OpenShift identity attributes like preferredUsername, name, and email. Administrators edit the OAuth custom resource to set these mappings.

Exam trap

EX280 often tests the location of LDAP attribute mappings, causing candidates to confuse it with GroupSync or kube-apiserver configuration.

How to eliminate wrong answers

Option A is wrong because the kube-apiserver ConfigMap does not contain LDAP settings; LDAP is configured in the OAuth server configuration. Option B is wrong because GroupSync CRD is for synchronizing groups, not for mapping user attributes. Option D is wrong because project request template annotations are for project metadata, not identity provider attribute mapping.

216
Multi-Selectmedium

Which TWO of the following statements regarding OpenShift Projects and Namespaces are correct? (Choose TWO)

Select 2 answers
A.A single namespace can contain multiple distinct OpenShift projects.
B.Namespaces created via 'oc create namespace' automatically instantiate project request templates.
C.Every Project in OpenShift has a corresponding underlying Kubernetes Namespace.
D.Projects can be nested hierarchically within other projects.
E.A Project is a Kubernetes Namespace with additional OpenShift annotations and management capabilities.
AnswersC, E

OpenShift Projects are a wrapper around Kubernetes Namespaces, so each Project always maps one-to-one to an underlying Namespace. This satisfies the stem's requirement for a correct statement: the Project adds annotations, RBAC and quota management on top, but the Namespace itself remains the actual cluster-scoped resource.

Why this answer

Option C is correct because OpenShift Projects are implemented as an abstraction layer over Kubernetes Namespaces: every Project object has a 1:1 relationship with an underlying Namespace of the same name, which is where the actual workloads and resources reside. Option E is correct because a Project is essentially a Kubernetes Namespace enriched with OpenShift-specific annotations (such as openshift.io/display-name, openshift.io/requester, and openshift.io/sa.scc.*) plus additional management features like project request templates, self-provisioning, and role bindings. Option A is incorrect because the relationship is one-to-one, not one-to-many: a single Namespace maps to exactly one Project, and a Project cannot span multiple Namespaces.

Option B is incorrect because project request templates are applied when a user creates a Project via 'oc new-project' or the web console's project request flow, not when a Namespace is created directly with 'oc create namespace', which bypasses the ProjectRequest API. Option D is incorrect because Projects and Namespaces are flat, non-hierarchical constructs; OpenShift does not support nesting Projects within other Projects.

Exam trap

EX280 often tests the misconception that `oc create namespace` and `oc new-project` are interchangeable — they are not, because only the latter invokes the project request template and OpenShift-specific annotations.

217
Multi-Selecthard

Which THREE things can you configure in a BuildConfig?

Select 3 answers
A.Build Strategy
B.Source Code Reference
C.Replicas
D.Triggers
E.Route settings
AnswersA, B, D

Build strategy is a core BuildConfig field, letting you select Source, Docker, or Custom strategies to control how the build executes. This directly satisfies the question's requirement for configurable BuildConfig elements, alongside triggers and output. Each strategy defines distinct build behaviour, so specifying it is essential when defining how OpenShift builds your application image.

Why this answer

In OpenShift, a BuildConfig defines how a build is performed, and its spec includes the build strategy (for example Source, Docker, or Custom), so option A 'Build Strategy' is correct. It also includes the source configuration (spec.source), which specifies the Source Code Reference such as a Git repository URL and ref or a binary/context directory, making option B correct. Additionally, a BuildConfig can define triggers (spec.triggers) like ImageChange, ConfigChange, GitHub/GitLab webhooks, or generic webhooks to automatically start builds, so option D is correct.

Option C 'Replicas' is not part of a BuildConfig; replica counts belong to workload controllers such as DeploymentConfigs or Deployments. Option E 'Route settings' is also not part of a BuildConfig; routes are configured via Route resources to expose services externally.

Exam trap

EX280 often tests the misconception that BuildConfigs manage runtime concerns like replicas or routes, when in fact they only govern image construction — runtime scaling and exposure are separate resources.

218
MCQhard

A security team wants to ensure that all pods in a new namespace called secure-apps run with a specific SELinux context level. They create a custom SCC named selinux-scc with seLinuxContext: MustRunAs and a specific level. After binding the SCC to the default service account in secure-apps, pods still fail to start with an SELinux relabeling error. What is the most likely cause?

A.The node's SELinux policy does not include the specified level, so the container runtime cannot apply the context.
B.The seLinuxContext field in the SCC must be set to RunAsAny to allow pods to start without specifying seLinuxOptions.
C.The pod's securityContext does not specify the required seLinuxOptions, so the SCC's MustRunAs strategy rejects the pod.
D.The SCC was not bound to the correct service account; it must be bound to the default service account in the openshift-infra namespace.
AnswerC

When seLinuxContext uses MustRunAs, the pod must explicitly request an SELinux context that falls within the allowed range. If the pod spec omits seLinuxOptions, the admission controller cannot verify compliance and rejects the pod. The pod template must include seLinuxOptions with the appropriate level, matching the SCC's allowed range.

Why this answer

With seLinuxContext set to MustRunAs, the pod must include seLinuxOptions in its securityContext that match the allowed SELinux context. Omitting these options causes the admission controller to reject the pod. The solution is to add the correct seLinuxOptions to the pod template, ensuring it aligns with the SCC's allowed range.

Exam trap

The trap here is assuming that the SCC alone will enforce the SELinux context without the pod explicitly requesting it, when MustRunAs requires the pod to specify matching options.

219
MCQmedium

An administrator notices that pods on different worker nodes cannot communicate with each other. Upon checking the cluster network operator, it appears the MTU settings between the underlying physical network and the cluster overlay network mismatch. Which OpenShift command checks the cluster network operator status?

A.oc get cni cluster
B.oc describe networkconfig
C.oc get nodes --show-mtu
D.oc get clusteroperator network
AnswerD

The Cluster Network Operator reports overlay health, including MTU mismatches between the physical underlay and the cluster network. Querying the network ClusterOperator object surfaces its status conditions, letting the administrator confirm the operator's degraded state before adjusting the MTU.

Why this answer

The Cluster Network Operator (CNO) status is exposed as a clusteroperator resource named 'network'. Running 'oc get clusteroperator network' shows the operator's availability, progress, and any degraded conditions, which is the standard way to check network operator health. This command directly queries the operator's status.

Exam trap

EX280 often tests the correct resource name for the network operator ('clusteroperator network') versus fictitious resources like 'cni cluster' or 'networkconfig', so candidates must know the exact oc command syntax.

How to eliminate wrong answers

Option A is wrong because 'oc get cni cluster' is not a valid resource/command combination in OpenShift. Option B is wrong because 'oc describe networkconfig' is not a valid resource; the correct resource is 'network.config.openshift.io'. Option C is wrong because 'oc get nodes --show-mtu' is not a real flag; MTU is not displayed via that option.

220
MCQhard

You are configuring an OAuth identity provider using 'htpasswd'. Which secret must contain the file?

A.A secret in 'openshift-config'
B.A ConfigMap in 'openshift-config'
C.A local file on the master node
D.A secret in 'openshift-authentication'
AnswerA

The `htpasswd` identity provider reads its credential file from a Secret in the `openshift-config` namespace, referenced by the OAuth custom resource's `spec.htpasswd.fileData.name` field. Placing it there satisfies OpenShift's requirement that identity provider secrets reside in that dedicated namespace, not the cluster or application namespaces.

Why this answer

When configuring an OAuth identity provider using htpasswd in OpenShift, the htpasswd file must be stored in a Secret in the 'openshift-config' namespace. The OAuth configuration references this secret by name, and the OpenShift authentication operator mounts it into the OAuth pods. This is the documented and required location for identity provider secrets.

Exam trap

EX280 often tests the misconception that identity provider files can be stored in ConfigMaps or in the 'openshift-authentication' namespace, when the correct location is a Secret in 'openshift-config'.

How to eliminate wrong answers

Option B is wrong because a ConfigMap is used for non-sensitive configuration data, and the htpasswd file contains password hashes that must be stored securely in a Secret. Option C is wrong because OpenShift is a containerized platform; storing the file locally on a master node is not how the OAuth operator consumes identity provider data and would not survive upgrades or be replicated. Option D is wrong because the 'openshift-authentication' namespace hosts the OAuth server pods, but the secret must be created in 'openshift-config' where the OAuth custom resource resides; the operator then projects it into the authentication namespace.

221
MCQhard

An administrator needs to configure a BuildConfig so that whenever a new image is pushed to a dependent ImageStream tag, a new build is automatically triggered. Which trigger type must be added to the BuildConfig?

A.Webhook
B.Periodic
C.ImageChange
D.ConfigChange
AnswerC

An ImageChange trigger watches a referenced ImageStreamTag and starts a build automatically when a new image lands on that tag. This satisfies the requirement that pushing an image to a dependent tag triggers the build without manual intervention.

Why this answer

The ImageChange trigger is specifically designed to watch an ImageStreamTag and automatically start a new BuildConfig run whenever the referenced image stream tag is updated (e.g., a new image is pushed). This is the standard mechanism for chaining builds or rebuilding an application when its base/builder image changes. It is configured under spec.triggers with type: ImageChange and an imageChange.imageStreamTag reference.

Exam trap

EX280 often tests the distinction between trigger types by describing an event (image push, code commit, schedule, config edit) and expecting you to map it to the correct trigger — candidates frequently confuse Webhook with ImageChange.

How to eliminate wrong answers

Option A is wrong because a Webhook trigger only fires when an external system calls the BuildConfig's webhook URL (GitHub/GitLab/generic) — it does not monitor image pushes. Option B is wrong because a Periodic trigger runs the build on a cron schedule, not in response to image events. Option D is wrong because a ConfigChange trigger only fires when the BuildConfig's own spec changes at creation/update time, not when a dependent image is pushed.

222
Multi-Selectmedium

An administrator wants to modify the default kubelet parameters (such as maximum pods per core or eviction hard thresholds) across worker nodes. Which TWO steps or resources are involved in this process? (Choose TWO)

Select 2 answers
A.Create a KubeletConfig custom resource defining the desired kubelet parameters.
B.Directly edit the kubelet.conf file on every node via SSH.
C.Restart the kubelet service manually on all nodes using systemctl.
D.Modify the ClusterVersion spec to include kubelet flags.
E.Configure the machineConfigPoolSelector in the KubeletConfig to target the worker pool.
AnswersA, E

A KubeletConfig custom resource holds the kubelet settings, such as maxPods and evictionHard, that the Machine Config Operator rolls out. Creating it satisfies the requirement to define the desired kubelet parameters declaratively rather than editing node files directly.

Why this answer

In OpenShift, kubelet parameters are customized by creating a KubeletConfig custom resource (option A), which is the supported API object for specifying values such as maxPods, podsPerCore, and evictionHard thresholds. To apply that KubeletConfig only to worker nodes, you must set the machineConfigPoolSelector field (option E) so the Machine Config Operator generates the corresponding MachineConfig and rolls it out to the targeted pool. Option B is wrong because directly editing kubelet.conf via SSH bypasses the Machine Config Operator and would be overwritten on the next rendered config sync.

Option C is wrong because the MCO handles kubelet restarts automatically during the config rollout; manual systemctl restarts are neither required nor supported. Option D is wrong because ClusterVersion is used for cluster version and update channel management, not for kubelet flags.

Exam trap

EX280 often tests the misconception that manual node access is required for kubelet changes, when the MCO automates it via KubeletConfig and MachineConfigPoolSelector.

223
MCQmedium

An administrator is diagnosing an application pod that repeatedly restarts. The pod's container shows a Completed exit with code 0 in its last termination state, yet Kubernetes restarts it anyway. The Deployment specifies 'restartPolicy: Always'. What is the correct interpretation?

A.Exit code 0 with restartPolicy Always means the container finished its work; the administrator should switch the workload to a Job.
B.The restart count is a cosmetic counter that resets on each node reboot and can be ignored if the pod is Ready.
C.Exit code 0 indicates a successful shutdown, so Kubernetes should not restart it; the observed restarts must come from a liveness probe failure.
D.The container is being OOMKilled; exit code 0 is the kubelet's translation of an out-of-memory termination.
AnswerA

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

Why this answer

restartPolicy Always instructs the kubelet to restart a container whenever it exits, regardless of exit code. A container that completes successfully with code 0 inside such a pod will be restarted forever, producing a rising restart count and a misleadingly healthy status. The workload type, not the exit code, determines whether this is expected.

Exam trap

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

224
Multi-Selectmedium

Which THREE actions can be performed using the IngressController custom resource? (Choose THREE)

Select 3 answers
A.Modifying the core Kubernetes API server port.
B.Defining the container security context constraints for worker nodes.
C.Scaling the number of router replicas.
D.Setting the endpoint publishing strategy (e.g., LoadBalancer, HostNetwork).
E.Configuring a default wildcard TLS certificate for routes.
AnswersC, D, E

The IngressController custom resource includes a `replicas` field that directly controls how many router pods the OpenShift ingress operator deploys, satisfying the requirement to scale router capacity. Setting this value triggers the operator to reconcile the deployment, adjusting replica count without manual intervention.

Why this answer

Option C is correct because the IngressController custom resource includes a replicas field that controls the number of router pods deployed by the OpenShift ingress operator, allowing administrators to scale router replicas declaratively. Option D is correct because the IngressController CR exposes the endpointPublishingStrategy field, which lets you choose how the router is exposed, such as LoadBalancerService, HostNetwork, NodePortService, or Private. Option E is correct because the IngressController CR supports the defaultCertificate field, which references a TLS secret used as the wildcard certificate for routes that do not specify their own certificate.

Option A is not correct because the core Kubernetes API server port is configured on the kube-apiserver static pod or API server arguments, not through the IngressController CR. Option B is not correct because security context constraints for worker nodes are managed via SCC objects and node configuration, not through the IngressController custom resource.

Exam trap

EX280 often tests whether candidates attribute unrelated cluster settings (API server port, node SCCs) to the IngressController CR, so pick only the router-scaling, publishing-strategy, and default-certificate options.

225
MCQeasy

An administrator wants to view the last 50 lines of logs for a pod named 'api-server-xyz' and keep the stream open for new log entries. Which command should they use?

A.oc logs api-server-xyz --tail=50 -f
B.oc describe pod api-server-xyz --lines=50
C.oc logs api-server-xyz --lines=50 --follow
D.oc tail api-server-xyz -n 50
AnswerA

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

Why this answer

'oc logs api-server-xyz --tail=50 -f' retrieves the last 50 lines and then follows the stream, printing new entries as they arrive. The --tail flag limits historical output, and -f (short for --follow) keeps the connection open. This is the standard pattern for live-tailing pod logs in OpenShift.

Exam trap

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

How to eliminate wrong answers

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

Page 2

Page 3 of 6

Page 4

All pages