EX280 Timed Hard Questions — 25 Difficult Questions

Question 1

An administrator is analyzing a severe networking issue where pod-to-pod communication across different worker nodes fails. Which THREE diagnostic utilities or commands should they execute inside an oc debug session on the nodes? (Choose THREE)

15 minute time limit — choose an answer to begin.

Accepted Answer

tcpdump -i . Option B (tcpdump -i ) is correct because capturing packets on the node's physical or overlay interface lets the administrator verify whether pod-to-pod traffic is actually leaving and arriving at the worker nodes, revealing drops, MTU issues, or missing encapsulation. Option C (ovs-ofctl dump-flows br-int) is correct because OpenShift SDN/OVN-Kubernetes uses Open vSwitch, and inspecting the flow tables on the br-int bridge shows whether the OVS rules correctly forward traffic between pods on different nodes. Option E (ip route show) is correct because cross-node pod communication depends on correct routing entries (e.g., routes to the pod CIDR or tunnel endpoints), so checking the node's routing table confirms whether packets have a valid path to the remote node's pod subnet. Option A (oc adm upgrade status) is unrelated, as it only reports cluster upgrade progress and has no bearing on live pod-to-pod connectivity. Option D (etcdctl endpoint health) checks the health of the etcd datastore, which, while important for the control plane, does not diagnose data-plane forwarding failures between pods on different worker nodes.

Answer

oc adm upgrade status

Answer

etcdctl endpoint health

Question 2

Which TWO of the following actions occur when a user is deleted from an OpenShift cluster using 'oc delete user <username>'? (Choose TWO)

Accepted Answer

The User resource object is removed from the cluster database.. Option A is correct because 'oc delete user <username>' removes the User resource object itself from etcd, the cluster's backing datastore, so the user no longer exists as an OpenShift API object. Option D is correct because deleting the User triggers revocation of that user's OAuth access tokens and refresh tokens, invalidating existing sessions so the identity can no longer authenticate. Option B is wrong because OpenShift does not write back to external identity providers; LDAP or OIDC records are managed outside the cluster and are untouched. Option C is wrong because namespaces are independent resources and are not garbage-collected when a user is deleted. Option E is wrong because RoleBindings and ClusterRoleBindings are not automatically removed; they may remain and reference a now-nonexistent user until manually cleaned up.

Answer

External identity provider records are automatically deleted from LDAP or OIDC servers.

Answer

All namespaces owned or created by the user are permanently deleted.

Answer

All RoleBindings and ClusterRoleBindings referencing the user are automatically deleted.

Question 3

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?

Accepted Answer

The Corefile in the cluster DNS operator configuration has incorrect or missing forward plugins for external resolvers.. 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.

Answer

The API server service is missing endpoint IPs.

Answer

NodePort range exhaustion prevents external DNS packets from traversing worker nodes.

Answer

The cluster ingress controller is blocking external UDP port 53.

Question 4

Which THREE of the following are required when configuring an OIDC identity provider?

Accepted Answer

Client Secret reference. When configuring an OIDC identity provider, the Client ID (C) is required because it uniquely identifies the relying party/application to the OpenID Provider during the authorization code flow. The Client Secret reference (A) is also required so the application can authenticate itself to the token endpoint and securely exchange the authorization code for tokens. The Issuer URL (E) is required because it identifies the OpenID Provider's metadata document (typically at /.well-known/openid-configuration), enabling discovery of endpoints such as authorization_endpoint, token_endpoint, and jwks_uri. The Htpasswd file path (B) is not part of OIDC; it belongs to HTTP Basic authentication using a local password file. The LDAP bind password (D) is also unrelated to OIDC, as it is used for LDAP directory authentication, not for OpenID Connect token exchange.

Answer

Htpasswd file path

Answer

LDAP bind password

Question 5

An administrator is setting up a new custom MachineConfigPool for GPU-enabled worker nodes. After creating the MachineConfigPool resource, the administrator creates a MachineConfig that should apply exclusively to these nodes. What must the administrator include in the MachineConfig to ensure it only applies to the GPU pool?

Accepted Answer

Labels matching the machineconfigpool selector (e.g., 'pools.operator.machineconfiguration.openshift.io/gpu-worker: ""').. MachineConfigs are applied to nodes based on the MachineConfigPool's node selector, which uses the label 'pools.operator.machineconfiguration.openshift.io/<pool-name>'. To target the GPU pool, the MachineConfig must include a label matching that selector, e.g., 'pools.operator.machineconfiguration.openshift.io/gpu-worker: ""'. The MCO then renders and applies the config only to nodes in that pool.

Answer

