Red Hat Certified OpenShift Administrator (EX280, OpenShift Container Platform 4.14+) (EX280) EX280 Questions 376–414 | Page 6/6

376

Multi-Selecthard

A cluster operator is reviewing the volume snapshot implementation in an OpenShift 4.14 environment. Which THREE components or resources are required to successfully perform and manage volume snapshots? (Choose THREE)

Select 3 answers

A.A CSI driver that implements snapshot/restore GRPC services

B.VolumeSnapshotClass

C.A default ClusterRoleBinding for system:authenticated users

D.VolumeSnapshot object

E.NetworkPolicy resources restricting snapshot traffic

AnswersA, B, D

The CSI driver must implement the snapshot and restore gRPC services, since the external-snapshotter controller delegates all CreateSnapshot, DeleteSnapshot and restore operations to these CSI RPCs. Without them, no VolumeSnapshotContent can be provisioned or restored.

Why this answer

Option A is correct because volume snapshots in OpenShift depend on a CSI driver that implements the snapshot/restore gRPC services (the external-snapshotter sidecar and CSI snapshotter capability), which actually creates and restores the snapshots on the storage backend. Option B is correct because a VolumeSnapshotClass defines the CSI driver and deletion policy used when provisioning a VolumeSnapshot, and it must exist for the snapshot to be dynamically created. Option D is correct because the VolumeSnapshot object is the user-facing resource that requests the snapshot and tracks its status and restore point.

Option C is not required, since snapshot operations are governed by RBAC on the snapshot resources rather than a default ClusterRoleBinding for system:authenticated users. Option E is not required, as NetworkPolicy controls pod network traffic and is unrelated to provisioning or managing volume snapshots.

Exam trap

EX280 often tests the specific CRDs and driver capabilities required for snapshots — candidates add unrelated resources like NetworkPolicy or ClusterRoleBindings that are not part of the snapshot architecture.

Full explanation →

377

MCQmedium

A stateful application needs its PersistentVolume to be bound only after the pod requesting it is assigned to a specific worker node, to avoid topology mismatch issues. Which StorageClass parameter achieves this?

A.allowVolumeExpansion: true

B.volumeBindingMode: Immediate

C.bindingMode: Late

D.volumeBindingMode: WaitForFirstConsumer

AnswerD

volumeBindingMode: WaitForFirstConsumer delays PersistentVolume binding until a pod using the claim is scheduled, letting the provisioner create storage in the node's topology zone. This satisfies the requirement that binding occur only after node assignment, avoiding cross-zone mismatch.

Why this answer

The volumeBindingMode: WaitForFirstConsumer parameter in a StorageClass delays volume binding until a pod using the PVC is scheduled. This ensures that the PersistentVolume is provisioned in the same topology zone as the node where the pod runs, preventing topology mismatch. It is the correct setting for stateful applications that require node-local or zone-specific storage.

Exam trap

EX280 often tests whether candidates know the exact StorageClass parameter name and values, so the trap is selecting 'bindingMode: Late' (a non-existent field) or 'Immediate' (which causes the topology problem) instead of the correct 'volumeBindingMode: WaitForFirstConsumer'.

How to eliminate wrong answers

Option A (allowVolumeExpansion: true) is wrong because this parameter only enables resizing of PVCs after creation; it has no effect on when or where volumes are bound. Option B (volumeBindingMode: Immediate) is wrong because Immediate binding provisions and binds the volume as soon as the PVC is created, without waiting for a pod, which can lead to topology mismatch if the volume is provisioned in a different zone than the pod. Option C (bindingMode: Late) is wrong because 'bindingMode' is not a valid StorageClass parameter; the correct field is 'volumeBindingMode' with values 'Immediate' or 'WaitForFirstConsumer'.

Full explanation →

378

MCQhard

An administrator configured an LDAP identity provider in OpenShift, but users report authentication failures. Upon checking the cluster logs, you find errors indicating that the bind DN password secret is missing or incorrect. Where must this bind password be stored?

A.In the 'openshift-config' namespace as a Secret referenced by the OAuth configuration

B.On each worker node at '/etc/origin/master/ldap.pass'

C.As an environment variable on the oauth-openshift deployment

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

AnswerA

The LDAP bind password must live in a Secret within the openshift-config namespace and be referenced by name in the OAuth configuration's identity provider stanza. The authentication operator reads only that namespace, so a missing or misplaced Secret produces the bind DN errors observed.

Why this answer

When configuring an LDAP identity provider in OpenShift, the bind DN password must be stored as a Secret in the 'openshift-config' namespace and referenced in the OAuth configuration. This is the required location for sensitive credentials used by the OAuth server to authenticate against LDAP.

Exam trap

EX280 often tests the location of the LDAP bind password Secret; candidates may incorrectly choose a ConfigMap or a different namespace, confusing sensitive and non-sensitive configuration storage.

How to eliminate wrong answers

Option B is wrong because storing the password on worker nodes is insecure and not how OpenShift manages identity provider credentials. Option C is wrong because environment variables on the oauth-openshift deployment are not used for LDAP bind passwords; the OAuth configuration references a Secret. Option D is wrong because ConfigMaps are for non-sensitive configuration data, not secrets, and the 'openshift-authentication' namespace is not where the bind password Secret is stored.

Full explanation →

379

MCQeasy

An administrator needs to create a Route that handles multiple subdomains or redirects insecure HTTP traffic to HTTPS automatically. Where is the insecure traffic redirect configured?

A.route.openshift.io/handling: insecure-redirect

B.tls.allowInsecure: true

C.insecureEdgeTerminationPolicy: Redirect

D.spec.redirectHTTP: enabled

AnswerC

Setting insecureEdgeTerminationPolicy to Redirect makes the OpenShift router answer plain HTTP on the route's host with a 301 to the HTTPS URL. This satisfies the automatic redirect requirement without a separate route or frontend configuration.

Why this answer

In OpenShift, a Route's TLS configuration includes the `insecureEdgeTerminationPolicy` field, which controls how non-TLS (HTTP) traffic is handled when the Route is configured for edge or re-encrypt termination. Setting it to `Redirect` makes the router automatically issue an HTTP 302 redirect to the HTTPS URL, ensuring all insecure traffic is upgraded. This is the standard, supported mechanism for enforcing HTTPS on a Route.

Exam trap

EX280 often tests the exact field name and location for redirecting insecure traffic, and candidates may confuse it with non-existent annotations or assume a boolean flag like `allowInsecure` exists.

How to eliminate wrong answers

Option A is wrong because `route.openshift.io/handling` is not a valid annotation or field in OpenShift; there is no such handling directive. Option B is wrong because `tls.allowInsecure` is not a valid field in a Route spec; while `insecureEdgeTerminationPolicy` can be set to `Allow` to permit HTTP, there is no boolean `allowInsecure` property. Option D is wrong because `spec.redirectHTTP` does not exist in the Route API; redirection is controlled exclusively via `insecureEdgeTerminationPolicy`.

Full explanation →

380

MCQmedium

An administrator needs to set a default StorageClass for the entire OpenShift cluster so that PVCs without a storageClassName specified automatically use it. How is this configured?

A.By modifying the kube-controller-manager operator configuration.

B.By adding the annotation storageclass.kubernetes.io/is-default-class: "true" to the StorageClass object.

C.By naming the StorageClass 'default-sc' exactly.

D.By setting defaultStorageClass: true in the cluster-config ConfigMap.

AnswerB

Annotating the StorageClass with `storageclass.kubernetes.io/is-default-class: "true"` satisfies the cluster-wide default requirement: the admission controller then assigns this class to any PVC omitting `storageClassName`. This is the sole supported mechanism for designating a default StorageClass, applying cluster-wide rather than per-namespace.

Why this answer

In Kubernetes and OpenShift, a StorageClass is marked as the cluster default by adding the annotation storageclass.kubernetes.io/is-default-class: "true" to its metadata. The PersistentVolumeClaim admission controller then automatically assigns that class to any PVC that omits storageClassName.

Exam trap

