EX280 Practice Test 6 — 10 Questions

Question 1

Which TWO components are core parts of the OpenShift DNS architecture for cluster resolution? (Choose TWO)

Accepted Answer

CoreDNS. CoreDNS (A) is correct because OpenShift uses CoreDNS as the actual DNS server that runs in the cluster and resolves names for services, pods, and internal cluster resources. The Cluster DNS Operator (B) is correct because it is the OpenShift operator responsible for deploying, configuring, and managing the CoreDNS instances and their DNS configuration across the cluster. BIND9 (C) is not part of the core OpenShift DNS architecture; it is a general-purpose DNS server not used as the cluster's internal resolver. HAProxy DNS module (D) is incorrect because HAProxy is used for routing/load balancing, not as a core DNS resolution component in OpenShift. Keepalived DNS plugin (E) is incorrect because Keepalived provides VRRP-based high availability and is not a DNS resolution component of OpenShift.

Answer

BIND9

Answer

HAProxy DNS module

Answer

Keepalived DNS plugin

Question 2

An administrator wants to test network connectivity from a pod named 'app-pod-1' to a service port on 'backend-service' using TCP. Which tool is commonly available and ideal for testing TCP port connectivity inside a container?

Accepted Answer

nc. 'nc' (netcat) is the standard tool for testing TCP/UDP port connectivity from inside a container because it can open a raw TCP connection to a specific host and port, e.g., 'nc -zv backend-service 8080'. It is included in many base images and is the go-to utility for verifying that a Service port is reachable and that network policies or firewalls are not blocking traffic.

Answer

ifconfig

Answer

traceroute

Answer

ping

Question 3

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 4

An administrator needs to test DNS resolution from inside a running pod. Which command run inside a container uses the standard Linux DNS lookup utility?

Accepted Answer

nslookup backend.production.svc.cluster.local. nslookup is the standard Linux DNS lookup utility and can be run inside a container to query DNS resolution for a service FQDN such as backend.production.svc.cluster.local. Running it inside the pod tests the actual DNS path the application would use, including the cluster DNS service and any search domain configuration. This directly answers the requirement to test DNS resolution from inside a running pod.

Answer

route lookup backend

Answer

oc get dns

Answer

ping -dns backend.production.svc.cluster.local

Question 5

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

Accepted Answer

Machine API Operator. 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.

Answer

Operator Lifecycle Manager

Answer

Machine Config Operator

Answer

Cluster Version Operator

Question 6

During an S2I build, an administrator needs to pass sensitive build arguments, such as subscription keys, without hardcoding them into the BuildConfig or exposing them in the final image history. How should this be handled?

Accepted Answer

Using build secrets mounted via the source secret or build strategy configuration. Build secrets in OpenShift are designed specifically for passing sensitive data like subscription keys, tokens, or credentials into an S2I build without embedding them in the BuildConfig or leaving them in the final image layers. When configured via the source secret (e.g., `sourceSecret` in the BuildConfig) or through the build strategy's `secrets` field, the secret is mounted into the build pod's filesystem at a temporary location and is not committed to the resulting image. This ensures the sensitive data is available only during the build process and is discarded afterward, satisfying both security and compliance requirements.

Answer

Storing them in an ImageStream annotation

Answer

Defining them as plain environment variables in the BuildConfig spec

Answer

Injecting them via the Route host header

Question 7

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?

Accepted Answer

Edit the CRD definition and remove any lingering finalizers in 'metadata.finalizers' to allow deletion.. 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.

Answer

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

Answer

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

Answer

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

Question 8

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

Accepted Answer

openshift-machine-config-operator. 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.

Answer

openshift-infra

Answer

openshift-machine-api

Answer

openshift-cluster-version

Question 9

Which command allows an administrator to view details, including events and current binding status, of a specific PersistentVolume named 'pv-data01'?

Accepted Answer

oc describe pv pv-data01. The 'oc describe pv pv-data01' command retrieves detailed information about the PersistentVolume, including its status, capacity, access modes, reclaim policy, and associated events, which is exactly what the administrator needs. The describe subcommand aggregates the object's spec, status, and recent events into a human-readable format.

Answer

oc status pv-data01

Answer

oc get pv pv-data01 -o yaml

Answer

oc logs pv/pv-data01

Question 10

Which TWO volume types are considered ephemeral storage patterns native to Kubernetes and OpenShift?

Accepted Answer

Generic ephemeral inline volumes. Generic ephemeral inline volumes (A) are a native Kubernetes ephemeral storage pattern: they are declared inline in the pod spec via the ephemeral.volumeClaimTemplate field, and the lifecycle of the generated PVC is tied to the pod, so the storage is created and deleted with the pod. emptyDir (D) is the classic native ephemeral volume type, created when a pod is assigned to a node and deleted permanently when the pod is removed, which is exactly the definition of ephemeral storage in Kubernetes/OpenShift. NFS network shares (B) are persistent external storage, not an ephemeral pattern, and they survive pod deletion. PersistentVolumeClaim (C) represents durable, independently managed storage whose lifecycle is decoupled from the pod, so it is not ephemeral. AWS EBS volumes (E) are persistent block storage (via the aws-ebs CSI driver) that outlives the pod and is not a native ephemeral pattern.

Answer

NFS network shares

Answer

PersistentVolumeClaim

Answer

AWS EBS volumes