EX280 Cluster Installation And Management Practice Test 2 — 15 Questions

Question 1

An administrator is examining the cluster architecture and core operators of OpenShift 4.14. Which THREE core operators run as part of the control plane and platform management? (Choose THREE)

Accepted Answer

Cluster Version Operator (CVO). The Cluster Version Operator (CVO) (A) is correct because it is a core control-plane operator in OpenShift 4.x that manages cluster updates by reconciling the ClusterVersion resource and applying the release payload's manifests. The Machine Config Operator (MCO) (B) is correct because it is a fundamental platform operator that manages MachineConfig objects and drives node configuration and OS-level changes (via MachineConfigDaemon) across control-plane and worker nodes. The Ingress Operator (C) is correct because it is a core platform operator that deploys and manages the cluster's ingress controllers and the default router, exposing services externally. The Cluster Autoscaler Operator (D) is not part of the baseline control-plane/platform management set; it is an optional operator that scales machine sets based on workload demand and must be installed/configured separately. Operator Lifecycle Manager (OLM) (E) is not one of the core control-plane operators in this context; it is the subsystem that manages installation and lifecycle of optional Operators (OLM itself is a component, but the question targets the core control-plane/platform operators such as CVO, MCO, and Ingress).

Answer

Cluster Autoscaler Operator

Answer

Operator Lifecycle Manager (OLM)

Question 2

Which TWO methods can an administrator use to view the nodes currently present in an OpenShift 4.14 cluster along with their roles and versions? (Choose TWO)

Accepted Answer

oc describe node . Option B, `oc get nodes`, is correct because it lists every node in the cluster and its output includes the node's roles (shown in the ROLES column, e.g., master/worker) and the Kubernetes version (shown in the VERSION column), which is exactly what the administrator needs. Option A, `oc describe node `, is also correct because the detailed description of a node includes its roles (via labels such as node-role.kubernetes.io/master or node-role.kubernetes.io/worker) and its kubelet version, so an administrator can inspect a specific node's roles and version. Option C, `oc cluster-version nodes`, is not a valid subcommand of `oc cluster-version` (which is used to view cluster version information, not node lists). Option D, `oc get machineconfigpools --nodes`, is invalid because `machineconfigpools` is a Machine Config Operator resource and does not accept a `--nodes` flag to list nodes. Option E, `oc get clusteroperators --nodes`, is invalid because `clusteroperators` lists ClusterOperator resources and does not support a `--nodes` flag for node information.

Answer

oc cluster-version nodes

Answer

oc get machineconfigpools --nodes

Answer

oc get clusteroperators --nodes

Question 3

An administrator wants to inspect or modify the OperatorGroup for a namespace in OpenShift 4.14. Which TWO characteristics or settings are defined by an OperatorGroup? (Choose TWO)

Accepted Answer

The target namespaces (targetNamespaces) where Operators in the group can manage workloads.. Option B is correct because an OperatorGroup's primary purpose is to define the targetNamespaces field, which specifies the set of namespaces that the Operators in the group are allowed to watch and manage; this is central to how OLM scopes an Operator's permissions. Option E is correct because the OperatorGroup also determines the namespace scope (SingleNamespace, MultiNamespace, or AllNamespaces) and drives the generation of the RBAC (Roles, RoleBindings, ClusterRoles, ClusterRoleBindings) that OLM creates for the subscriptions and CSVs in that group. Options A, C, and D are incorrect because kernel versions, upgrade channels/target releases, and cloud instance types are MachineConfig, ClusterVersion, and MachineSet concerns respectively, not OperatorGroup settings.

Answer

The kernel version applied to worker nodes in the pool.

Answer

The cluster upgrade channel and target release version.

Answer

The cloud provider machine instance type (e.g., m5.xlarge).

Question 4

An administrator is preparing an OpenShift Container Platform 4.14 cluster for a controlled upgrade during a maintenance window. The administrator wants the Cluster Version Operator to stop automatically applying new updates after the desired version is reached, but still allow the administrator to manually trigger future upgrades. Which action should the administrator take?

Accepted Answer

Patch the ClusterVersion resource to set spec.desiredUpdate to the current version and set the update policy to manual.. To stop the Cluster Version Operator from applying updates automatically while preserving the ability to upgrade later, the administrator should pin the desired version in the ClusterVersion resource and configure the update policy for manual approval. This keeps the cluster on the current release until an administrator explicitly changes the desired update, which fits a controlled maintenance-window upgrade process.

Answer

Set spec.channel to stable-4.14 and leave spec.upstream unchanged.

Answer

Patch the ClusterVersion resource to add spec.desiredUpdate with the current version and set spec.channel to an invalid placeholder.

Answer

Patch the ClusterVersion resource to set spec.desiredUpdate to the current version and add an overrides entry that blocks the CVO.

Question 5

An administrator is preparing to install an OpenShift Container Platform 4.14 cluster on bare metal. The administrator wants to create an ignition config that embeds a custom MachineConfig for configuring a chrony time server on all nodes. Which command should the administrator use to generate the ignition config?

Accepted Answer

openshift-install create ignition-configs --dir=install-dir. The correct command is 'openshift-install create ignition-configs', which produces the ignition files required to boot nodes in a user-provisioned infrastructure (UPI) installation. This step is essential on bare metal because the administrator must then use these files with coreos-installer to install Red Hat Enterprise Linux CoreOS on each node. The other commands serve different stages of the installation workflow.

Answer

openshift-install create cluster --dir=install-dir

Answer

openshift-install create config --dir=install-dir

Answer