EX280 often tests the annotation-based defaulting mechanism — candidates incorrectly assume a StorageClass named 'default' or a ConfigMap setting controls defaulting.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager operator configuration controls controller behavior, not StorageClass defaulting; there is no field there for default storage class selection. Option C is wrong because the name 'default-sc' has no special meaning — Kubernetes does not infer default status from a StorageClass name. Option D is wrong because there is no cluster-config ConfigMap field called defaultStorageClass; defaulting is annotation-driven, not ConfigMap-driven.

Full explanation →

381

MCQhard

An administrator is troubleshooting a certificate signing request (CSR) that is stuck in the Pending state for a newly added worker node. Which command should they use to approve the pending CSR?

A.oc cluster-version approve-csr <csr-name>

B.oc adm certificate approve <csr-name>

C.oc patch csr <csr-name> --type=json -p='[{"op": "replace", "path": "/status/conditions", "value": "Approved"}]'

D.oc approve csr <csr-name>

AnswerB

The CSR remains Pending until an administrator explicitly approves it; worker node CSRs are not auto-approved by default. The `oc adm certificate approve` subcommand is the cluster-admin action that transitions the request to Approved, allowing the kubelet to receive its signed certificate and join the node.

Why this answer

`oc adm certificate approve <csr-name>` is the documented OpenShift command to approve a pending CSR, which triggers the signer controller to issue the node client certificate. It is the standard administrative action for unblocking node bootstrap. The command is idempotent and safe to re-run.

Exam trap

EX280 often tests whether candidates know the exact syntax `oc adm certificate approve` — the trap is picking a plausible but non-existent `oc approve csr` or a manual JSON patch of the status subresource.

How to eliminate wrong answers

Option A is wrong because `oc cluster-version` is not a valid command — the correct resource is `clusterversion`, and it has no `approve-csr` subcommand. Option C is wrong because directly patching the CSR status conditions bypasses the approval controller and is not the supported workflow; the CSR status is managed by the signer, and manual patches can leave the CSR in an inconsistent state. Option D is wrong because `oc approve` is not a top-level command — approval is under `oc adm certificate approve`.

Full explanation →

382

MCQmedium

An administrator needs to configure a custom default certificate for all routes created in the cluster without specifying a certificate on every individual Route object. Where should this wildcard certificate be configured?

A.In a ConfigMap named 'router-certs' in the default namespace

B.In the IngressController resource named 'default' in openshift-ingress-operator

C.In the apiserver.config.openshift.io cluster object

D.In the DNS cluster operator configuration

AnswerB

The default IngressController in openshift-ingress-operator accepts a defaultCertificate field, which the ingress operator applies to every router-generated Route lacking its own certificate. Configuring it there satisfies the stem's constraint of a cluster-wide wildcard without editing individual Route objects.

Why this answer

The wildcard default certificate for all routes is configured in the IngressController resource named 'default' in the `openshift-ingress-operator` namespace, specifically in `spec.defaultCertificate` with a Secret reference. This tells the OpenShift ingress operator to use that certificate as the fallback for any Route that does not specify its own TLS certificate. It is the cluster-wide default for edge/re-encrypt routes.

Exam trap

EX280 often tests the difference between the IngressController resource (declarative, operator-managed) and the legacy router-certs secret — candidates pick the old secret location or confuse it with the apiserver config object.

How to eliminate wrong answers

Option A is wrong because although the router historically used a `router-certs` secret in the `openshift-ingress` namespace, manually editing it is not the supported declarative method and it is not in the `default` namespace — the operator manages this. Option C is wrong because the `apiserver.config.openshift.io` cluster object configures the API server's serving certificate and named certificates, not ingress route certificates. Option D is wrong because the DNS cluster operator manages cluster DNS records and forwarding, not TLS certificates for routes.

Full explanation →

383

Multi-Selectmedium

Which TWO actions are required when configuring an external OpenID Connect (OIDC) identity provider in OpenShift Container Platform?

Select 2 answers

A.Reference a Secret containing the clientSecret used to authenticate against the OIDC provider.

B.Create a dedicated OAuthClient resource for every single cluster user.

C.Deploy an internal LDAP directory synchronization cronjob inside the openshift-authentication namespace.

D.Provide the issuer URL pointing to the OIDC provider's discovery endpoint.

E.Generate a self-signed CA certificate for the API server using openshift-install.

AnswersA, D

The client secret authenticates OpenShift to the OpenID Connect provider during the authorisation code exchange, so it must be supplied via a Secret. It satisfies the stem's requirement by providing the credential the identity provider expects.

Why this answer

When configuring an external OIDC identity provider in OpenShift Container Platform, the OAuth configuration (a custom resource of kind OAuth) requires an identityProvider entry of type OpenIDConnect that references a Secret holding the clientSecret used to authenticate the cluster's OAuth server against the OIDC provider, so option A is correct. The same identityProvider stanza must also specify the issuer URL, which points to the OIDC provider's discovery endpoint (/.well-known/openid-configuration) so OpenShift can retrieve the provider's metadata such as authorization and token endpoints, making option D correct. Option B is wrong because OAuthClient resources represent OAuth clients that consume the cluster's OAuth server (for example, service accounts or external applications), not individual cluster users, and they are not created per user for an external IdP.

Option C is wrong because LDAP synchronization is only relevant to the LDAP identity provider and is not part of OIDC configuration. Option E is wrong because openshift-install is used for cluster installation and does not generate a self-signed CA for the API server as part of configuring an external OIDC identity provider.

Exam trap

EX280 often tests identity provider configuration details — candidates confuse OIDC with LDAP (picking directory sync) or assume per-user OAuthClients, missing that OIDC uses a single client with issuer URL and client secret.

Full explanation →

384

MCQhard

The OpenShift SDN (or OVN-Kubernetes) network plugin reports a failure. The administrator needs to inspect the iptables rules on a worker node to verify packet mangling and NAT configurations. How can they view the host's iptables rules?

A.oc logs daemonset/iptables-analyzer

B.oc adm diagnostics iptables

C.oc debug node/<node-name> -- chroot /host iptables-save

D.oc exec deployment/router-default -- iptables -L

AnswerC

Host iptables rules live in the node's network namespace, not the container's. `oc debug node/<node-name>` starts a privileged pod on that node, and `chroot /host` enters the host root filesystem so `iptables-save` reads the actual host NAT and mangling rules.

Why this answer

The `oc debug node/<node-name>` command creates a privileged debug pod that runs on the target node and mounts the host's root filesystem at /host. Using `chroot /host` switches the process root into the host's filesystem, allowing the administrator to run the host's own `iptables-save` binary against the host's netfilter tables. This is the only option that actually inspects the node's kernel-level iptables rules rather than pod-level or non-existent resources.

Exam trap

EX280 often tests whether candidates know that node-level inspection requires `oc debug node/<name>` plus `chroot /host`, not `oc exec` into a workload pod — the trap is picking a pod-scoped command that shows the wrong network namespace.

How to eliminate wrong answers

Option A is wrong because there is no DaemonSet named 'iptables-analyzer' in OpenShift, and even if one existed, `oc logs` would only show container stdout, not iptables rules. Option B is wrong because `oc adm diagnostics` does not have an 'iptables' subcommand — it runs predefined cluster health checks, not arbitrary host commands. Option D is wrong because the router-default deployment runs in a pod with its own network namespace, so `iptables -L` there shows only the pod's rules, not the host's NAT/mangle tables used by the SDN plugin.

Full explanation →

385

Multi-Selecthard

Which THREE items are required to successfully deploy a basic application using S2I?

Select 3 answers

A.BuildConfig

B.External Load Balancer

C.A pre-existing Database

D.Builder Image

E.Source Code

AnswersA, D, E

A BuildConfig defines the build strategy, source reference and output image stream, triggering and orchestrating the S2I assembly. It is one of the three required items, since without it no build is instantiated from the source and builder image.

Why this answer

Option A (BuildConfig) is required because S2I builds are driven by an OpenShift BuildConfig that defines the source, strategy (Source-to-Image), and output image stream for the application. Option D (Builder Image) is required because the S2I build strategy needs an S2I-enabled builder image (e.g., a builder image stream such as nodejs or python) that contains the assemble and run scripts to compile and package the source. Option E (Source Code) is required because S2I takes application source (from a Git repository, binary, or local directory) as the input that the builder image's assemble script transforms into a runnable image.

