EX280 Practice Questions 2 — 50 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

Question 11

An OpenShift cluster integrates with an LDAP server where user attribute names differ from default settings (e.g., mail instead of preferredUsername). Where are these LDAP attribute mappings configured?

Accepted Answer

In the LDAP identity provider specification under the 'attributes' mapping fields. LDAP attribute mappings are configured in the LDAP identity provider specification under the `attributes` field. This section maps LDAP attributes (e.g., mail, uid) to OpenShift identity attributes like preferredUsername, name, and email. Administrators edit the OAuth custom resource to set these mappings.

Answer

In the kube-apiserver ConfigMap under LDAP settings

Answer

In the GroupSync CRD resource settings

Answer

In the project request template annotations

Question 12

An administrator wants to verify which CSI driver plugins are registered and active in an OpenShift cluster. Which cluster-scoped resource should they query?

Accepted Answer

csidrivers.storage.k8s.io. The cluster-scoped resource that lists registered CSI drivers is csidrivers.storage.k8s.io. This resource represents the CSI drivers that are registered with the Kubernetes cluster and provides information about their capabilities, such as whether they support attach/detach operations. Querying this resource shows which CSI drivers are active and available for use.

Answer

volumesnapshotclasses.snapshot.storage.k8s.io

Answer

storageclasses.storage.k8s.io

Answer

csinodes.storage.k8s.io

Question 13

Which YAML key in a StorageClass definition specifies the CSI plugin responsible for provisioning the storage?

Accepted Answer

provisioner. The provisioner field in a StorageClass identifies the CSI driver (or in-tree provisioner) responsible for dynamically provisioning PersistentVolumes. For CSI-based storage, its value is the driver name registered by the CSI plugin, such as ebs.csi.aws.com or csi.ceph.com. Without a valid provisioner, the StorageClass cannot create PVs.

Answer

storagePlugin

Answer

plugin

Answer

driverName

Question 14

An ImageStream named 'frontend' in a project contains multiple tags, including 'latest' and 'v1.0'. You want to update an existing Deployment to specifically use the 'v1.0' tag of this ImageStream. Where must this reference be updated in the Deployment specification?

Accepted Answer

In the spec.template.spec.containers[].image field pointing to image-registry.openshift-image-registry.svc:5000/namespace/frontend:v1.0.. In OpenShift, an ImageStream tag is consumed by referencing the internal registry image path in the container's image field. The correct form is image-registry.openshift-image-registry.svc:5000//:, which the kubelet resolves through the internal registry and the ImageStream tag. Updating spec.template.spec.containers[].image to this fully qualified reference with the v1.0 tag ensures the Deployment pulls that specific tag.

Answer

In the spec.imageStreamRef field.

Answer

In the metadata.annotations['openshift.io/image.in-cluster'] field.

Answer

In the spec.strategy.rollingUpdate.image field.

Question 15

An administrator wants to check the cluster-wide resource consumption of nodes (CPU and Memory percentages). Which command provides this tabular overview?

Accepted Answer

oc adm top nodes. 'oc adm top nodes' is the OpenShift CLI command that queries the metrics subsystem and returns a tabular view of each node's CPU and memory consumption as a percentage of capacity. It is the node-level analog of 'oc adm top pods' and is the standard way to get a cluster-wide resource overview from the command line.

Answer

oc get nodes --metrics

Answer

oc cluster-capacity

Answer

oc describe nodes --usage

Question 16

You are configuring an OAuth identity provider using 'htpasswd'. Which secret must contain the file?

Accepted Answer

A secret in 'openshift-config'. When configuring an OAuth identity provider using htpasswd in OpenShift, the htpasswd file must be stored in a Secret in the 'openshift-config' namespace. The OAuth configuration references this secret by name, and the OpenShift authentication operator mounts it into the OAuth pods. This is the documented and required location for identity provider secrets.

Answer

A ConfigMap in 'openshift-config'

Answer

A local file on the master node

Answer

A secret in 'openshift-authentication'

Question 17

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?

Accepted Answer

A Secret named 'pull-secret' in the 'openshift-config' namespace.. 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.

Answer

The MachineConfigPool resource named 'worker'.

Answer

The ClusterVersion custom resource spec field 'pullSecret'.

Answer

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

Question 18

An administrator needs to restrict pod creation based on Pod Security Standards namespaces. Which TWO of the following are valid Pod Security Standard levels defined by Kubernetes and supported in OpenShift? (Choose TWO)

Accepted Answer

restricted. Option B (restricted) is correct because the Kubernetes Pod Security Standards define exactly three levels — privileged, baseline, and restricted — and restricted is the most stringent, enforcing hardening such as requiring non-root execution, dropping all capabilities, and disallowing hostPath/host namespaces. Option C (baseline) is correct because it is the minimally restrictive level that still blocks known privilege escalations (e.g., hostNetwork, hostPID, privileged containers) while allowing default pod configurations. OpenShift supports these levels via namespace labels such as pod-security.kubernetes.io/enforce=baseline or restricted, which is how an administrator restricts pod creation per namespace. Options A (hardened), D (secured), and E (isolated) are not valid Pod Security Standard levels defined by Kubernetes; they are not recognized values for the pod-security.kubernetes.io/enforce label and therefore would not restrict pod creation as intended.

Answer

hardened

Answer

secured

Answer

isolated

Question 19

An administrator needs to configure an authentication mechanism where users logging into the OpenShift web console are authenticated via an external corporate directory using LDAP. Which resource object should the administrator configure?

Accepted Answer

The cluster OAuth custom resource named cluster. In OpenShift, the cluster OAuth custom resource named `cluster` is the central configuration point for identity providers, including LDAP. Administrators configure the `spec.identityProviders` field to add an LDAP identity provider, specifying connection details, bind credentials, and attribute mappings. This resource is cluster-scoped and resides in the `openshift-config` namespace, and changes trigger a redeployment of the OAuth server pods.

Answer

A Secret named identity-provider in the openshift-authentication namespace

Answer

An Authentication custom resource named cluster in the kube-system namespace

Answer

A ConfigMap named ldap-config in the openshift-config namespace

Question 20

An OpenShift administrator needs to restrict external access to a specific application Route by limiting access to a predefined list of allowed client IP addresses. How can this be accomplished?

Accepted Answer

Add the annotation 'haproxy.router.openshift.io/ip_whitelist' to the Route object.. The annotation 'haproxy.router.openshift.io/ip_whitelist' on a Route object instructs the HAProxy router to allow only the specified client IP addresses (or CIDR ranges) to access that route. This is the standard OpenShift method for per-route IP whitelisting without affecting other routes or the entire router. The annotation is processed by the router's HAProxy configuration, which adds ACL rules to enforce the whitelist.

Answer

Configure spec.clientIP in the Service object definition.

Answer

Create a NetworkPolicy with spec.ingress.ipBlock restricting the router pod.

Answer

Update the IngressController CR with a global clientIP blacklist.