CCNA Cluster Installation And Management Questions

MCQeasy

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

A.Operator Lifecycle Manager

B.Machine Config Operator

C.Cluster Version Operator

D.Machine API Operator

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.Machine Config Operator (MCO)

B.Cluster Version Operator (CVO)

C.Cluster Infrastructure Operator (CIO)

D.Operator Lifecycle Manager (OLM)

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecthard

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

Select 3 answers

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

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

C.Verify the OLM CatalogSource status.

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

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

AnswersB, D, E

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

Why this answer

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

Practice this question →

MCQmedium

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

A.oc get csv

B.oc get operators --all-namespaces

C.oc adm cluster-health

D.oc get clusteroperators

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

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

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

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

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

E.Inspect the MachineConfigPool status conditions for OLM errors.

AnswersA, C

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

Why this answer

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

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

Exam trap

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

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

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

C.Review the ClusterVersion resource status conditions.

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

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

AnswersD, E

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

Why this answer

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

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

Exam trap

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

Practice this question →

MCQmedium

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

A.oc version --cluster

B.oc get nodes --version

C.oc get clusterversion

D.oc describe operator cluster

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.selector

B.deletePolicy

C.template

D.replicas

AnswerD

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

Why this answer

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

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

Exam trap

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

Practice this question →

MCQeasy

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

A.openshift-machine-api

B.openshift-operator-lifecycle-manager

C.openshift-cluster-version

D.openshift-config

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

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

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

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

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

AnswerD

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

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

B.Handling external DNS records and cluster ingress routing.

C.Provisioning cloud provider virtual machines for cluster scaling.

D.Managing container image registries and secure image signing.

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

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

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

C.View the ClusterVersion status conditions.

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

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

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

C.The 'Updating' condition status is False.

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

E.The 'DegradedMachineCount' is greater than zero.

AnswersB, C

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

Why this answer

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

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

Exam trap

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

Practice this question →

Multi-Selecteasy

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

Select 2 answers

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

B.oc logs <pod-name>

C.oc system-log dump

D.oc adm tail-events

E.oc get events

AnswersB, E

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

Why this answer

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

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

Exam trap

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

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.openshift-user-workloads

B.kube-public-custom

C.openshift-cluster-version

D.openshift-machine-config-operator

E.openshift-custom-catalog

AnswersC, D

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

Why this answer

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

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

Exam trap

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

Practice this question →

MCQmedium

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

A.oc adm upgrade

B.oc describe upgrade-channel

C.oc get clusterversion --recommendations

D.oc cluster-version check

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecthard

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

Select 3 answers

A.MachineSet

B.ClusterVersion

C.OperatorGroup

D.ClusterAutoscaler

E.MachineHealthCheck

AnswersA, D, E

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

Why this answer

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

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

Exam trap

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

Practice this question →

MCQhard

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

A.Modify the cluster-wide node migration ConfigMap.

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

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

B.Scale the OLM operator pods to zero.

C.Delete the CatalogSource resource entirely.

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

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

AnswersA, D

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

Why this answer

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

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

Exam trap

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

Practice this question →

Multi-Selecthard

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

Select 3 answers

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

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

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

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

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

AnswersA, B, C

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

Why this answer

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

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

Exam trap

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

Practice this question →

MCQhard

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.MachineHealthCheck

B.KubeletConfig

C.ContainerRuntimeConfig

D.NodeNetworkConfigurationPolicy

AnswerC

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecthard

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

Select 2 answers

A.oc describe clusteroperator <operator-name>

B.oc get clusterversion

C.oc get clusteroperators

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

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

AnswersA, C

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

Why this answer

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

Exam trap

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

Practice this question →

MCQmedium

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

A.oc get machineconfigpool --cordoned

B.oc describe clusteroperator scheduling

C.oc get nodes

D.oc adm show-cordoned

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.oc adm certificate-status

B.oc get csr

C.oc describe clusteroperator pkcs

D.oc get certificates --all-namespaces

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.NodeScalingOperator resource

B.MachineConfigPool autoscaler status

C.ClusterAutoscaler and MachineAutoscaler

D.ClusterVersion autoscaling spec

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.NodeAutoscaler

B.MachineConfigPool

C.ClusterAutoscaler

D.MachineHealthCheck

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.oc get machinesets

B.oc get machineconfigpools

C.oc get csv --all-namespaces

D.oc get clusteroperators

E.oc get clusterversion

AnswersD, E

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

Why this answer

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

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

Exam trap

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

Practice this question →

MCQmedium

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

A.Apply a MachineConfig to the worker MachineConfigPool pausing the updates, then reboot the node.

B.Run 'oc adm cordon worker-01' followed by 'oc adm drain worker-01 --delete-emptydir-data --ignore-daemonsets'.

C.Stop the kubelet service on worker-01 via systemctl and reboot the underlying operating system.

D.Run 'oc delete node worker-01' directly to force the cluster control plane to automatically reschedule workloads.

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.To load balance ingress traffic across worker nodes.

B.To ensure a specified number of identical machine instances are running and healthy.

C.To manage persistent volume claims across storage backends.

D.To group cluster nodes by operating system kernel version.

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.oc adm get machines

B.oc get cluster-infrastructure

C.oc get machineconfigpools

D.oc get machinesets -A (or within openshift-machine-api)

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.Patch the worker MachineConfigPool to set 'spec.paused: true'.

B.Delete all pending MachineConfig objects from the cluster.

C.Scale down the machine-config-operator deployment in openshift-machine-config-operator to zero replicas.

D.Annotate all worker nodes with 'machineconfiguration.openshift.io/paused=true'.

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.Completed=True and Ready=True

B.Available=True and Progressing=False

C.Available=False and Progressing=True

D.Upgraded=True and Finished=True

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.Create a KubeletConfig custom resource defining the desired kubelet parameters.

B.Directly edit the kubelet.conf file on every node via SSH.

C.Restart the kubelet service manually on all nodes using systemctl.

D.Modify the ClusterVersion spec to include kubelet flags.

E.Configure the machineConfigPoolSelector in the KubeletConfig to target the worker pool.

AnswersA, E

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

Why this answer

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

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

Exam trap

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

Practice this question →

