EX280 Cluster Installation And Management — Timed 50 Questions

Question 1

An administrator needs to modify the SSH key used for debugging worker nodes across an OpenShift 4.14 cluster. Which resource type should the administrator edit or create to apply this change cluster-wide to all worker nodes?

50 minute time limit — choose an answer to begin.

Accepted Answer

Create or modify a MachineConfig object that targets the worker role and specifies the sshKey field.. In OpenShift 4.x, node-level configuration such as SSH keys for debugging is managed declaratively through MachineConfig objects applied by the Machine Config Operator. Creating or modifying a MachineConfig that targets the `worker` role and sets the `sshKey` field in `spec.config.passwd.users` propagates the key to all worker nodes cluster-wide. The MCO then rolls out the change node by node.

Answer

Modify the ClusterVersion custom resource spec field.

Answer

Edit the kubelet configuration map in the kube-system namespace.

Answer

Update the authentication.config.openshift.io cluster operator resource.

Question 2

During an upgrade of an OpenShift 4.14 cluster using the Cluster Version Operator (CVO), the upgrade status stalls at a specific component. The administrator wants to check the detailed error messages and reconciling loops of the CVO itself. Where should the administrator look?

Accepted Answer

Review the logs of the cluster-version-operator deployment in the openshift-cluster-version namespace.. The Cluster Version Operator runs as a Deployment named 'cluster-version-operator' in the 'openshift-cluster-version' namespace, and its pod logs contain the detailed reconciliation loops, errors, and status messages for the upgrade. Checking these logs is the correct way to see why the CVO is stalled on a particular component.

Answer

Inspect the clusteroperators object using 'oc describe clusteroperator base-os'.

Answer

Check the cluster-wide events in the default namespace using 'oc get events'.

Answer

Inspect the MachineConfigPool status in the openshift-machine-api namespace.

Question 3

Which OpenShift 4.14 operator provides a catalog of certified third-party and Red Hat operators available for cluster installation?

Accepted Answer

OperatorHub / Cluster Catalog Operator. OperatorHub is the OpenShift feature (backed by the Cluster Catalog Operator / Marketplace Operator) that provides a catalog of certified Red Hat, ISV, and community operators for installation. It surfaces operators from default catalog sources like 'redhat-operators', 'certified-operators', and 'community-operators', and is accessible via the web console or 'oc get packagemanifests'.

Answer

Console Operator

Answer

Machine API Operator

Answer

Cluster Version Operator

Question 4

When draining a worker node in OpenShift 4.14, which type of pod running on the node will typically be blocked from eviction unless explicitly ignored or handled?

Accepted Answer

Pods not backed by a controller (naked pods). Pods not backed by a controller (naked pods) are not managed by a ReplicaSet, Deployment, or similar controller, so when a node is drained, they cannot be rescheduled elsewhere and will be blocked from eviction unless explicitly ignored with --force or --delete-emptydir-data. This is because draining aims to gracefully evict pods that can be rescheduled, but naked pods would be lost.

Answer

Static pods

Answer

StatefulSet pods

Answer

DaemonSet pods

Question 5

An administrator wants to add a custom CA certificate trust bundle to all worker nodes in an OpenShift 4.14 cluster so that internal container registries can be accessed securely. Which object should the administrator configure?

Accepted Answer

Create a ConfigMap in openshift-config containing the CA certificate and reference it in the cluster image configuration (imageregistry.config.openshift.io).. To add a custom CA trust bundle cluster-wide, administrators create a ConfigMap in the 'openshift-config' namespace containing the CA certificate and reference it in the cluster-wide image configuration (spec.additionalTrustedCA of the 'cluster' Image config object). This causes the Machine Config Operator to roll out the CA to all nodes and updates the trust bundle used by the container runtime and image pulls.

Answer

Modify the kube-dns ConfigMap to trust external TLS certificates.

Answer

Update the OAuth custom resource with the CA bundle path.

Answer

Restart the cluster proxy service with the '--ca-file' parameter.

Question 6

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

Accepted Answer

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

Answer

Placing the MachineConfig object directly inside the GPU namespace.

Answer

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

Answer

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

Question 7

An administrator needs to perform an offline (disconnected) upgrade of an OpenShift 4.14 cluster where nodes have no direct internet access. Which resource must be configured in the cluster to supply the release payload images from a local mirror registry?

Accepted Answer