Placing the MachineConfig object directly inside the GPU namespace.

Answer

A field in the spec named 'targetPool: gpu-worker'.

Answer

An annotation specifying 'machineconfigpool.openshift.io/target: gpu-worker'.

Question 6

A developer requests a PersistentVolumeClaim using ReadWriteMany access mode. Which default storage type in a standard AWS ODF (OpenShift Data Foundation) deployment natively supports RWX?

Accepted Answer

openshift-storage.cephfs.csi.ceph.com. The CephFS CSI driver (openshift-storage.cephfs.csi.ceph.com) is the only default storage class in an AWS OpenShift Data Foundation deployment that natively supports ReadWriteMany (RWX) access mode. CephFS is a POSIX-compliant shared filesystem that allows multiple pods on different nodes to mount and write to the same volume simultaneously. RBD (RADOS Block Device) and EBS are block storage, which only support ReadWriteOnce (RWO) or ReadOnlyMany (ROX), not RWX.

Answer

openshift-storage.rbd.csi.ceph.com

Answer

gp2-csi.storage.k8s.io

Answer

ebs.csi.aws.com

Question 7

An OpenShift cluster upgrade stalled because a MachineConfigPool is paused. The administrator needs to verify which MachineConfigPool is paused and unpause it. Which command accomplishes this?

Accepted Answer

oc get machineconfigpools. Checking the MachineConfigPool resource YAML or status shows the paused state, which can be modified using oc patch or oc edit.

Answer

oc adm upgrade resume

Answer

oc get mcp --show-paused

Answer

oc resume machineconfigpool/worker

Question 8

A cluster uses a CSI driver that does not support volume expansion. A user edits an existing PVC to request a larger size. What action does the OpenShift API server take?

Accepted Answer

The resize request fails or is marked with an error condition because expansion is unsupported.. When a user edits a PVC to request a larger size, the API server validates the change against the StorageClass's allowVolumeExpansion field and the CSI driver's capabilities. If the driver does not support volume expansion (or allowVolumeExpansion is false), the resize request is rejected or the PVC is marked with a ResizeError/FileSystemResizePending condition indicating expansion is unsupported. The PVC's requested size is not silently accepted without backend action.

Answer

The PVC size is updated in Kubernetes metadata, but physical storage is left unchanged.

Answer

OpenShift automatically converts the PVC to use a default storage class that supports expansion.

Answer

The pod is immediately terminated and restarted on a node with more disk space.

Question 9

An administrator notices that a namespace has exceeded its object count quota for ConfigMaps. When a developer attempts to create a new ConfigMap, what error response is returned by the API server?

Accepted Answer

HTTP 403 Forbidden with a message stating the resource quota has been exceeded. When a namespace exceeds its object count quota for ConfigMaps, the API server rejects the create request with HTTP 403 Forbidden and a message indicating the resource quota has been exceeded. ResourceQuota admission control enforces this at admission time, so the object is never persisted. The error is a quota violation, not an authentication or timeout issue.

Answer

HTTP 401 Unauthorized forcing the user to re-authenticate

Answer

HTTP 200 OK, but the ConfigMap is placed in a pending state until quota frees up

Answer

HTTP 504 Gateway Timeout because the controller manager is blocked

Question 10

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

Accepted Answer

oc logs -n openshift-machine-config-operator daemonset/machine-config-daemon. Option E is correct because `oc describe machineconfigpool ` shows the pool's status conditions, including Degraded, Updated, Updating, and the reason/message fields that identify why the pool is degraded. Option C is correct because listing MachineConfigs with the label `machineconfiguration.openshift.io/role=` shows the rendered and role-specific configs applied to that pool, helping spot a bad or mismatched MachineConfig. Option A is correct because `oc logs -n openshift-machine-config-operator daemonset/machine-config-daemon` retrieves the Machine Config Daemon logs, where the actual node-level failure (e.g., failed systemd unit, file write, or reboot issue) is recorded. Option B is wrong because scaling the cluster-version-operator deployment does not diagnose a degraded MachineConfigPool and is not a supported troubleshooting step. Option D is wrong because `oc adm upgrade cancel` only cancels an in-progress cluster upgrade and does not reveal the root cause of the MachineConfigPool degradation.

Answer

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

Answer

oc adm upgrade cancel

Question 11

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

Accepted Answer