Multi-Selectmedium

An administrator wants to configure automated remediation for worker nodes that become unresponsive or experience hardware failure. Which TWO configurations or resources are required for a MachineHealthCheck to function properly? (Choose TWO)

Select 2 answers

A.A replica count specifying how many remediation pods to run.

B.Unhealthy conditions specifying the node status condition and timeout duration.

C.Match labels pointing to the target MachineSet or machine pool.

D.A ContainerRuntimeConfig specifying reboot parameters.

E.An OperatorGroup defining the namespace for the health check.

AnswersB, C

Unhealthy conditions define which node status conditions, such as Ready being Unknown, and the timeout duration before a node is deemed unhealthy. Without this threshold, the MachineHealthCheck cannot distinguish a failed node from a transient blip, so remediation never triggers.

Why this answer

Option B is correct because a MachineHealthCheck must define unhealthyConditions, which specify the node status condition type (for example Ready) and a timeout duration that determines how long the condition must persist before the node is considered unhealthy and remediation is triggered. Option C is correct because a MachineHealthCheck uses a selector with matchLabels to identify the target MachineSet or machine pool whose machines it will monitor and remediate. Option A is incorrect because MachineHealthCheck does not use a replica count for remediation pods; remediation is performed by deleting and recreating the unhealthy Machine via its MachineSet.

Option D is incorrect because ContainerRuntimeConfig is used to configure container runtime settings like pidsLimit or logLevel, not node health remediation. Option E is incorrect because an OperatorGroup defines the namespaces an Operator watches and is unrelated to MachineHealthCheck configuration.

Exam trap

EX280 often tests the confusion between MachineHealthCheck and other node-management resources, so candidates may pick unrelated options like ContainerRuntimeConfig or OperatorGroup, which serve entirely different purposes.

Practice this question →

MCQmedium

An administrator notices that a worker node is in a 'NotReady' state due to a storage failure. The administrator successfully replaces the underlying physical machine and wants to clear the old node object from the OpenShift 4.14 cluster. Which command should be used?

A.oc adm cordon worker-old --purge

B.oc patch machine worker-old --type=merge -p '{"spec":{"deleted":true}}'

C.oc remove node-status worker-old

D.oc delete node worker-old

AnswerD

Deleting the Node object removes the stale worker registration and its associated resources, letting the replacement machine rejoin cleanly. The node must first be drained or the machine powered off, since oc delete node acts on the cluster-scoped Node API object.

Why this answer

To remove a node object from an OpenShift cluster, the correct command is `oc delete node <node-name>`. This deletes the Node resource from the cluster, and if the node is managed by a MachineSet, the Machine object may also be deleted or replaced. In this scenario, the administrator has already replaced the physical machine, so deleting the old node object is appropriate.

Exam trap

EX280 often tests the correct command for node removal, tricking candidates into using cordon or drain instead of delete, or inventing non-existent commands like `oc remove`.

How to eliminate wrong answers

Option A is wrong because `oc adm cordon` only marks the node as unschedulable; it does not delete it, and `--purge` is not a valid flag for cordon. Option B is wrong because patching a Machine object with `deleted: true` is not a standard way to remove a node; Machine deletion is handled by the Machine API, but the command syntax is incorrect. Option C is wrong because `oc remove node-status` is not a valid command; there is no such subcommand.

Practice this question →

Multi-Selecthard

An administrator is planning an OpenShift 4.14 cluster upgrade and wants to ensure that specific safety checks and conditions are met before proceeding. Which THREE conditions must be true for an upgrade to proceed smoothly? (Choose THREE)

Select 3 answers

A.All MachineConfigPools must be fully updated and not in a degraded state.

B.The cluster must be switched to the 'nightly' channel for all production upgrades.

C.All user-created namespaces must be temporarily deleted prior to upgrade.

D.The target version must be part of a valid, recommended update path from the current version.

E.All core cluster operators must report healthy status without being degraded.

AnswersA, D, E

MachineConfigPools must be fully updated and not degraded, because the Cluster Version Operator blocks upgrades while any pool is still rolling out or has failed nodes. This prevents the upgrade from compounding an existing configuration drift or unhealthy node state.

Why this answer

Option A is correct because OpenShift's Cluster Version Operator will not begin an upgrade while any MachineConfigPool is still updating or degraded; each pool must report Updated=True and Degraded=False so that node configuration rollouts complete cleanly. Option D is correct because upgrades must follow a supported path in the Cincinnati update graph — the target version must be a recommended or valid next hop from the current version, otherwise the CVO blocks the update. Option E is correct because all cluster operators (including the Cluster Version Operator itself) must report Available=True and Degraded=False; a degraded operator halts the upgrade to prevent further damage.

Option B is wrong because 'nightly' channels are for pre-release testing, not production upgrades, which should use stable/eus channels. Option C is wrong because user namespaces and workloads are not deleted before an upgrade; OpenShift upgrades are designed to preserve tenant workloads.

Exam trap

EX280 often tests the misconception that any newer version can be upgraded to directly, or that nightly channels are acceptable for production, when in fact OpenShift enforces valid update paths and stable channels for production.

Practice this question →

MCQeasy

Which component in OpenShift 4.14 serves as the API entry point for managing MachineAPI resources like Machines and MachineSets?

A.Cluster Version Operator

B.Machine Config Operator

C.Operator Lifecycle Manager

D.Machine API Operator

AnswerD

The Machine API Operator manages the Machine and MachineSet custom resources and their controllers, exposing them through the cluster's API for lifecycle operations. It is the component that reconciles these MachineAPI objects, distinguishing it from the Cluster Baremetal Operator or Machine Config Operator, which handle node provisioning and configuration instead.

Why this answer

The Machine API Operator is the component that manages the lifecycle of MachineAPI resources such as Machines, MachineSets, and MachineHealthChecks. It deploys and reconciles the machine-api controllers and CRDs, making it the API entry point for cluster node provisioning in OpenShift 4.

Exam trap

EX280 often tests the confusion between the Machine API Operator (manages Machine/MachineSet resources) and the Machine Config Operator (manages node OS configuration), so candidates pick MCO when the question asks about MachineAPI resources.

How to eliminate wrong answers