ImageContentSourcePolicy (or ImageTagMirrorSet). In a disconnected OpenShift 4.x environment, the ImageContentSourcePolicy (ICSP) — or its newer replacement, ImageTagMirrorSet/ImageDigestMirrorSet — is the cluster-wide resource that tells CRI-O to redirect image pull requests from the original registry (e.g., quay.io/openshift-release-dev) to the local mirror registry. Without this redirection, the ClusterVersionOperator and MachineConfigOperator cannot pull the release payload or operator images, so the upgrade stalls. The ICSP is applied via 'oc apply' and triggers a rolling reboot of nodes as the MachineConfigPool absorbs the new registries.conf entries.

Answer

ClusterVersion mirror override parameter

Answer

MachineConfig registry redirection file

Answer

OperatorGroup mirror setting

Question 8

An administrator wants to perform a manual rollback of a MachineConfig change that caused issues on worker nodes. What is the standard way to revert to the previous configuration using the Machine Config Operator?

Accepted Answer

Delete the problematic MachineConfig object, causing the MCO to automatically roll back nodes to the previous configuration.. In OpenShift 4, MachineConfigs are additive and immutable — the MCO renders the desired state from the set of MachineConfigs matching a pool. Deleting the problematic MachineConfig removes it from the rendered set, so the MCO generates a new rendered config that matches the prior state and rolls nodes back to it. This is the documented manual rollback approach when a MachineConfig change breaks nodes.

Answer

Reboot each worker node into the previous GRUB menu entry manually via IPMI.

Answer

Run 'oc rollback machineconfigpool worker'.

Answer

Run 'oc adm node-rollback --pool=worker'.

Question 9

An administrator wants to temporarily disable a MachineHealthCheck so that node maintenance can be performed without triggering automated node deletion. How should this be done?

Accepted Answer

Delete the MachineHealthCheck custom resource during the maintenance window and recreate it afterward.. The MachineHealthCheck (MHC) custom resource is the object that defines which nodes are monitored and what remediation actions are taken. Deleting the MHC custom resource removes the health check entirely, so the machine-api-operator no longer watches those nodes and will not trigger automated node deletion during maintenance. Recreating the MHC afterward restores the original health-check behavior. This is the documented, supported way to temporarily disable an MHC in OpenShift.

Answer

Set the MachineHealthCheck replica count to zero.

Answer

Stop the machine-api-operator deployment.

Answer

Annotate every node with 'machinehealthcheck.openshift.io/enabled=false'.

Question 10

An administrator is managing an OpenShift 4.14 cluster and notices that a newly installed Operator fails to start because it requires a specific version of Kubernetes that is older than what OpenShift 4.14 provides. How does OLM handle Operator compatibility checks during subscription creation?

Accepted Answer

OLM evaluates the ClusterServiceVersion (CSV) metadata against the cluster version and blocks installation if requirements are unmet.. OLM (Operator Lifecycle Manager) performs compatibility checks by reading the ClusterServiceVersion (CSV) metadata, which includes fields like `spec.minKubeVersion` and `spec.version`. During subscription creation, OLM compares these requirements against the cluster's Kubernetes version (reported by the Cluster Version Operator). If the CSV specifies a minimum Kubernetes version that is higher than the cluster's current version, or if other constraints are unmet, OLM blocks the installation and the operator remains in a failed or pending state. This prevents incompatible operators from being deployed and potentially causing cluster instability.

Answer

The kube-apiserver automatically patches the operator deployment to bypass version checks.

Answer

The operator runs inside a compatibility emulation container provided by the MCO.

Answer

The Cluster Version Operator automatically downgrades the cluster Kubernetes API to match the Operator.

Question 11

An administrator is troubleshooting an Operator installed via OperatorHub whose pods are failing to pull images because the Operator's subscription namespace lacks access to the global pull secret. How can the administrator configure OLM to use a custom pull secret for an Operator in a specific namespace?

Accepted Answer

Add the image pull secret to the ServiceAccount used by the Operator deployment in the target namespace.. To allow an Operator in a specific namespace to use a custom pull secret, the administrator should add the image pull secret to the ServiceAccount used by the Operator deployment in that namespace. This ensures that the pods created by the Operator can pull images from private registries using the provided credentials.

Answer

Modify the global ClusterVersion resource with the namespace-specific pull secret.

Answer

Edit the CatalogSource resource to inject credentials into the CSV.

Answer