Option B (External Load Balancer) is not required for a basic S2I deployment, since OpenShift Routes or Services handle exposure internally. Option C (A pre-existing Database) is not required, as a basic application deployment does not depend on an external database being present.

Exam trap

EX280 often tests whether candidates confuse optional components like databases or load balancers with the essential building blocks of an S2I build, leading them to select unnecessary items.

Full explanation →

386

MCQmedium

A cluster administrator notices that a PVC stuck in the Pending state references a StorageClass with volumeBindingMode set to WaitForFirstConsumer. What action will cause the PVC to bind?

A.Delete the StorageClass and recreate it with Immediate binding mode.

B.Restart the kube-apiserver service on the control plane nodes.

C.Create and schedule a Pod that mounts the PVC.

D.Manually create a PV matching the exact size and labels of the PVC.

AnswerC

With WaitForFirstConsumer, the volume binding decision is deferred until a Pod using the PVC is scheduled, letting the scheduler pick a node and then provision storage in that node's topology zone. Creating and scheduling a Pod that mounts the PVC triggers this provisioning, satisfying the delayed-binding constraint and moving the PVC from Pending to Bound.

Why this answer

With volumeBindingMode: WaitForFirstConsumer, the storage provisioner delays binding until a pod using the PVC is scheduled, allowing the scheduler to pick a node and then provision storage in the correct topology zone. Creating and scheduling a pod that mounts the PVC triggers the provisioning and binding process. Until such a pod exists, the PVC remains Pending by design.

Exam trap

EX280 often tests whether candidates recognize that a Pending PVC with WaitForFirstConsumer is normal behavior, not a failure — the trap is assuming Pending always means a problem requiring intervention.

How to eliminate wrong answers

Option A is wrong because changing to Immediate binding mode alters cluster storage behavior and is unnecessary — WaitForFirstConsumer is intentional for topology-aware provisioning, and the PVC will bind once a consumer pod is created. Option B is wrong because restarting the kube-apiserver has no effect on volume binding, which is handled by the scheduler and the CSI provisioner, not the API server. Option D is wrong because manually creating a PV bypasses the dynamic provisioner and is not the intended mechanism; WaitForFirstConsumer expects the provisioner to create the PV after scheduling, and a manually created PV may not match topology constraints.

Full explanation →

387

Multi-Selecthard

Which TWO of the following characteristics apply to OpenShift SecurityContextConstraints (SCCs)? (Choose TWO)

Select 2 answers

A.SCCs replace Kubernetes NetworkPolicies entirely.

B.SCCs evaluate and can mutate pod specifications during admission control.

C.SCCs can be created as namespaced resources using standard RoleBindings.

D.SCCs are cluster-scoped resources.

E.SCCs apply only to stateful workloads and daemonsets.

AnswersB, D

SCCs act at admission control, validating a pod's security context against allowed values and mutating the pod spec to apply defaults such as SELinux labels or runAsUser when fields are unset. This admission-time evaluation distinguishes them from purely declarative policy objects.

Why this answer

Option B is correct because SCCs are enforced by the OpenShift admission controller: when a pod is created, the SCC admission plugin evaluates the pod's security context (runAsUser, SELinux context, capabilities, volumes, etc.) against the SCCs available to the requesting service account, and can mutate the pod specification to apply defaults such as allowed UID ranges or SELinux labels. Option D is correct because SecurityContextConstraints are cluster-scoped API resources (like ClusterRoles), defined once for the whole cluster rather than within a namespace, and are bound to users, groups, or service accounts via cluster-scoped RBAC (ClusterRole/ClusterRoleBinding or the scc-specific user/group fields). Option A is wrong because SCCs govern pod security context and admission, not network traffic; NetworkPolicies are a separate Kubernetes mechanism and SCCs do not replace them.

Option C is wrong because SCCs are not namespaced resources and cannot be granted through ordinary namespaced RoleBindings; access is granted via cluster-scoped bindings or the SCC's users/groups fields. Option E is wrong because SCCs apply to all pods regardless of workload type, including Deployments, Jobs, and standalone pods, not only stateful workloads or DaemonSets.

Exam trap

EX280 often tests the misconception that SCCs are namespaced or that they replace NetworkPolicies — candidates must remember SCCs are cluster-scoped admission controllers focused on pod security context, not network traffic.

Full explanation →

388

MCQmedium

An application pod is running, but HTTP requests to the service are returning '502 Bad Gateway'. The administrator wants to check if the endpoints controller has populated the Service with active pod IP addresses. Which command verifies this?

A.oc get svc my-service

B.oc get endpoints my-service

C.oc describe ingress

D.oc get routes my-route

AnswerB

Endpoints objects hold the ready pod IPs and ports backing a Service, populated by the endpoints controller. Reading them confirms whether selector matching succeeded, distinguishing a 502 caused by empty endpoints from one caused by ingress or application faults.

Why this answer

The Endpoints object is what the endpoints controller populates with the IP addresses and ports of pods that match a Service's selector. Running 'oc get endpoints my-service' shows whether the Service has active backend pod IPs; if the endpoints list is empty, the Service selector does not match any ready pods, which is a common cause of 502 errors from the router.

Exam trap

EX280 often tests whether candidates know that 'oc get svc' shows the Service definition but not the backing pod IPs — the Endpoints object is the authoritative source for verifying selector-to-pod matching.

How to eliminate wrong answers

Option A is wrong because 'oc get svc my-service' shows the Service's ClusterIP, ports, and selector, but not the actual pod IPs backing it — it will not reveal whether endpoints were populated. Option C is wrong because 'oc describe ingress' shows ingress rules, TLS settings, and backend references, but not the live endpoint IPs of the Service. Option D is wrong because 'oc get routes my-route' shows the OpenShift Route hostname and target Service, but not the pod-level endpoints that determine whether traffic can reach a backend.

Full explanation →

389

Multi-Selecthard

An OpenShift cluster operator is stuck in a Progressing state during an update. Which THREE diagnostic steps help determine why the operator reconciliation loop is blocked? (Choose THREE)

Select 3 answers

A.Reboot all control plane nodes simultaneously.

B.Check cluster-wide events related to the operator namespace.

C.Check the logs of the operator deployment in its respective openshift-* namespace.

D.Inspect the status conditions in the operator's Custom Resource (e.g., oc get <cr> -o yaml).

E.Delete all persistent volumes in the cluster.

AnswersB, C, D

Cluster-wide events expose reconciliation failures such as failed API calls, RBAC denials, or resource conflicts affecting the operator's namespace, directly revealing why the loop stalls in Progressing. Filtering events by the operator namespace surfaces the specific blocking condition the stem describes, without requiring deeper pod-level inspection first.

Why this answer

Option B is correct because cluster-wide events (e.g., oc get events -n openshift-<operator>) reveal scheduling failures, image pull errors, RBAC denials, or dependency issues that can stall the operator's reconciliation loop. Option C is correct because the operator deployment's pod logs in its openshift-* namespace show the actual reconciliation errors, failed API calls, or exceptions the controller is hitting while trying to progress. Option D is correct because inspecting the Custom Resource's status conditions (e.g., oc get <cr> -o yaml) exposes the operator's own reported state, including Degraded/Progressing reasons and messages that pinpoint the blocking condition.

Option A is not appropriate because rebooting all control plane nodes simultaneously causes an outage and does not diagnose the reconciliation issue. Option E is not appropriate because deleting persistent volumes destroys data and is unrelated to diagnosing why an operator is stuck Progressing.

Exam trap

EX280 often tests whether candidates choose safe, read-only diagnostic commands (events, logs, CR status) over destructive actions like rebooting nodes or deleting PVs, which are never valid troubleshooting steps.

Full explanation →

390

Multi-Selectmedium

Which THREE statements are true regarding Ingress controllers in OpenShift? (Choose THREE)

Select 3 answers