Option A is wrong because the Cluster Version Operator manages cluster upgrades and release image reconciliation, not MachineAPI resources. Option B is wrong because the Machine Config Operator applies OS-level configuration (Ignition, kubelet, systemd) to nodes; it does not manage Machine or MachineSet objects. Option C is wrong because Operator Lifecycle Manager handles installation and upgrades of operators via Subscriptions and InstallPlans, not the MachineAPI.

Practice this question →

Multi-Selecteasy

Which TWO tasks are typically performed by an OpenShift cluster administrator when managing worker node lifecycles? (Choose TWO)

Select 2 answers

A.Directly editing etcd data files on control plane nodes.

B.Manually compiling custom Linux kernel binaries on every node via SSH.

C.Writing custom source code for the Kubernetes API server.

D.Cordoning and draining nodes for operating system maintenance.

E.Applying labels to nodes to control MachineConfigPool membership.

AnswersD, E

Cordoning marks the node unschedulable so no new pods land there, while draining evicts existing workloads gracefully. Together they let the administrator safely take a worker offline for OS patching or upgrades without disrupting running applications.

Why this answer

Option D is correct because cordoning a node marks it as unschedulable (kubectl cordon) and draining it evicts running pods (kubectl drain) so the node can safely undergo OS patching, reboots, or other maintenance without disrupting workloads. Option E is correct because node labels are the mechanism that determines which nodes belong to a given MachineConfigPool, allowing the administrator to target specific MachineConfig updates to defined groups of worker nodes. Option A is not a typical administrator task, since etcd data files on control plane nodes are managed by the etcd operator and should not be edited directly.

Option B is incorrect because OpenShift manages the OS via immutable RHCOS and MachineConfig, not by manually compiling kernels over SSH. Option C is incorrect because writing Kubernetes API server source code is upstream development work, not cluster administration.

Exam trap

EX280 often tests the misconception that administrators manually manage nodes via SSH or edit control plane components, when in reality OpenShift uses declarative management through MachineConfigs and the MCO, and node lifecycle tasks like cordoning/draining and labeling are the correct administrative actions.

Practice this question →

Multi-Selecteasy

An administrator is preparing to perform maintenance on worker nodes in an OpenShift 4.14 cluster. Which TWO commands or actions are part of the standard workflow to safely prepare a node for maintenance? (Choose TWO)

Select 2 answers

A.Run 'oc delete node <node-name> --force' immediately before stopping services.

B.Run 'oc adm cordon <node-name>' to mark the node as unschedulable.

C.Stop the kubelet service directly via systemctl without cordoning.

D.Run 'oc adm drain <node-name> --delete-emptydir-data --ignore-daemonsets' to evict existing pods.

E.Scale the MachineConfigPool replicas to zero.

AnswersB, D

Cordoning sets the node's spec.unschedulable field to true, so the scheduler places no new pods there while existing workloads keep running. This satisfies the requirement to stop new scheduling before draining, preventing rescheduling onto a node about to undergo maintenance.

Why this answer

Option B is correct because 'oc adm cordon <node-name>' marks the node as unschedulable, preventing the scheduler from placing new pods on it while existing workloads continue running, which is the required first step before maintenance. Option D is correct because 'oc adm drain <node-name> --delete-emptydir-data --ignore-daemonsets' safely evicts the node's pods; --ignore-daemonsets is needed since DaemonSet pods cannot be evicted, and --delete-emptydir-data allows removal of pods using emptyDir volumes. Together, cordon then drain is the standard OpenShift 4.14 workflow to prepare a worker node for maintenance.

Option A is wrong because force-deleting the Node object does not gracefully evict pods and can leave workloads in an inconsistent state. Option C is wrong because stopping kubelet without cordoning or draining leaves pods abruptly terminated and the node still marked schedulable. Option E is wrong because scaling a MachineConfigPool to zero replicas is not a node-maintenance procedure and would disrupt the pool's managed nodes.

Exam trap

EX280 often tests whether candidates confuse the destructive 'oc delete node --force' with the graceful cordon-then-drain workflow, or forget that DaemonSet pods require --ignore-daemonsets to allow drain to complete.

Practice this question →

MCQmedium

An administrator is preparing to upgrade an OpenShift Container Platform 4.14 cluster from version 4.13.12 to 4.14.6. Before starting the upgrade, the administrator wants to ensure that all cluster Operators are healthy and that no prerequisites are blocking the upgrade. Which command should the administrator run to view the current upgrade status and any available updates?

A.oc get nodes -o wide

B.oc describe clusteroperators

C.oc adm upgrade

D.oc get clusterversion version -o yaml

AnswerC

This command displays the current cluster version, available updates, and any upgrade conditions or blockers. It is the standard tool to assess upgrade readiness and see recommended updates. It directly provides the information needed to verify that the cluster is in a healthy state before initiating an upgrade, making it the correct first step.

Why this answer

The `oc adm upgrade` command is designed to show the current cluster version, any available updates, and conditions that might prevent an upgrade. It provides a concise summary that helps administrators decide whether to proceed. Before upgrading, it is essential to confirm that all ClusterOperators are available and not degraded, and that no upgrade blockers exist.

This command directly surfaces that information.

Exam trap

The trap here is confusing general cluster inspection commands with the specific upgrade status command that reports available updates and blockers.

Practice this question →

MCQeasy

Which namespace contains the Machine Config Operator (MCO) and its associated daemon pods in OpenShift 4.14?

A.openshift-machine-config-operator

B.openshift-infra

C.openshift-machine-api

D.openshift-cluster-version

AnswerA

The Machine Config Operator and its machine-config-daemon pods run in the openshift-machine-config-operator namespace, the dedicated system namespace OpenShift 4.14 creates for MCO components. Other namespaces, such as openshift-config or default, do not host these operator pods.

Why this answer

The Machine Config Operator (MCO) in OpenShift 4.14 runs in the `openshift-machine-config-operator` namespace. This namespace hosts the MCO deployment and its associated daemon pods (machine-config-daemon) that apply machine configurations to nodes. The other namespaces serve different cluster functions.

Exam trap

EX280 often tests namespace locations of core operators, and candidates may confuse `openshift-machine-config-operator` with `openshift-machine-api` due to similar naming.