provisioner. Option B (provisioner) is correct because every StorageClass must specify the provisioner field, which identifies the volume plugin (e.g., kubernetes.io/aws-ebs, ebs.csi.aws.com, or kubernetes.io/no-provisioner) used to dynamically provision PersistentVolumes. Option C (volumeBindingMode) is correct because it is a valid StorageClass field that controls when volume binding and dynamic provisioning occur, with supported values Immediate and WaitForFirstConsumer. Option E (reclaimPolicy) is correct because StorageClass supports the reclaimPolicy field to define the default PersistentVolume reclaim behavior for dynamically provisioned volumes, with valid values Delete and Retain. Option A (containerRuntime) is not a StorageClass parameter; it relates to container runtime configuration (e.g., CRI-O) and is not part of the storage.k8s.io/v1 StorageClass schema. Option D (nodeSelector) is not a StorageClass field; node selection for storage is handled via allowedTopologies or in PersistentVolume nodeAffinity, not a nodeSelector key on StorageClass.

Answer

containerRuntime

Answer

nodeSelector

Question 12

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

Accepted Answer

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

Answer

When the PVC object is successfully created in the namespace.

Answer

When the user executes 'oc adm pv create'.

Answer

When the CSI driver operator starts up during cluster bootstrap.

Question 13

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

Accepted Answer

The PersistentVolumeClaim (to check binding status and provisioner errors). Option B is correct because 'oc describe pvc ' 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 ' 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 ' 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.

Answer

The cluster image registry configuration

Answer

The OAuth client credentials secret

Question 14

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

Accepted Answer

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

Answer

StartupProbe

Answer

LivenessProbe

Answer

HealthProbe

Question 15

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)

Accepted Answer

A RoleBinding must exist in 'namespace-b' referencing the ServiceAccount as 'system:serviceaccount:namespace-a:sa-name'.. 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.

Answer

The source namespace must disable its LimitRange objects.

Answer

An administrative override annotation must be placed on the target namespace.

Answer

The ServiceAccount must be granted cluster-admin rights cluster-wide.

Question 16

You have a build that fails because it requires access to a private repository. What is the correct way to provide credentials to the build?

Accepted Answer

Associate a secret with the BuildConfig. To let a build pull from a private repository, you associate a Secret containing the registry credentials with the BuildConfig via `spec.strategy.sourceStrategy.pullSecret` (or `spec.output` for push secrets). OpenShift injects this secret into the build pod so it can authenticate to the private registry. This keeps credentials out of the Dockerfile and source code, aligning with security best practices.

Answer

Hardcode credentials in the Dockerfile

Answer

Use an environment variable in the deployment

Answer

Mount a ConfigMap

Question 17

During a troubleshooting session on a degraded cluster operator, an administrator finds that the operator's operand configuration is controlled by a Custom Resource (CR). Where is the most reliable place to look for error status messages reported by the operator controller loop regarding this CR?

Accepted Answer

The status field of the specific Custom Resource instance (e.g., 'oc get

-o yaml').. Operator controllers reconcile a Custom Resource and write observed state, conditions, and error messages back into the CR's status field. The most reliable place to see controller-reported errors is the status subresource of that specific CR instance, typically viewed with 'oc get

-o yaml'. This reflects the controller's own view of the operand's health and any reconciliation failures.

Answer

The default Kubernetes events in the default namespace.

Answer

The global clusterversion object status conditions.

Answer

The /var/log/messages file on the master nodes.

Question 18

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?

Accepted Answer

volumeMode: Block. 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.

Answer

mountOptions: [ "raw" ]

Answer

accessMode: RawBlock

Answer

storageType: Unformatted

Question 19

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?

Accepted Answer

bob lacks the 'self-provisioner' cluster role, which can be granted via cluster-admin binding. 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.

Answer

bob needs an explicit RoleBinding for the 'admin' role in the default namespace

Answer

bob's user object is missing the 'project-creator' annotation

Answer

bob must be added to the cluster-admin group in the oauth configuration

Question 20

An administrator is inspecting an OpenShift 4.14 cluster and notices that the MachineConfigPool for workers is in a degraded state because a MachineConfig failed to apply. Where should the administrator look to find the exact error encountered by the Machine Config Daemon on the affected nodes?

Accepted Answer

Check the logs of the machine-config-daemon pods in the openshift-machine-config-operator namespace.. The Machine Config Daemon runs as a pod on each node in the openshift-machine-config-operator namespace and is responsible for applying rendered MachineConfigs and reporting errors back to the MCO. When a MachineConfig fails to apply and the pool goes degraded, the exact error (e.g., failed systemd unit, invalid Ignition, file conflict) is recorded in the machine-config-daemon pod logs on the affected node.

Answer

Review the OperatorHub catalog source logs in openshift-marketplace.

Answer

Run 'oc adm node-logs --role=worker' to view kernel panic messages.

Answer

Inspect the Cluster Version Operator logs in openshift-cluster-version.