A.Administrators can create additional custom IngressController instances.

B.They replace the internal Kubernetes kube-proxy component entirely.

C.They are implemented using HAProxy router pods by default.

D.They watch both Route and Ingress resources.

E.They require manual iptables rule updates on every worker node for every new route.

AnswersA, C, D

Administrators may deploy extra IngressController custom resources beyond the default `default` instance, each bound to distinct node selectors, namespaces or endpoint publishing strategies. This satisfies the stem's requirement for true statements, since OpenShift supports multiple concurrent ingress controllers, enabling workload isolation and separate routing domains within one cluster.

Why this answer

Option A is correct because OpenShift administrators can create additional custom IngressController instances (for example, in the openshift-ingress-operator namespace) to provide separate ingress endpoints with their own HAProxy router deployments, scaling, and node placement. Option C is correct because the default OpenShift Ingress controller is implemented by the OpenShift Router, which runs HAProxy in router pods managed by the Ingress Operator. Option D is correct because the OpenShift router watches both Route resources (the OpenShift-native API) and Ingress resources (the standard Kubernetes API), serving both through the same HAProxy-based data path.

Option B is not correct because kube-proxy is a separate Kubernetes component that programs service load balancing on nodes; Ingress controllers handle HTTP/HTTPS routing and do not replace kube-proxy. Option E is not correct because the router dynamically updates its HAProxy configuration as Routes and Ingresses change, so administrators do not manually edit iptables rules on worker nodes for each new route.

Exam trap

EX280 often tests the misconception that Ingress controllers replace kube-proxy or require manual iptables updates, confusing the roles of different networking components.

Full explanation →

391

Multi-Selecteasy

Which TWO files or directories are commonly configured or injected via MachineConfig objects for node customization? (Choose TWO)

Select 2 answers

A.Custom files placed in arbitrary file paths on the node filesystem.

B.Persistent Volume Claims (PVCs) for user applications.

C.Direct modifications to the Kubernetes API server binary code.

D.Authorized SSH keys for the core user.

E.Dynamic container image layer storage caches.

AnswersA, D

MachineConfig objects support injecting custom files at arbitrary paths on the node filesystem via the files section, using base64-encoded contents. This satisfies node customisation by allowing configuration files, scripts, or certificates to be placed anywhere required.

Why this answer

MachineConfig objects in OpenShift are used to apply node-level customizations by injecting Ignition configs, and they commonly include custom files placed at arbitrary paths on the node filesystem (option A) — for example, dropping a config file into /etc or a systemd unit — because MachineConfig supports specifying file contents, path, mode, and ownership. They also commonly configure authorized SSH keys for the core user (option D), which is a standard MachineConfig use case (e.g., the 99-master-ssh and 99-worker-ssh MachineConfigs) to enable SSH access to nodes. Option B is incorrect because PVCs are Kubernetes storage resources for application pods, not node customization injected via MachineConfig.

Option C is incorrect because MachineConfig does not modify the Kubernetes API server binary code; it manages node OS-level configuration through Ignition. Option E is incorrect because container image layer caches are managed by the container runtime and are not a MachineConfig-injected node customization.

Exam trap

EX280 often tests whether candidates confuse node-level MachineConfig customization with workload-level Kubernetes objects like PVCs or runtime-managed artifacts like image caches.

Full explanation →

392

MCQhard

An administrator runs 'oc debug node/worker-1' and gets a shell in the debug pod, but when they try to run 'crictl ps' to list running containers on the node, the command is not found. They confirm the node's kubelet is healthy and workloads are running. What is the correct explanation and fix?

A.crictl has been deprecated in favor of 'oc adm node-logs', so the administrator should use that command for container inspection instead.

B.The debug pod uses a minimal image without crictl; they must add '--image=registry.access.redhat.com/ubi9/ubi' to install it manually.

C.The debug pod must be started with 'chroot /host' executed inside it, because the host binaries are mounted at /host but the shell starts in the container root.

D.The administrator lacks the cluster-admin role, so crictl is hidden by RBAC; granting cluster-admin will make the binary visible.

AnswerC

'oc debug node/<name>' mounts the host root filesystem at /host inside the debug pod but leaves the shell in the container's filesystem, where node binaries such as crictl are absent. Running 'chroot /host' switches the process root to the host filesystem, after which crictl and other node tools resolve. This is the documented workflow for node-level troubleshooting on OpenShift.

Why this answer

'oc debug node' intentionally isolates the administrator: the host filesystem is bind-mounted at /host rather than made the process root, so host-only binaries are not on PATH. Entering the host namespace with 'chroot /host' makes crictl, journalctl, and other node utilities resolvable, which is the supported method for inspecting CRI containers on a node.

Exam trap

The trap here is believing that a debug shell on a node automatically runs in the host's filesystem, when it actually starts in the container root with the host mounted at /host.

Full explanation →

393

MCQhard

An administrator is troubleshooting a failing MachineConfig update in an OpenShift cluster. The MachineConfigPool 'worker' is degraded and reports that a node is failing to apply the rendered-worker configuration. Which log stream is critical for determining why the Machine Config Daemon failed to update system files on the target node?

A.oc describe machineconfigpool worker

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

C.oc logs -n openshift-cluster-version-operator deployment/cluster-version-operator

D.journalctl -u kubelet -e

AnswerB

The Machine Config Daemon runs as a DaemonSet pod on each node, and its container logs record exactly why it failed to write system files during a rendered-worker update. Querying the daemonset in the openshift-machine-config-operator namespace surfaces the per-node error, satisfying the need to diagnose the degraded MachineConfigPool.

Why this answer

The Machine Config Daemon (MCD) runs as a DaemonSet in the openshift-machine-config-operator namespace and is the component that actually applies rendered MachineConfigs to each node — writing files, updating the kubelet config, and rebooting when required. When a node fails to apply a rendered config, the MCD pod on that node logs the precise failure (e.g., file write errors, systemd unit failures, drain failures). Therefore 'oc logs -n openshift-machine-config-operator daemonset/machine-config-daemon' is the critical log stream.

Exam trap

EX280 often tests whether candidates know that 'oc describe machineconfigpool' shows status but not root cause — the actual failure reason lives in the Machine Config Daemon logs, not in the pool description or CVO logs.

How to eliminate wrong answers

Option A is wrong because 'oc describe machineconfigpool worker' only shows status conditions (Degraded, Updating) and node counts — it does not reveal why the MCD failed to write files. Option C is wrong because the Cluster Version Operator logs track cluster version upgrades, not per-node MachineConfig application failures. Option D is wrong because kubelet journal logs show pod lifecycle and container runtime issues, not the MCD's file-application errors during a MachineConfig rollout.

Full explanation →

394

MCQhard

An administrator creates a NetworkPolicy that restricts egress traffic from a namespace. However, DNS resolution for external services immediately stops working. What is the cause of this behavior?

A.NetworkPolicies automatically disable the OpenShift SDN controller.

B.The NetworkPolicy blocks outbound traffic to port 53 on the cluster DNS service.

C.CoreDNS pods do not have valid security context constraints.

D.External DNS servers reject requests originating from OpenShift node IPs.

AnswerB

Egress NetworkPolicies are default-deny once any pod is selected, so only explicitly permitted destinations pass. Cluster DNS listens on port 53, and omitting an egress rule for it silently drops all name resolution traffic from the namespace.

Why this answer

When a NetworkPolicy selects pods for egress, it becomes default-deny for all egress traffic from those pods except what is explicitly allowed. If the policy does not include a rule permitting UDP/TCP port 53 to the cluster DNS service (usually openshift-dns in openshift-dns namespace), DNS resolution fails immediately. The fix is to add an egress rule allowing port 53 to the DNS pods or namespace.

Exam trap

EX280 often tests the default-deny behavior of NetworkPolicies — candidates forget that once a pod is selected for egress, DNS (port 53) is blocked unless explicitly allowed.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies are enforced by the CNI plugin (OVN-Kubernetes or OpenShift SDN) and do not disable the SDN controller — they simply filter traffic. Option C is wrong because CoreDNS pods run with appropriate SCCs by default; SCCs govern pod security, not network reachability, and DNS failures from NetworkPolicies are not SCC-related. Option D is wrong because external DNS servers do not reject OpenShift node IPs — the failure occurs before the packet leaves the cluster, at the NetworkPolicy enforcement point.