How to eliminate wrong answers

Option B is wrong because `openshift-infra` is a legacy namespace used in OpenShift 3 for infrastructure components, not for MCO in OpenShift 4. Option C is wrong because `openshift-machine-api` contains the Machine API Operator and related components for cluster machine management, not the MCO. Option D is wrong because `openshift-cluster-version` hosts the Cluster Version Operator (CVO) which manages cluster updates, not the MCO.

Practice this question →

MCQmedium

An administrator installed an Operator via OperatorHub and selected a specific update channel. Later, the administrator wants to switch the Subscription to a different update channel. How should this be performed?

A.Edit the Subscription custom resource and modify the 'spec.channel' field to the new channel.

B.Delete the Operator's CSV and reinstall the Operator from scratch via the CLI.

C.Modify the OperatorGroup target namespace to force a channel renegotiation.

D.Patch the ClusterServiceVersion directly with the new channel identifier.

AnswerA

Update channels are declared in the Subscription custom resource's spec.channel field. Editing that field to the new channel value causes the Operator Lifecycle Manager to reconcile and begin serving updates from the selected channel, without reinstalling the Operator.

Why this answer

To switch an Operator's update channel, you edit the Subscription custom resource and change the spec.channel field to the desired channel name. The Operator Lifecycle Manager (OLM) then reconciles the Subscription and upgrades/downgrades the Operator to the latest version available in that channel. This is the supported and non-disruptive method.

Exam trap

EX280 often tests the misconception that you must reinstall an Operator to change its update channel, when in fact editing the Subscription's spec.channel is sufficient.

How to eliminate wrong answers

Option B is wrong because deleting the CSV and reinstalling from scratch is disruptive, unnecessary, and does not preserve the Subscription; it also may leave residual resources. Option C is wrong because modifying the OperatorGroup target namespace does not affect channel selection; OperatorGroup defines the namespaces the Operator watches, not the update channel. Option D is wrong because patching the CSV directly with a channel identifier is not how OLM works; the CSV does not have a channel field, and manual edits can break the Operator's lifecycle management.

Practice this question →

Multi-Selecthard

An administrator is managing operator subscriptions and wants to ensure that an operator is automatically updated when new versions are released in the channel. Which THREE conditions or configuration settings must be satisfied? (Choose THREE)

Select 3 answers

A.The OperatorGroup must correctly encompass the target namespace scope.

B.A healthy CatalogSource must be available providing the operator manifests.

C.The Subscription must have 'spec.installPlanApproval: Automatic' configured.

D.The Cluster Version Operator must have auto-upgrade enabled for third-party operators.

E.The global pull secret must be deleted so OLM can fetch unauthenticated updates.

AnswersA, B, C

The OperatorGroup defines which namespaces the subscription's operator watches; if its scope excludes the target namespace, the operator cannot be installed there, so automatic channel updates never apply. Correctly encompassing the target namespace is therefore a prerequisite for the update mechanism to function.

Why this answer

Option A is correct because the OperatorGroup defines the set of target namespaces (its spec.targetNamespaces or the namespace it resides in) that the operator's CSV will be deployed to, and OLM will not resolve or upgrade a Subscription whose OperatorGroup scope does not cover the intended namespace. Option B is correct because OLM resolves available operator versions from the package manifests served by a CatalogSource; if that CatalogSource is unhealthy or missing, no new bundles are discovered and no upgrade can be triggered. Option C is correct because spec.installPlanApproval: Automatic on the Subscription causes OLM to automatically approve the generated InstallPlan when a newer bundle appears in the channel, which is exactly what enables unattended updates.

Option D is not correct because the Cluster Version Operator manages OpenShift platform components, not third-party OLM operators, and has no auto-upgrade setting governing them. Option E is not correct because deleting the global pull secret would break image pulls from authenticated registries; OLM uses the existing pull secrets and does not require unauthenticated catalog access.

Exam trap

EX280 often tests the OLM update chain — candidates pick plausible-sounding but incorrect options like CVO auto-upgrade or pull secret manipulation, missing that the three real prerequisites are OperatorGroup scope, CatalogSource health, and Automatic InstallPlan approval.

Practice this question →

Multi-Selecteasy

Which TWO actions can an administrator perform using the 'oc adm' command set related to cluster management? (Choose TWO)

Select 2 answers

A.Write custom container Dockerfiles on cluster nodes.

B.Initiate and manage cluster upgrades.

C.Manage user project request limits directly.

D.Cordon or drain cluster nodes for maintenance.

E.Create application deployments directly without YAML files.

AnswersB, D

The `oc adm upgrade` subcommand initiates and monitors cluster version upgrades, satisfying the stem's cluster-management constraint. It queries and applies available OpenShift release channels, letting administrators approve or schedule upgrades directly. This is a genuine administrative action within the `oc adm` command set, unlike workload-level operations.

Why this answer

Option B is correct because the 'oc adm upgrade' subcommand (e.g., 'oc adm upgrade --to=<version>') lets administrators initiate, monitor, and manage OpenShift cluster upgrades, including viewing available update channels and approving upgrades. Option D is correct because 'oc adm cordon <node>' and 'oc adm drain <node>' are administrative commands used to mark nodes unschedulable and evict workloads for maintenance. Option A is incorrect because Dockerfiles are authored in a build context and built with tools like 'docker build' or 'oc new-build', not via 'oc adm' on cluster nodes.

Option C is incorrect because project request limits are managed through ClusterResourceQuota or the project request template, not directly via 'oc adm'. Option E is incorrect because application deployments are created with 'oc new-app' or 'oc create', not through the 'oc adm' administrative command set.

Exam trap

EX280 often tests the boundary between 'oc' (developer) and 'oc adm' (administrator) commands, tricking candidates into selecting developer tasks like 'oc new-app' as if they were administrative 'oc adm' operations.

Practice this question →

Multi-Selectmedium

An administrator wants to check the status of Machine API provisioning and verify that all machines are in a running state. Which TWO commands or resource inspections should the administrator perform? (Choose TWO)

Select 2 answers

A.Run 'oc adm machine-status'.

B.Run 'oc get clusteroperators --machines'.

C.Run 'oc get machines -A' to list all provisioned machines across namespaces.