Annotate the OperatorGroup with 'olm.openshift.io/pull-secret=true'.

Question 12

An administrator has successfully updated the global pull secret in openshift-config/pull-secret. How does the Machine Config Operator propagate this new pull secret to all existing worker nodes in the cluster?

Accepted Answer

The MCO automatically detects the secret change, generates a new rendered MachineConfig, and rolls out the update to nodes.. The Machine Config Operator (MCO) watches the openshift-config/pull-secret Secret as part of its managed configuration. When the global pull secret is updated, the MCO merges it into the rendered MachineConfig for each pool, generating a new rendered config that includes the updated /var/lib/kubelet/config.json. The MCO then triggers a rolling update of the affected nodes, cordoning and draining each node before applying the new config and rebooting if necessary. This ensures all existing worker nodes receive the new pull secret without manual intervention.

Answer

Pull secrets cannot be updated on existing nodes; nodes must be destroyed and recreated.

Answer

The Cluster Version Operator requires a manual cluster reboot command to push secrets.

Answer

The administrator must manually SSH into each worker node and run 'oc-update-pull-secret'.

Question 13

An administrator is configuring Operator subscriptions in OpenShift 4.14 using OLM. Which THREE parameters can be configured within a Subscription custom resource? (Choose THREE)

Accepted Answer

name. Option B (name) is correct because the Subscription CR's metadata.name field is the required identifier that OLM uses to track and manage the subscription, and it must be a valid DNS-1123 subdomain name. Option D (installPlanApproval) is correct because this spec field controls whether InstallPlans are applied automatically (Automatic) or require manual approval (Manual), which is a core configurable parameter of a Subscription. Option E (channel) is correct because spec.channel specifies the update channel (for example, stable or fast) from which the operator's package and upgrades are sourced. Options A (kubeletConfigSelector) and C (machineConfigPoolSelector) are not Subscription parameters; those selectors belong to MachineConfigPool and KubeletConfig resources used by the Machine Config Operator, not to OLM Subscription custom resources.

Answer

kubeletConfigSelector

Answer

machineConfigPoolSelector

Question 14

An administrator is configuring a disconnected (air-gapped) OpenShift 4.14 cluster installation. Which THREE components or resources are critical for successfully managing container image mirroring and catalog sources in this environment? (Choose THREE)

Accepted Answer

ImageContentSourcePolicy (or ImageTagMirrorSet). In a disconnected OpenShift 4.14 installation, image mirroring and catalog management depend on three key resources. Option B, ImageContentSourcePolicy (or its successor ImageTagMirrorSet), is correct because it rewrites image pull references so that the cluster fetches mirrored images from the local registry instead of the upstream registries. Option D, a local container registry mirror containing mirrored release and operator payloads, is correct because the air-gapped environment has no internet access, so all release images and operator bundles must be hosted internally. Option E, a CatalogSource pointing to the local index image, is correct because OLM uses the CatalogSource to discover and install operators from the mirrored index rather than from the default Red Hat catalog. Option A does not belong because OperatorGroup namespace restrictions govern operator tenancy and target namespace selection, not image mirroring. Option C does not belong because MachineHealthCheck remediation timeouts relate to node health remediation, which is unrelated to mirroring or catalog sources.

Answer

OperatorGroup namespace restriction rules

Answer

MachineHealthCheck remediation timeout settings

Question 15

Which TWO objects are used by OLM to manage Operator catalogs and sources of software in OpenShift 4.14? (Choose TWO)

Accepted Answer

OperatorGroup. CatalogSource (E) is correct because it defines a source of Operator packages and metadata that OLM queries to discover available Operators, pointing to an index image (e.g., via an image reference) that OLM uses to resolve installable content. OperatorGroup (C) is correct because it configures the namespaces an Operator watches and generates the required RBAC and target namespace scope for OLM-managed Operators, making it a core OLM object used alongside catalogs. ClusterVersion (A) is incorrect because it is managed by the Cluster Version Operator to track OpenShift cluster version and update status, not Operator catalog/software sources. MachineSet (B) is incorrect because it belongs to the Machine API for managing compute machine replicas, unrelated to OLM catalog management. MachineConfigPool (D) is incorrect because it is used by the Machine Config Operator to group nodes for configuration rollout, not for Operator catalog or software source management.

Answer

ClusterVersion

Answer

MachineSet

Answer

MachineConfigPool

Question 16

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 17

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 18

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 19

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 20

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