openshift-install create manifests --dir=install-dir

Question 6

An administrator has a running OpenShift Container Platform 4.14 cluster and wants to add three new worker nodes to an existing MachineSet. After running `oc scale machineset <machineset-name> --replicas=5` in the `openshift-machine-api` namespace, the administrator notices that two new Machines are created but the corresponding nodes do not appear in `oc get nodes` after several minutes. Which command should the administrator run FIRST to investigate why the new nodes are not joining the cluster?

Accepted Answer

oc get machines -n openshift-machine-api -o wide. When a MachineSet is scaled, it creates Machine objects that represent the desired nodes. If those Machines fail to provision (for example, due to cloud quota limits or invalid instance types), the nodes will never appear. Listing the Machines with `oc get machines -n openshift-machine-api -o wide` immediately shows their state and any error conditions. This is the first step to determine whether the issue is in provisioning or in the node joining process.

Answer

oc get clusteroperators

Answer

oc describe machineset <machineset-name> -n openshift-machine-api

Answer

oc get nodes -o wide

Question 7

An administrator is planning to install an OpenShift Container Platform 4.14 cluster on AWS using the installer-provisioned infrastructure (IPI) method. The administrator needs to ensure that the cluster can automatically scale worker nodes based on demand. Which OpenShift component should the administrator configure to enable automatic scaling?

Accepted Answer

ClusterAutoscaler. ClusterAutoscaler is responsible for automatically scaling the cluster's worker nodes up or down based on workload requirements. It monitors for unschedulable pods and, when necessary, increases the replica count of targeted MachineSets through MachineAutoscaler resources. Conversely, it can remove underutilized nodes to reduce costs. The other options are either components that are scaled or are unrelated to autoscaling.

Answer

MachineAutoscaler

Answer

MachineConfigPool

Answer

MachineSet

Question 8

An administrator is managing an OpenShift Container Platform 4.14 cluster and needs to add a new worker node to an existing MachineSet. The administrator has created a new Machine object with the appropriate provider specification. What is the next step to ensure the MachineSet recognizes and manages this new Machine?

Accepted Answer

Add the Machine to the MachineSet's selector labels.. A MachineSet manages Machines based on label selectors. To have an existing MachineSet manage a manually created Machine, the administrator must ensure the Machine has the labels that match the MachineSet's selector. The MachineSet will then automatically adopt the Machine and include it in its replica count. The other options do not achieve the desired integration.

Answer

Create a new MachineSet that includes the new Machine's specifications.

Answer

Update the MachineSet's replicas field to include the new Machine.

Answer

Set the Machine's ownerReference to point to the MachineSet.

Question 9

An administrator is managing an OpenShift Container Platform 4.14 cluster that uses the `vSphere` platform. The administrator needs to add a new worker node by scaling up a MachineSet. After scaling, the new Machine is created but the node fails to join the cluster. The administrator suspects that the node's ignition configuration or network settings are incorrect. Which command should the administrator use to retrieve the console output of the new node to diagnose the boot failure?

Accepted Answer

oc get machine <machine-name> -n openshift-machine-api -o jsonpath='{.status.providerStatus}'. When a node fails to join, the Machine resource's providerStatus can contain platform-specific information. For vSphere, this includes the VM's IP address and other details that allow the administrator to connect to the vSphere console and view the boot sequence. This is crucial for diagnosing ignition failures or network misconfigurations. Other commands either require the node to be running or do not provide console output.

Answer

oc debug node/<node-name>

Answer

oc get node <node-name> -o yaml

Answer

oc get machine <machine-name> -n openshift-machine-api -o yaml

Question 10

An administrator is configuring a new OpenShift Container Platform 4.14 cluster and wants to ensure that etcd is properly backed up. The administrator plans to use the cluster-etcd-operator to perform backups. Which resource must be created to configure automatic etcd backups?

Accepted Answer

An EtcdBackup custom resource in the openshift-etcd-operator namespace.. The EtcdBackup custom resource is the correct way to configure automatic etcd backups in OpenShift 4.14. It is managed by the cluster-etcd-operator and allows administrators to define backup schedules and storage locations. This resource ensures that backups are performed consistently and can be restored if needed. The other options are either unsupported or incorrect resources.

Answer

A CronJob in the openshift-etcd namespace that runs the etcd backup script.

Answer

A MachineConfig that runs a systemd timer to execute the etcd backup command.

Answer

A Backup custom resource in the openshift-config namespace.

Question 11

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

Accepted Answer

Cluster Version Operator (CVO). 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.

Answer

Machine Config Operator (MCO)

Answer

Cluster Infrastructure Operator (CIO)

Answer

Operator Lifecycle Manager (OLM)

Question 12

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?

Accepted Answer

The MachineConfig object lacks the correct labels required to associate it with the target MachineConfigPool.. 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.

Answer

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

Answer

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

Answer

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

Question 13

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?

Accepted Answer

Patch the worker MachineConfigPool to set 'spec.paused: true'.. 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.

Answer

Delete all pending MachineConfig objects from the cluster.

Answer

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

Answer

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

Question 14

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?

Accepted Answer

Set 'spec.installPlanApproval: Automatic'. 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.

Answer

Set 'spec.channel.autoApprove: yes'

Answer

Set 'spec.autoUpgrade: true'

Answer

Set 'spec.approvalStrategy: Immediate'

Question 15

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?

Accepted Answer

Run 'oc adm cordon worker-01' followed by 'oc adm drain worker-01 --delete-emptydir-data --ignore-daemonsets'.. 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.

Answer

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

Answer

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

Answer

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