D.Run 'oc get machinesets -A' to check replica counts and desired states.

E.Run 'oc get machineconfigpools --machines'.

AnswersC, D

Running `oc get machines -A` queries the Machine API's Machine resources cluster-wide, listing every provisioned machine and its current phase across all namespaces. This directly satisfies the stem's requirement to verify that all machines are in a running state, since the PHASE column reveals whether each machine reports Running.

Why this answer

Option C is correct because 'oc get machines -A' lists all Machine objects across all namespaces, letting the administrator inspect each machine's PHASE (e.g., Running, Provisioned, Provisioning) to confirm they are in a running state. Option D is correct because 'oc get machinesets -A' shows each MachineSet's DESIRED, CURRENT, and READY replica counts, which verifies that the desired number of machines has been provisioned and is healthy. Option A is wrong because 'oc adm machine-status' is not a valid oc adm subcommand.

Option B is wrong because 'oc get clusteroperators' does not accept a '--machines' flag and reports ClusterOperator status, not Machine API provisioning. Option E is wrong because 'oc get machineconfigpools' does not accept a '--machines' flag and reports MachineConfigPool node configuration status, not Machine provisioning state.

Exam trap

EX280 often tests whether candidates know the actual 'oc' commands and resource names for Machine API inspection, so made-up commands like 'oc adm machine-status' or invalid flags like '--machines' are common distractors.

Practice this question →

MCQhard

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?

A.Review the OperatorHub catalog source logs in openshift-marketplace.

B.Check the logs of the machine-config-daemon pods in the openshift-machine-config-operator namespace.

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

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

AnswerB

The Machine Config Daemon runs on each node and reports apply failures; its pod logs in the openshift-machine-config-operator namespace contain the precise error, such as a failed systemd unit or file write, that degraded the pool.

Why this answer

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.

Exam trap

EX280 often tests whether candidates know that MachineConfig apply errors live in the machine-config-daemon pod logs in openshift-machine-config-operator, not in CVO or OperatorHub logs.

How to eliminate wrong answers

Option A is wrong because OperatorHub catalog source logs in openshift-marketplace relate to OLM operator installation, not to MachineConfig application. Option C is wrong because 'oc adm node-logs --role=worker' retrieves node journal logs (useful for kernel/systemd issues) but does not surface the MCD's structured apply errors, and kernel panics are not the typical failure mode for a bad MachineConfig. Option D is wrong because the Cluster Version Operator logs in openshift-cluster-version track cluster upgrades, not per-node MachineConfig application failures.

Practice this question →

Multi-Selectmedium

An administrator needs to identify worker nodes that require attention during an upgrade or maintenance. Which TWO conditions or states on a node object indicate potential issues or special maintenance states? (Choose TWO)

Select 2 answers

A.Running=Normal

B.SchedulingDisabled

C.Active=True

D.Schedulable=True

E.NotReady

AnswersB, E

SchedulingDisabled marks a node cordoned by an administrator, meaning no new pods are scheduled onto it. This directly signals a special maintenance state, letting the administrator identify nodes deliberately drained or reserved before an upgrade proceeds.

Why this answer

Option B (SchedulingDisabled) is correct because this condition on a node object indicates the node has been cordoned (via `oc adm cordon` or `kubectl cordon`), meaning it is marked unschedulable and will not accept new pods, which is a special maintenance state administrators must track during upgrades. Option E (NotReady) is correct because the Ready condition set to NotReady (or Unknown) means the node's kubelet is not reporting healthy status to the control plane, signaling a potential problem requiring attention. Options A (Running=Normal) and C (Active=True) are not valid node conditions in OpenShift/Kubernetes node status, so they do not indicate anything meaningful.

Option D (Schedulable=True) is the normal, healthy state indicating the node can accept pods, so it does not represent an issue or special maintenance state.

Exam trap

EX280 often tests whether candidates can distinguish normal healthy states (Schedulable=True, Ready=True) from maintenance/issue states (SchedulingDisabled, NotReady), so picking 'Schedulable=True' as an issue is the common mistake.

Practice this question →

MCQmedium

An administrator wants to check why a specific MachineConfigPool is taking a long time to complete an update. Which status condition on the MachineConfigPool indicates that nodes are currently being updated?

A.Updating=True

B.RollingOut=Running

C.Reconciling=Pending

D.Progressing=Active

AnswerA

Updating=True is the MachineConfigPool status condition that signals the pool's nodes are actively being reconfigured. It directly answers the stem's question about which condition shows an update in progress, distinguishing it from Updated, Degraded or RenderFailed.

Why this answer

The MachineConfigPool (MCP) status includes a condition of type 'Updating'. When this condition's status is 'True', it explicitly indicates that the pool is actively applying configuration changes to its nodes. This is the standard condition used by the Machine Config Operator (MCO) to signal that an update is in progress.

Therefore, option A is correct.

Exam trap

EX280 often tests the specific condition names and statuses in OpenShift resource statuses, and candidates may confuse generic Kubernetes conditions like 'Progressing' with the actual MCP conditions, leading them to select plausible but incorrect options.

How to eliminate wrong answers

Option B is wrong because 'RollingOut=Running' is not a valid condition type or status in the MachineConfigPool API; the MCP uses conditions like 'Updated', 'Updating', 'Degraded', and 'RenderDegraded'. Option C is wrong because 'Reconciling=Pending' is not a recognized condition; the MCP does not have a 'Reconciling' condition. Option D is wrong because 'Progressing=Active' is not a condition type used by the MCP; while 'Progressing' might appear in some Kubernetes resources, it is not part of the MCP status.

Practice this question →

MCQeasy

Which component in OpenShift 4.14 coordinates the creation of certificates for cluster components and worker nodes?

A.Machine API Operator

B.Kubernetes CSR controller / OpenShift PKI operators

C.Cluster Autoscaler

D.Operator Lifecycle Manager (OLM)

AnswerB

The Kubernetes CSR controller and OpenShift PKI operators handle certificate signing requests, issuing and renewing certificates for cluster components and worker nodes. This satisfies the stem's requirement for the coordinating component, since the CSR controller approves and signs CSRs while the PKI operators manage the certificate authorities and rotation lifecycle.