Full explanation →

395

MCQhard

An administrator needs to configure resource requests and limits such that any pod created without explicit CPU requests in the 'web-tier' namespace automatically gets assigned a default CPU request of 200m and a default CPU limit of 500m. Which object achieves this?

A.ResourceQuota

B.PodPreset

C.LimitRange with default and defaultRequest parameters

D.ClusterResourceQuota

AnswerC

A LimitRange with default and defaultRequest keys applies admission-time defaults to containers lacking explicit values, so pods in web-tier receive a 200m CPU request and 500m limit automatically. ResourceQuota instead caps aggregate namespace consumption and cannot inject per-container defaults.

Why this answer

A LimitRange object with default and defaultRequest parameters is specifically designed to set default resource requests and limits for containers in a namespace. When a pod is created without explicit CPU requests, the LimitRange's defaultRequest value (200m) is applied as the request, and the default value (500m) is applied as the limit. This ensures consistent resource allocation and prevents pods from being created without any resource constraints.

Exam trap

EX280 often tests the distinction between ResourceQuota and LimitRange, where candidates mistakenly believe ResourceQuota can set default requests/limits, but it only enforces aggregate limits.

How to eliminate wrong answers

Option A is wrong because ResourceQuota enforces aggregate resource consumption limits for a namespace (e.g., total CPU or memory across all pods) but does not set default requests or limits for individual containers. Option B is wrong because PodPreset was an alpha feature that injected additional information into pods at creation time, but it was removed in Kubernetes 1.20 and never provided default resource requests/limits; it also required specific label selectors. Option D is wrong because ClusterResourceQuota is an OpenShift-specific object that manages quota across multiple namespaces based on label selectors, not a mechanism to assign default resource values to pods.

Full explanation →

396

MCQeasy

Which OpenShift 4.14 command allows an administrator to gather cluster-wide diagnostic logs and configuration data for support cases?

A.oc adm must-gather

B.oc adm collect-logs

C.oc support dump

D.oc cluster-debug bundle

AnswerA

oc adm must-gather collects cluster-wide diagnostic logs, resource definitions and configuration from all nodes into a single archive for Red Hat support. Unlike oc logs or oc describe, which target one pod or resource, it satisfies the stem's requirement for comprehensive cluster-wide data.

Why this answer

The command 'oc adm must-gather' collects a comprehensive set of cluster diagnostics, including logs, resource definitions, and configuration data from all relevant components. It is the standard tool for gathering information for Red Hat support cases. It runs a pod on the cluster that collects data and saves it to a local directory.

Exam trap

EX280 often tests the exact command name, and candidates may confuse it with similar-sounding commands from other tools or platforms.

How to eliminate wrong answers

Option B is wrong because 'oc adm collect-logs' is not a valid OpenShift command; the correct command is 'oc adm must-gather'. Option C is wrong because 'oc support dump' does not exist in OpenShift; it might be confused with other platforms. Option D is wrong because 'oc cluster-debug bundle' is not a valid command; OpenShift uses must-gather for debugging bundles.

Full explanation →

397

MCQeasy

A cluster administrator needs to grant a Deployment in the production namespace permission to pull images from a private container registry. The image pull secret is named my-registry-secret. Which step must be performed so that pods created by this Deployment can successfully pull the image?

A.Create a RoleBinding mapping the secret to the cluster-readers cluster role.

B.Annotate the Deployment resource with the full base64-encoded dockerconfigjson payload.

C.Run oc set data secrets/my-registry-secret --namespace=production.

D.Patch the default ServiceAccount in the production namespace to include my-registry-secret in its imagePullSecrets array.

AnswerD

Patching the default ServiceAccount adds my-registry-secret to its imagePullSecrets array, so the kubelet automatically injects those credentials into every pod that omits an explicit serviceAccountName. Since the Deployment's pods use the default ServiceAccount, this satisfies the private registry authentication requirement without editing the pod template.

Why this answer

To allow pods created by a Deployment to pull from a private registry, the imagePullSecrets must be associated with the ServiceAccount used by the pods. By default, pods use the 'default' ServiceAccount in their namespace. Patching that ServiceAccount to include my-registry-secret in its imagePullSecrets array ensures that all pods using that ServiceAccount (including those from the Deployment) can authenticate to the registry.

Exam trap

EX280 often tests whether candidates know that image pull secrets must be linked to a ServiceAccount (or pod spec), so the trap is selecting an RBAC-related answer (RoleBinding) or a secret modification command that does not actually associate the secret with the pods.

How to eliminate wrong answers

Option A is wrong because a RoleBinding grants RBAC permissions to a subject (user, group, or service account) and has no relationship to image pull secrets; mapping a secret to cluster-readers does not enable registry authentication. Option B is wrong because annotating the Deployment with a base64-encoded dockerconfigjson payload is not a supported mechanism for image pull authentication; the correct approach is to reference a Secret of type kubernetes.io/dockerconfigjson via imagePullSecrets. Option C is wrong because 'oc set data secrets/my-registry-secret' modifies the contents of the secret (e.g., adding a key-value pair) but does not associate it with any ServiceAccount or pod, so it does not solve the pull authentication problem.

Full explanation →

398

Multi-Selectmedium

An administrator notices that a node has been automatically cordoned and drained by the cluster. Which THREE places should the administrator inspect to find the reason for the node eviction or failure? (Choose THREE)

Select 3 answers

A.oc get storageclass

B.oc describe node <node-name>

C.Journalctl logs for the kubelet service on the affected node.

D.oc get ingresscontroller

E.oc get events --field-selector reason=Evicted

AnswersB, C, E

Describing the node surfaces the cordoned and drained state plus conditions, taints and recent events recorded against the node object itself. That reveals whether the kubelet reported NotReady, disk or memory pressure, or an eviction taint applied by the node lifecycle controller.

Why this answer

Option B, `oc describe node <node-name>`, is correct because the node's status conditions (such as Ready, MemoryPressure, DiskPressure, PIDPressure) and the associated events/taints like node.kubernetes.io/not-ready or node.kubernetes.io/unreachable reveal why the node was cordoned and drained. Option C, journalctl logs for the kubelet service on the affected node, is correct because the kubelet is the component that reports node status and applies eviction/taints; its logs contain the precise errors (e.g., failed to update node status, container runtime failures, certificate or resource issues) behind the eviction. Option E, `oc get events --field-selector reason=Evicted`, is correct because it filters cluster events specifically for the Evicted reason, showing which pods were evicted, from which node, and the eviction message (e.g., The node was low on resource: memory).

Options A and D are incorrect because `oc get storageclass` and `oc get ingresscontroller` list storage and ingress configuration objects, which are unrelated to node cordon/drain/eviction diagnostics.

Exam trap

EX280 often tests whether candidates know to check node conditions, kubelet logs, and Evicted events — not storage classes or ingress controllers, which are unrelated to node eviction.

Full explanation →

399

MCQhard

A cluster administrator notices that a NetworkPolicy applied to the database namespace is dropping traffic from the frontend namespace. The policy uses namespaceSelector. Which label must be present on the frontend namespace for traffic to be successfully allowed?

A.openshift.io/cluster-monitoring=true

B.security.openshift.io/scc=restricted

C.A custom label defined in the namespaceSelector of the NetworkPolicy spec

D.kubernetes.io/metadata.name matching the namespace name

AnswerC

A namespaceSelector matches namespaces by their labels, so the frontend namespace must carry the exact custom label key and value declared in the policy's namespaceSelector. Without that label, the selector never matches and traffic stays dropped.

Why this answer

In a NetworkPolicy, the `namespaceSelector` matches namespaces based on their labels. For traffic from the `frontend` namespace to be allowed, the `frontend` namespace must have the exact label key-value pair specified in the `namespaceSelector` of the NetworkPolicy. This label is arbitrary and defined by the administrator; it does not have to be a default OpenShift label.