Why this answer

In OpenShift 4.x, the Kubernetes CSR (Certificate Signing Request) controller works in tandem with OpenShift PKI operators to automate certificate issuance and rotation for cluster components and worker nodes. The CSR controller approves and signs CSRs submitted by kubelet and other components, while PKI operators manage the lifecycle of CA certificates and ensure trust distribution. This integrated mechanism eliminates manual certificate management, which was common in OpenShift 3.

Exam trap

EX280 often tests the distinction between operators responsible for infrastructure (Machine API, Cluster Autoscaler) and those handling security/PKI, causing candidates to confuse certificate management with node provisioning or operator lifecycle.

How to eliminate wrong answers

Option A is wrong because the Machine API Operator manages the lifecycle of machines (nodes) in the cluster, including provisioning and scaling, but it does not handle certificate creation or signing. Option C is wrong because the Cluster Autoscaler adjusts the number of nodes in a cluster based on workload demands; it has no role in certificate management. Option D is wrong because Operator Lifecycle Manager (OLM) manages the installation, upgrade, and lifecycle of Operators themselves, not the certificates for cluster components or nodes.

Practice this question →

MCQmedium

An OpenShift 4.14 cluster administrator has installed an Operator from OperatorHub into a custom namespace using a Subscription. The administrator notices that the Operator pod is not being created. Upon checking the Subscription, the installation mode is set to AllNamespaces, but the Operator target namespace is restricted. Which Operator Lifecycle Manager (OLM) object should the administrator inspect to troubleshoot why the CSV (ClusterServiceVersion) is not installing?

A.Check the MachineConfigPool for paused reconciliation flags.

B.Review the ClusterVersion resource status for pending updates.

C.Inspect the OperatorGroup in the target namespace to ensure its targetNamespaces match or support the Subscription scope.

D.Inspect the KubeletConfig custom resource for validation errors.

AnswerC

The OperatorGroup defines which namespaces a CSV can target; a mismatch between its `targetNamespaces` and the Subscription's AllNamespaces scope blocks CSV resolution, so no Operator pod is created. Inspecting it in the target namespace reveals whether the group supports that scope, directly diagnosing the failed installation.

Why this answer

The OperatorGroup defines the target namespaces that an Operator can watch and install into. When a Subscription uses AllNamespaces mode but the OperatorGroup restricts targetNamespaces, OLM cannot reconcile the CSV into the desired scope, so the Operator pod never gets created. Inspecting the OperatorGroup in the target namespace reveals the mismatch.

Exam trap

EX280 often tests the misconception that Subscription alone controls Operator scope, when in fact the OperatorGroup's targetNamespaces must be compatible with the Subscription's install mode.

How to eliminate wrong answers

Option A is wrong because MachineConfigPool paused flags affect node configuration updates, not OLM Operator installation. Option B is wrong because ClusterVersion status tracks OpenShift platform updates, unrelated to Operator CSV reconciliation. Option D is wrong because KubeletConfig validation errors affect kubelet settings on nodes, not Operator Lifecycle Manager behavior.

Practice this question →

MCQeasy

Which OpenShift 4.14 command is used to uncordon a worker node and return it to a schedulable state after maintenance?

A.oc node enable

B.oc adm uncordon

C.oc adm schedulable

D.oc scale node

AnswerB

The oc adm uncordon command clears the unschedulable taint from a node, allowing the scheduler to place new pods on it again. This is the exact counterpart to oc adm cordon, which marked the worker unschedulable before maintenance began.

Why this answer

The correct command is `oc adm uncordon <node-name>`. This command removes the unschedulable taint from the node, allowing the scheduler to place new pods on it. It is the standard OpenShift/Kubernetes administrative command for reversing a cordon operation.

Exam trap

EX280 often tests the distinction between `oc adm cordon/uncordon` and other node management commands, and candidates may confuse `uncordon` with `drain` or invent non-existent commands like `oc node enable`.

How to eliminate wrong answers

Option A is wrong because `oc node enable` does not exist as a command in OpenShift; node management is done via `oc adm`. Option C is wrong because `oc adm schedulable` is not a valid subcommand; the correct subcommands are `cordon` and `uncordon`. Option D is wrong because `oc scale node` is not a valid command; scaling applies to resources like Deployments or ReplicationControllers, not nodes.

Practice this question →

Multi-Selecthard

An administrator needs to configure secure access to a private registry for both node image pulls and OLM operator deployments. Which THREE actions or resources are required across the cluster? (Choose THREE)

Select 3 answers

A.Update the global pull secret in openshift-config/pull-secret with registry credentials.

B.Ensure CA trust certificates are distributed to nodes via ConfigMaps and image config.

C.Modify the ClusterVersion spec to disable TLS verification globally.

D.Scale the Machine API operator to zero during credential updates.

E.Configure ImageContentSourcePolicy or ImageTagMirrorSet resources for image redirection.

AnswersA, B, E

Global pull secret enables nodes to pull images from authenticated registries.

Why this answer

Option A is correct because the global pull secret stored in the openshift-config namespace as pull-secret must contain the private registry credentials so that all nodes and the internal registry can authenticate when pulling images. Option B is correct because when the registry uses a custom or self-signed CA, the CA certificate must be distributed to nodes via a ConfigMap referenced in the cluster-wide image config (image.config.openshift.io/cluster) so that CRI-O and related components trust the registry's TLS certificate. Option E is correct because ImageContentSourcePolicy (or the newer ImageTagMirrorSet/ImageDigestMirrorSet) resources redirect image pulls from upstream references to the private registry mirror, which is required for both node image pulls and OLM operator deployments to resolve images correctly.

Option C is incorrect because disabling TLS verification globally via ClusterVersion is not a supported or secure practice and would undermine the secure access requirement. Option D is incorrect because scaling the Machine API operator to zero is unrelated to registry credential or trust configuration and would disrupt cluster machine management.

Exam trap

EX280 often tests the misconception that updating only the global pull secret is sufficient for private registry access, when in fact CA trust distribution and image mirror/redirection policies are equally required for both node pulls and OLM operator deployments.

Practice this question →

MCQhard