Exam trap

EX280 often tests the difference between automatic labels (like `kubernetes.io/metadata.name`) and custom labels, tricking candidates into choosing a default label instead of the one defined in the policy.

How to eliminate wrong answers

Option A is wrong because `openshift.io/cluster-monitoring=true` is a label used for monitoring, not for NetworkPolicy selection unless explicitly configured. Option B is wrong because `security.openshift.io/scc=restricted` is a label related to Security Context Constraints, not namespace selection for NetworkPolicy. Option D is wrong because `kubernetes.io/metadata.name` is a label automatically added to namespaces (since Kubernetes 1.21) that contains the namespace name, but it is not the label required unless the NetworkPolicy specifically uses it; the question states the policy uses `namespaceSelector`, which requires a custom label defined in the policy.

Full explanation →

400

Multi-Selecteasy

Which TWO methods can administrators use to access the OpenShift 4.14 web console or CLI for cluster management? (Choose TWO)

Select 2 answers

A.Using 'systemctl gui-console' on control plane nodes.

B.Using SSH to log directly into the API server container runtime socket.

C.Using a web browser to access the OpenShift Web Console URL.

D.Using the 'kubectl-adm console' plugin.

E.Using the 'oc' command-line interface tool after logging in with 'oc login'.

AnswersC, E

The OpenShift Web Console is served over HTTPS by the console operator, and browser login uses the same OAuth identity provider as the CLI. This satisfies the web console access method, giving administrators a graphical interface for cluster management.

Why this answer