An administrator running OpenShift 4.14 wants to configure automatic approval for an Operator subscription updates using the Operator Lifecycle Manager. Which field and value in the Subscription resource must be set?

A.Set 'spec.installPlanApproval: Automatic'

B.Set 'spec.channel.autoApprove: yes'

C.Set 'spec.autoUpgrade: true'

D.Set 'spec.approvalStrategy: Immediate'

AnswerA

Setting `spec.installPlanApproval: Automatic` on the Subscription resource satisfies the stem's requirement for automatic approval of Operator updates. The Operator Lifecycle Manager reads this field and installs each new InstallPlan without manual intervention, whereas the default `Manual` value requires an administrator to approve every upgrade.

Why this answer

In OpenShift, the Subscription resource's spec.installPlanApproval field controls whether InstallPlans for an Operator update are approved automatically or manually. Setting it to 'Automatic' means OLM will automatically approve any InstallPlan that is generated for a new version in the subscribed channel, enabling seamless updates. This is the documented field and value for automatic approval in OLM.

Exam trap

EX280 often tests the exact field name and value for OLM subscription configuration, and candidates may confuse it with non-existent fields like autoUpgrade or approvalStrategy, or incorrectly assume that channel settings control approval.

How to eliminate wrong answers

Option B is wrong because 'spec.channel.autoApprove' does not exist; the channel field is a string specifying the update channel (e.g., 'stable'), not an object with an autoApprove property. Option C is wrong because 'spec.autoUpgrade' is not a valid field in the Subscription CRD; automatic upgrades are controlled via installPlanApproval, not a boolean autoUpgrade. Option D is wrong because 'spec.approvalStrategy' is not a field; the correct field is installPlanApproval, and its valid values are 'Automatic' or 'Manual', not 'Immediate'.

Practice this question →

MCQmedium

An administrator needs to update the global pull secret for an OpenShift 4.14 cluster so that nodes can pull images from a new authenticated private registry. Which resource stores the global pull secret?

A.The MachineConfigPool resource named 'worker'.

B.The ClusterVersion custom resource spec field 'pullSecret'.

C.A Secret named 'pull-secret' in the 'openshift-config' namespace.

D.A ConfigMap named 'global-pull-registry' in 'kube-system'.

AnswerC

The global pull secret resides in the 'openshift-config' namespace as a Secret named 'pull-secret', which the cluster propagates to each node's kubelet configuration. Updating this single resource satisfies the requirement that all nodes authenticate to the new private registry without per-node edits.

Why this answer

The global pull secret for an OpenShift cluster is stored as a Secret named 'pull-secret' in the openshift-config namespace. Updating this secret causes the MCO to propagate the new credentials to every node's /var/lib/kubelet/config.json (and to the internal registry), enabling pulls from the new authenticated registry. This is the documented location for cluster-wide registry credentials.

Exam trap

EX280 often tests the confusion between the ClusterVersion spec.pullSecret reference and the actual Secret object, plus the misconception that pull credentials live in a ConfigMap or in kube-system.

How to eliminate wrong answers

Option A is wrong because a MachineConfigPool only tracks node configuration rollout state — it does not store registry credentials. Option B is wrong because while ClusterVersion has a spec.pullSecret field, that field references the Secret by name in openshift-config; the actual credential data lives in the Secret, not in the ClusterVersion object. Option D is wrong because there is no ConfigMap named 'global-pull-registry' in kube-system — pull credentials are Secrets, not ConfigMaps, and the namespace is openshift-config, not kube-system.

Practice this question →

MCQeasy

What is the primary role of Operator Lifecycle Manager (OLM) in OpenShift 4.14?

A.Managing the installation, upgrades, and RBAC lifecycle of Operators in the cluster.

B.Monitoring node CPU and memory utilization thresholds.

C.Provisioning physical bare-metal servers for cluster expansion.

D.Encrypting etcd database contents at rest.

AnswerA

OLM installs, upgrades and manages the RBAC and lifecycle of Operators across the cluster, resolving dependency and version constraints automatically. This directly satisfies the question's focus on installation, upgrades and RBAC lifecycle management within OpenShift 4.14.

Why this answer

Operator Lifecycle Manager (OLM) is the OpenShift component that provides a declarative way to install, upgrade, and manage the lifecycle of Operators and their associated RBAC. It introduces Custom Resource Definitions (CRDs) like ClusterServiceVersion (CSV), Subscription, and InstallPlan to automate dependency resolution, version upgrades, and permission grants. OLM ensures Operators are installed with the correct service accounts, roles, and role bindings, and it handles upgrades through channels and approval strategies.

Thus, option A accurately captures OLM's primary role.

Exam trap

EX280 often tests the misconception that OLM handles low-level infrastructure tasks like node monitoring or etcd encryption, when in fact it is strictly focused on Operator lifecycle management.

How to eliminate wrong answers

Option B is wrong because node CPU and memory monitoring is handled by the OpenShift monitoring stack (Prometheus, Alertmanager, and node-exporter), not OLM. Option C is wrong because bare-metal provisioning is performed by the OpenShift installer (IPI/UPI) or Metal3, not OLM. Option D is wrong because etcd encryption at rest is configured via the API server's encryption configuration and is managed by the cluster's kube-apiserver, not OLM.

Practice this question →

Multi-Selectmedium

An administrator needs to troubleshoot an upgrade failure in OpenShift 4.14. Which TWO actions or diagnostic steps should the administrator take? (Choose TWO)

Select 2 answers

A.Reboot the entire cluster control plane via physical power cycles.

B.Delete all pods in the openshift-cluster-version namespace to force a clean restart.

C.Inspect any cluster operators reporting 'Degraded=True' or 'Progressing=True'.

D.Run 'oc describe clusterversion' to view upgrade history, channels, and failure messages.

E.Scale down all OLM Operator subscriptions to zero.

AnswersC, D

Cluster operators expose their health through status conditions, so operators reporting Degraded=True or Progressing=True pinpoint which component is blocking the upgrade. Inspecting these conditions identifies the failing subsystem, satisfying the need to diagnose the OpenShift 4.14 upgrade failure.

Why this answer

Option C is correct because during an OpenShift 4.x upgrade the Cluster Version Operator orchestrates ClusterOperators, and any operator stuck with Degraded=True or Progressing=True directly identifies the component blocking or failing the upgrade, making it the primary diagnostic signal. Option D is correct because 'oc describe clusterversion' (or 'oc get clusterversion -o yaml') exposes the ClusterVersion status, including the current and desired channel, version history, conditions, and the specific failure message recorded by the CVO, which is essential for pinpointing why an upgrade failed. Option A is wrong because power-cycling the control plane is disruptive, unsupported, and risks etcd corruption without providing any diagnostic value.

Option B is wrong because deleting pods in openshift-cluster-version does not force a clean restart of the upgrade and can disrupt the CVO's reconciliation logic. Option E is wrong because scaling OLM subscriptions to zero would break operator management and is unrelated to diagnosing a cluster version upgrade failure.

Exam trap

EX280 often tests whether candidates know to inspect ClusterOperator conditions and clusterversion history rather than taking drastic remediation actions like rebooting the control plane or deleting CVO pods.

Practice this question →

Multi-Selecthard

An administrator wants to customize worker node behavior in an OpenShift 4.14 cluster using the Machine Config Operator. Which THREE custom resources are natively provided and managed by the MCO for node customization? (Choose THREE)

Select 3 answers

A.ClusterVersion

B.MachineConfig

C.KubeletConfig

D.ContainerRuntimeConfig

E.OperatorGroup

AnswersB, C, D

MachineConfig is the MCO's core custom resource, delivering Ignition configs that write files, systemd units and kernel arguments to nodes. It satisfies the stem's requirement for a natively provided MCO resource used to customise worker node behaviour.

Why this answer

The Machine Config Operator (MCO) natively manages three node-customization custom resources: MachineConfig (B), which defines Ignition-based changes to files, systemd units, and kernel arguments on nodes; KubeletConfig (C), which customizes kubelet parameters such as maxPods, podPidsLimit, and eviction thresholds; and ContainerRuntimeConfig (D), which tunes CRI-O settings like pidsLimit and logLevel. These three CRs are all reconciled by the MCO's controller and rendered into the machine-config daemon's desired state. ClusterVersion (A) is managed by the Cluster Version Operator (CVO) to control cluster updates, not by the MCO for node customization.

OperatorGroup (E) is an OLM resource that scopes Operator installation to namespaces and is unrelated to MCO node configuration.

Exam trap

EX280 often tests the confusion between resources managed by different operators. The trap is assuming ClusterVersion is managed by MCO, but it's actually managed by CVO.

Practice this question →

MCQeasy

Which custom resource defines a group of nodes (such as all worker nodes or a custom compute pool) that share a common MachineConfig in OpenShift 4.14?

A.NodeGroup

B.MachineSet

C.MachineConfigPool

D.ConfigMap

AnswerC

MachineConfigPool groups nodes sharing a common MachineConfig, targeting updates to worker nodes or custom pools via node selectors. It is the custom resource that binds MachineConfigs to defined node sets, matching the stem's requirement precisely.

Why this answer

A MachineConfigPool (MCP) groups nodes that share the same MachineConfig, such as all worker nodes (the 'worker' pool) or a custom pool like 'infra'. The Machine Config Operator (MCO) applies MachineConfigs to nodes based on their pool membership, and each pool has its own rendered MachineConfig. This is the resource that defines a set of nodes with a common configuration.

Exam trap

The trap is confusing MachineSet (which manages machine lifecycle/scaling) with MachineConfigPool (which groups nodes for configuration), or picking the generic ConfigMap because it sounds like a configuration grouping resource.

How to eliminate wrong answers

Option A is wrong because NodeGroup is not an OpenShift resource — it is a concept in other systems (e.g., GKE node pools, EKS managed node groups), not an OpenShift CRD. Option B is wrong because MachineSet manages the lifecycle and scaling of machines (nodes) for a MachineConfigPool, but it does not define the configuration grouping itself — MachineSets are associated with a pool via labels, not the other way around. Option D is wrong because ConfigMap is a generic Kubernetes resource for storing non-confidential configuration data; it has no role in defining node configuration groups in OpenShift.

Practice this question →

MCQhard

An administrator wants to apply kernel arguments to all worker nodes in an OpenShift 4.14 cluster using the Machine Config Operator. After creating a new MachineConfig object, the administrator notices that the worker nodes are not updating and the MachineConfigPool status shows 'Updating=False'. What is the most likely cause?

A.The administrator forgot to run 'oc adm upgrade --force' to trigger node reboots.

B.The MachineConfig object lacks the correct labels required to associate it with the target MachineConfigPool.

C.The Cluster Version Operator must be manually restarted to detect new MachineConfig definitions.

D.The cluster storage provider must be re-initialized to support kernel argument persistence.

AnswerB

The Machine Config Operator selects MachineConfigs by the machineconfiguration.openshift.io/role label, which binds each object to a MachineConfigPool. Without the matching worker role label, the rendered config never merges into that pool, so nodes stay put and the pool reports Updating=False.

Why this answer

MachineConfig objects are associated with a MachineConfigPool (MCP) through the 'machineconfiguration.openshift.io/role' label (e.g., 'worker' or 'master'). Without this label, the MCO has no way to know which pool should consume the config, so the pool's rendered config never changes and 'Updating=False' remains. The MCO does not scan for arbitrary MachineConfigs — it only renders configs whose role label matches the pool's node selector.

Exam trap

EX280 often tests the assumption that any MachineConfig object is automatically applied cluster-wide; the trap is forgetting that MachineConfigs are scoped to a pool via the 'machineconfiguration.openshift.io/role' label, not applied globally.

How to eliminate wrong answers

Option A is wrong because 'oc adm upgrade --force' is a Cluster Version Operator command for triggering cluster upgrades, not for applying MachineConfig changes; the MCO reboots nodes automatically when the rendered config changes. Option C is wrong because the Cluster Version Operator does not detect MachineConfig objects — the Machine Config Operator watches them directly, and restarting CVO has no effect on MCP rendering. Option D is wrong because kernel argument persistence is handled by the MCO writing to the node's bootloader config via Ignition; storage providers have no role in this process.

Practice this question →

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.

Practice this question →

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.

Practice this question →

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'.

Practice this question →

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.

Practice this question →