Option C is correct because administrators can access the OpenShift 4.14 web console by pointing a supported web browser at the console URL (typically https://console-openshift-console.apps.<cluster-domain>), which is the standard browser-based management interface. Option E is correct because the 'oc' CLI is the supported command-line tool for OpenShift, and administrators authenticate to the cluster with 'oc login' (for example, 'oc login https://api.<cluster-domain>:6443 -u <user>') before running management commands. Option A is incorrect because 'systemctl gui-console' is not a valid OpenShift or systemd unit for launching a console on control plane nodes.

Option B is incorrect because SSHing into the API server container runtime socket is neither a supported nor practical method for accessing the web console or CLI. Option D is incorrect because 'kubectl-adm console' is not a real plugin or command in OpenShift or Kubernetes.

Exam trap

EX280 often tests the distinction between supported management interfaces and invalid or non-existent commands, so candidates might mistakenly choose plausible-sounding but fictitious options like 'systemctl gui-console' or 'kubectl-adm console'.

Full explanation →

401

Multi-Selecteasy

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

Select 2 answers

A.VirtualIP

B.ClusterIP

C.IngressObject

D.NodePort

E.Route

AnswersB, D

ClusterIP is a native Kubernetes Service type, exposing an internal virtual IP reachable only within the cluster. OpenShift supports it natively, satisfying the stem's requirement for valid built-in Service types. It provides stable east-west load balancing across selected pods without external exposure, unlike NodePort or LoadBalancer.

Why this answer

Option B (ClusterIP) is correct because ClusterIP is the default Kubernetes/OpenShift Service type that exposes the Service on an internal cluster IP reachable only from within the cluster. Option D (NodePort) is correct because NodePort is a natively supported Service type that exposes the Service on each node's IP at a static port (default range 30000–32767), allowing external access via <NodeIP>:<NodePort>. The other options are not Service types: VirtualIP (A) is not a Kubernetes/OpenShift Service type, IngressObject (C) is not a Service type (Ingress is a separate API resource for HTTP/HTTPS routing), and Route (E) is an OpenShift-specific resource that exposes Services externally but is not itself a Service type.

Exam trap

EX280 often tests the distinction between native Kubernetes Service types and OpenShift-specific resources like Routes, causing candidates to mistakenly select 'Route' as a Service type.

Full explanation →

402

MCQmedium

A developer reports that pods in the namespace 'project-a' cannot resolve services located in the namespace 'project-b' using standard internal DNS names. What is the correct way to query 'project-b' service 'backend' from 'project-a'?

A.backend.project-b.svc.cluster.local

B.backend.project-b.pod.cluster.local

C.backend.project-b.svc

D.backend.project-b.internal

AnswerA

Cross-namespace DNS resolution requires the fully qualified domain name, since the search list only covers the pod's own namespace. The FQDN `backend.project-b.svc.cluster.local` satisfies the stem's constraint: pods in `project-a` resolving a service in `project-b`. The `<service>.<namespace>.svc.cluster.local` format targets that namespace explicitly.

Why this answer

The fully qualified domain name (FQDN) for a Kubernetes/OpenShift Service follows the pattern <service>.<namespace>.svc.cluster.local. Therefore, to reach the 'backend' service in namespace 'project-b' from any other namespace, the correct DNS name is backend.project-b.svc.cluster.local. This FQDN resolves via the cluster's internal DNS to the Service's ClusterIP.

Exam trap

EX280 often tests whether candidates know the exact DNS suffix hierarchy (svc.cluster.local vs pod.cluster.local vs .internal), so the trap is choosing a plausible-looking but incorrect suffix like '.svc' or '.internal' instead of the full FQDN.

How to eliminate wrong answers

Option B (backend.project-b.pod.cluster.local) is wrong because the 'pod' subdomain is used for headless services or direct pod DNS records (e.g., <pod-ip>.<namespace>.pod.cluster.local), not for standard Service resolution — using it would fail to resolve the service name. Option C (backend.project-b.svc) is wrong because while it may work as a relative name within the same cluster domain due to search domains, it is not the fully qualified name and can fail depending on the pod's resolv.conf search list; the question asks for the correct way to query cross-namespace, which requires the FQDN. Option D (backend.project-b.internal) is wrong because '.internal' is not a valid Kubernetes DNS suffix — the cluster domain is 'cluster.local' by default, and 'internal' has no special meaning in cluster DNS.

Full explanation →

403

MCQeasy

You need to provide temporary scratch space for a container that shares the pod's lifetime and is cleared when the pod is deleted. Which volume type should you configure in the Pod specification?

A.persistentVolumeClaim

B.hostPath

C.nfs

D.emptyDir

AnswerD

emptyDir creates a directory tied to the pod's lifecycle, shared by its containers and deleted permanently when the pod is removed. hostPath and persistent volumes outlive the pod, so they fail the stem's scratch-space and lifetime constraints.

Why this answer

An emptyDir volume is created when a pod is assigned to a node and exists for the lifetime of that pod. It is initially empty, provides scratch space for the container, and is deleted permanently when the pod is removed from the node. This exactly matches the requirement for temporary, pod-lifetime scratch space.

Exam trap

EX280 often tests the distinction between emptyDir (pod-lifetime, ephemeral) and hostPath (node-lifetime, persistent) — candidates pick hostPath thinking it provides temporary storage, but it actually persists and exposes host data.

How to eliminate wrong answers

Option A is wrong because persistentVolumeClaim provides durable storage that outlives the pod and is not cleared on pod deletion. Option B is wrong because hostPath mounts a directory from the host node, which persists beyond the pod and can expose host filesystem data, violating the temporary requirement. Option C is wrong because nfs mounts a remote network filesystem that persists independently of the pod and is not cleared on deletion.

Full explanation →

404

MCQmedium

An OpenShift administrator needs to investigate a pod that is failing with an 'OOMKilled' exit code. Which command reveals the memory limit configuration and historical usage right before the crash?

A.oc describe pod <pod-name>

B.oc top pod <pod-name> --containers

C.oc get pod <pod-name> -o yaml

D.oc adm diagnostics

AnswerA

`oc describe pod` reports the container's configured memory limit and requests from the pod spec, plus recent events including OOMKilled terminations. It satisfies the need to see the limit that was exceeded, though historical usage immediately before the crash requires metrics tooling rather than describe output alone.

Why this answer

'oc describe pod <pod-name>' shows the container's resource requests and limits (including memory limit), the last state with the OOMKilled reason, and the exit code 137. It also displays events and the node the pod ran on, giving the administrator the configuration and crash context in one view. This is the standard first command for diagnosing OOMKilled pods.

Exam trap

EX280 often tests whether candidates confuse 'oc describe pod' (shows limits, last state, OOMKilled reason) with 'oc top pod' (shows only live usage) — the trap is picking 'oc top' because it mentions memory.

How to eliminate wrong answers

Option B is wrong because 'oc top pod --containers' shows only current live memory/CPU usage — it cannot show historical usage before the crash or the configured limit. Option C is wrong because 'oc get pod -o yaml' shows the manifest (including limits) but not the last state, exit reason, or historical usage — it lacks the runtime diagnostic detail. Option D is wrong because 'oc adm diagnostics' runs cluster-wide health checks and does not drill into a specific pod's OOM event or memory configuration.

Full explanation →

405

MCQhard

You want to automate the application lifecycle so that every time a code change is pushed, the build and deployment occur automatically. Which combination of features should you use?

A.Only cron jobs

B.Manual build and manual rollout

C.BuildConfig Webhook and ImageStream triggers

D.DeploymentConfigs only

AnswerC

A BuildConfig webhook triggers a build on each code push, and ImageStream triggers then deploy the resulting image automatically. Together they satisfy the stem's requirement for fully automated build and deployment on every code change, without manual intervention.

Why this answer

In OpenShift, BuildConfig webhooks (GitHub, GitLab, Bitbucket, or generic) allow external code repositories to trigger a new build automatically when a change is pushed. ImageStream triggers then detect when a new image is pushed to an ImageStream and automatically start a new deployment (via DeploymentConfig or Deployment). Together, they create a fully automated CI/CD pipeline from code push to deployment.

This is the standard OpenShift-native approach for automating the application lifecycle.

Exam trap

EX280 often tests the misconception that DeploymentConfigs alone can automate deployments, confusing manual triggers with automatic ones, or overlooking the need for a build trigger (webhook) and an image trigger (ImageStream) to achieve full automation.

How to eliminate wrong answers

Option A is wrong because cron jobs only schedule tasks at fixed times and cannot react to code changes; they lack integration with source control or image streams. Option B is wrong because manual build and manual rollout require human intervention, which defeats the purpose of automation. Option D is wrong because DeploymentConfigs alone only manage deployment and scaling; they do not trigger builds or respond to code pushes without additional triggers like ImageStreams or webhooks.

Full explanation →

406

MCQhard

What is the result of using a 'Recreate' strategy during a deployment?

A.Zero downtime deployment

B.Rolling update

C.Temporary service outage

D.Instant switch

AnswerC

The Recreate strategy terminates all existing pods before starting new ones, so no instances serve traffic during the gap. This satisfies the stem's scenario, producing a temporary service outage, unlike RollingUpdate which maintains availability throughout the transition.

Why this answer

The Recreate strategy terminates all existing Pods before creating new ones, which necessarily causes a temporary service outage because there is a period with zero running Pods. This is in contrast to RollingUpdate, which maintains availability by incrementally replacing Pods. The Recreate strategy is used when the application cannot run multiple versions concurrently.

Exam trap

EX280 often tests the trade-off between Recreate (downtime, no version overlap) and RollingUpdate (no downtime, version overlap), so candidates must recognize that Recreate inherently causes an outage.

How to eliminate wrong answers

Option A is wrong because zero downtime requires a rolling update or blue-green deployment, not Recreate. Option B is wrong because a rolling update is a different strategy (RollingUpdate) that replaces Pods incrementally. Option D is wrong because 'Instant switch' is not a standard deployment strategy and does not describe Recreate's behavior.

Full explanation →

407

MCQhard

You need to terminate TLS for a route using a custom certificate. Which object must contain the TLS key and certificate?

A.A Secret in the same namespace as the route

B.A ConfigMap in the 'openshift-config' namespace

C.A custom resource definition of type TLS

D.The ingress controller configuration

AnswerA

OpenShift routes reference a TLS certificate and private key held in a Secret within the route's own namespace; the router reads that Secret to serve the custom certificate. This satisfies the stem's requirement to terminate TLS with a custom certificate rather than the default router certificate.

Why this answer

In OpenShift, TLS termination for a Route is configured by referencing a TLS certificate and key stored in a Kubernetes Secret. The Secret must reside in the same namespace as the Route because Routes are namespace-scoped resources and can only reference Secrets within their own namespace. The Secret must be of type kubernetes.io/tls and contain tls.crt and tls.key.

This design ensures isolation and proper RBAC control.

Exam trap

EX280 often tests the misconception that TLS certificates for routes are stored in ConfigMaps or in the openshift-config namespace, but the correct answer is always a Secret in the same namespace as the route.

How to eliminate wrong answers

Option B is wrong because ConfigMaps are intended for non-sensitive configuration data and are not used to store TLS private keys; also, the 'openshift-config' namespace is for cluster-wide configuration, not per-route TLS. Option C is wrong because there is no custom resource definition of type TLS in OpenShift for route termination; TLS certificates are stored in Secrets, not CRDs. Option D is wrong because the ingress controller configuration is a cluster-wide resource that defines default certificates and router behavior, but it cannot be used to specify a custom certificate for an individual route.

Full explanation →

408

Multi-Selectmedium

An administrator is configuring a ResourceQuota named 'quota-dev' in the 'development' namespace. Which TWO of the following resource types can be directly tracked and limited by this ResourceQuota? (Choose TWO)

Select 2 answers

A.persistentvolumeclaims

B.clusterroles

C.pods

D.namespaces

E.nodes

AnswersA, C

ResourceQuota directly limits persistentvolumeclaims by counting their quantity within the namespace, satisfying the 'development' namespace constraint. Unlike CPU or memory requests, which apply to pods, PVC quotas cap storage claims independently, allowing administrators to restrict how many volumes teams can provision without touching cluster-wide storage classes.

Why this answer

Option A (persistentvolumeclaims) is correct because Kubernetes ResourceQuota objects support the persistentvolumeclaims field, which limits the number of PVCs that can exist in the namespace, as well as requests.storage to cap total storage requested. Option C (pods) is correct because ResourceQuota natively supports the pods field, allowing the administrator to limit the total number of Pods created in the 'development' namespace. Options B (clusterroles), D (namespaces), and E (nodes) are incorrect because they are cluster-scoped resources, not namespaced resources; ResourceQuota only applies to namespaced objects within the namespace where the quota is defined, so it cannot track or limit ClusterRoles, Namespaces, or Nodes.

Exam trap

EX280 often tests the scope of ResourceQuota, and candidates may incorrectly include cluster-scoped resources like clusterroles or nodes, which are not namespaced and thus cannot be limited by ResourceQuota.

Full explanation →

409

MCQmedium

A cluster administrator wishes to enforce the restricted Pod Security Standard across an entire namespace named auditing-ns. Which label should the administrator apply to the namespace to enforce this policy while generating audit warnings for non-compliant pods?

A.pod-security.kubernetes.io/enforce: restricted and pod-security.kubernetes.io/audit: restricted

B.security.openshift.io/scc.enforce: restricted-v2

C.security.openshift.io/pod-security-standard: enforce-restricted

D.admission.cluster.openshift.io/validate-psa: true

AnswerA

Namespace labels drive Pod Security Admission. Setting enforce to restricted blocks non-compliant pods, while audit set to restricted records violations in the audit log without blocking, satisfying the requirement for enforcement plus audit warnings across auditing-ns.

Why this answer

To enforce the restricted Pod Security Standard across a namespace and generate audit warnings, the administrator must apply the 'pod-security.kubernetes.io/enforce: restricted' label to enforce the policy and 'pod-security.kubernetes.io/audit: restricted' to log audit events for non-compliant pods. These labels are part of the Kubernetes Pod Security Admission (PSA) feature, which OpenShift 4.x uses.

Exam trap

EX280 often tests the exact label syntax for Pod Security Admission — candidates may confuse SCC-related labels or invent non-existent annotation keys.

How to eliminate wrong answers

Option B is wrong because 'security.openshift.io/scc.enforce' is not a valid label for Pod Security Admission; SCCs (Security Context Constraints) are a separate OpenShift mechanism and are not configured via namespace labels. Option C is wrong because 'security.openshift.io/pod-security-standard' is not a recognized label — the correct prefix is 'pod-security.kubernetes.io/'. Option D is wrong because 'admission.cluster.openshift.io/validate-psa' is not a valid label or configuration key for enforcing PSA.

Full explanation →

410

Multi-Selecthard

Which TWO things must be configured to use a Private Image Registry?

Select 2 answers

A.A route to the registry

B.A docker-registry type secret

C.Linking the secret to the service account

D.Creating a new ClusterRole

E.Updating the node configuration

AnswersB, C

A docker-registry secret holds the registry credentials in the required format, which OpenShift uses when authenticating to the private registry. Creating it satisfies the requirement for storing authentication details before linking them to the service account.

Why this answer

To pull images from a private image registry, Kubernetes needs credentials, which are supplied via a docker-registry type secret (option B) containing the registry URL, username, and password/token in .dockerconfigjson format. That secret must then be linked to the service account (option C) used by the pod (e.g., via the imagePullSecrets field or the service account's imagePullSecrets), so the kubelet can authenticate when pulling the image. A route to the registry (A) is only needed for external network access and is not a required configuration element for using a private registry.

Creating a new ClusterRole (D) is unnecessary because image pulling is governed by node credentials and imagePullSecrets, not RBAC ClusterRoles. Updating the node configuration (E) is not required since authentication is handled through the secret and service account rather than by reconfiguring nodes.

Exam trap

EX280 often tests whether candidates know both halves — the Secret alone is insufficient; it must be linked to the ServiceAccount (or referenced as imagePullSecrets) for the pull to succeed.

Full explanation →

411

MCQeasy

What is the purpose of the 'oc adm drain' command during cluster maintenance?

A.To restart the kubelet service and flush local DNS caches.

B.To permanently delete the node and its virtual machine instance from the cloud provider.

C.To mark a node unschedulable and gracefully evict workloads running on it.

D.To clear container logs and free up disk space on the node filesystem.

AnswerC

Marking a node unschedulable prevents new pods from landing there, while graceful eviction respects pod disruption budgets and terminates existing workloads cleanly. This satisfies the maintenance constraint of removing a node from service without abruptly killing running applications, letting controllers reschedule them elsewhere.

Why this answer

The 'oc adm drain' command is used to safely evict all pods from a node before maintenance, such as rebooting or upgrading. It marks the node as unschedulable (cordon) and then evicts pods, respecting PodDisruptionBudgets. This ensures workloads are gracefully moved to other nodes, minimizing downtime.

Exam trap

EX280 often tests the difference between 'cordon' and 'drain'—cordon only marks unschedulable, while drain also evicts pods. Candidates may confuse drain with node deletion or log cleanup.

How to eliminate wrong answers

Option A is wrong because draining does not restart kubelet or flush DNS caches; that would be done via systemctl or node commands. Option B is wrong because drain does not delete the node or its VM; node deletion is a separate action (e.g., 'oc delete node'). Option D is wrong because drain does not clear logs or free disk space; it only evicts pods.

Full explanation →

412

MCQhard

An OpenShift cluster administrator receives an alert that etcd disk fsync durations are excessively high. Which performance metric is the etcd diagnostic tool measuring when evaluating disk latency?

A.The network round trip time between etcd follower and leader nodes.

B.The time taken for etcd to commit WAL (Write-Ahead Log) entries to persistent storage via fsync.

C.The time taken by the Kubernetes API server to serialize JSON objects.

D.The garbage collection duration of expired etcd keys.

AnswerB

The etcd diagnostic tool measures fsync latency: the duration for etcd to commit Write-Ahead Log entries to persistent storage. Elevated values indicate slow disk writes, directly explaining the excessively high fsync durations reported in the alert.

Why this answer

The etcd diagnostic tool measures disk fsync latency — the time for etcd to commit Write-Ahead Log (WAL) entries to persistent storage via fsync — because etcd's performance is bound by disk I/O on the WAL. High fsync durations directly cause slow etcd writes, leader election instability, and API server timeouts, which is why the alert fires.

Exam trap

EX280 often tests whether candidates confuse etcd disk fsync latency with network peer latency or API server performance, leading them to pick the network or serialization option.

How to eliminate wrong answers

Option A is wrong because network round-trip time between etcd peers is measured separately (peer latency) and is not what fsync duration refers to. Option C is wrong because API server JSON serialization is a control-plane CPU concern, unrelated to etcd disk fsync. Option D is wrong because etcd garbage collection (compaction and defragmentation) is a maintenance operation, not the fsync latency metric the diagnostic tool reports.

Full explanation →

413

Multi-Selecteasy

Which TWO of the following commands can an administrator use to verify the identity and permissions of the currently logged-in user? (Choose TWO)

Select 2 answers

A.oc whoami

B.oc get user --current

C.oc auth can-i --list

D.oc adm who-can-i

E.oc describe authentication

AnswersA, C

Running oc whoami returns the authenticated username bound to the current session token, directly confirming the identity half of the verification requirement. It queries the OpenShift API server, which validates the OAuth access token and reports the mapped user, satisfying the stem's need to establish who is logged in.

Why this answer

Option A, `oc whoami`, is correct because it queries the OpenShift API server and returns the username of the identity associated with the current session's credentials, directly verifying who the logged-in user is. Option C, `oc auth can-i --list`, is correct because it performs a SelfSubjectRulesReview against the API server and prints the full list of verbs and resources the current user is permitted to perform, thereby verifying the user's permissions. Option B, `oc get user --current`, is not a valid command—`oc get user` lists User objects but has no `--current` flag to identify the logged-in user.

Option D, `oc adm who-can-i`, is not a real subcommand; the actual command is `oc adm policy who-can <verb> <resource>`, which checks which users can perform an action, not the current user's identity. Option E, `oc describe authentication`, is not valid because `authentication` is a cluster-scoped configuration resource (operator.openshift.io) and describing it shows cluster auth configuration, not the current user's identity or permissions.

Exam trap

EX280 often tests the difference between `oc whoami` (identity) and `oc auth can-i` (authorization), causing candidates to pick invalid commands like `oc get user --current`.

Full explanation →

414

MCQhard

An administrator expands a PVC from 10Gi to 50Gi. The underlying cloud storage volume is successfully resized, but inside the running pod, 'df -h' still reports the size as 10Gi. What is the most likely reason?

A.The pod must be restarted to flush the Linux page cache.

B.The file system on the volume has not been expanded to occupy the new block storage capacity.

C.The StorageClass lacks the allowVolumeExpansion parameter.

D.PVC expansion is strictly read-only after creation and cannot be updated at the filesystem level.

AnswerB

Resizing the cloud volume expands the underlying block device, but the filesystem must then be grown separately to occupy that capacity. Until the filesystem is expanded, df -h inside the pod continues reporting the original 10Gi size.

Why this answer

When a PVC is expanded, the CSI driver resizes the underlying block volume, but the filesystem inside the volume must also be expanded to use the new space. For filesystems like ext4 or XFS, this requires a resize operation (resize2fs or xfs_growfs), which is typically triggered by the kubelet when the pod is restarted or when the CSI driver supports online expansion. If the filesystem resize hasn't occurred, 'df -h' inside the pod still reports the old size.

Exam trap

EX280 often tests the two-stage nature of volume expansion — candidates assume that resizing the cloud volume automatically resizes the filesystem, but the filesystem resize is a separate step that may require a pod restart or may be handled online depending on the CSI driver.

How to eliminate wrong answers

Option A is wrong because the Linux page cache does not control filesystem size reporting — restarting the pod alone won't change 'df -h' output unless the filesystem resize is triggered as part of the volume remount. Option C is wrong because if the StorageClass lacked 'allowVolumeExpansion: true', the PVC expansion would have been rejected by the API server, and the underlying cloud volume would not have been resized — but the question states the cloud volume was successfully resized. Option D is wrong because PVC expansion is supported (when allowVolumeExpansion is true) and is not read-only; the filesystem can be grown, though shrinking is not supported.

Full explanation →

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