EX280 Storage And Persistent Volumes Practice Test 5 — 15 Questions

Question 1

An administrator needs to prune or reclaim dangling VolumeSnapshotContent objects whose parent VolumeSnapshots have already been deleted, but the reclaim policy was set incorrectly. How can this be resolved?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Manually delete the orphaned VolumeSnapshotContent object or remove its finalizers if stuck.. Orphaned VolumeSnapshotContent objects left behind when their parent VolumeSnapshot is deleted (due to a misconfigured deletionPolicy of Retain instead of Delete) must be cleaned up manually. You delete the VolumeSnapshotContent object directly, or if it is stuck due to finalizers, remove the finalizers (e.g., snapshot.storage.kubernetes.io/volumesnapshotcontent-bound-protection) and then delete it.

Answer

Recreate the deleted VolumeSnapshot with the exact same UID.

Answer

Restart the snapshot-controller deployment.

Answer

Run 'oc prune snapshots --force'.

Question 2

Which THREE actions are required when manually setting up a pre-provisioned PersistentVolume backed by an existing storage asset?

Accepted Answer

Specify spec.accessModes to match expected claim requirements.. When manually creating a pre-provisioned PersistentVolume, you must define the storage capacity in spec.capacity.storage (option D) so the PV advertises the correct size that a PVC can request and bind to. You must also set spec.accessModes (option B) such as ReadWriteOnce, ReadOnlyMany, or ReadWriteMany so the PV's supported modes match the PVC's requested access mode for binding. Finally, you must provide the volume source configuration (option C), e.g., csi with driver/volumeHandle or nfs with server/path, because this tells Kubernetes which existing storage asset to attach and how to mount it. Option A is wrong because allowVolumeExpansion is a StorageClass field, not a per-namespace setting, and it is irrelevant to a manually created PV. Option E is wrong because VolumeSnapshotClass is only needed for snapshot operations, not for defining a pre-provisioned PV.

Answer

Set allowVolumeExpansion to false on all namespaces.

Answer

Create a matching VolumeSnapshotClass before defining the PV.

Question 3

A cluster administrator wants to restrict a specific storage class so that only members of a designated OpenShift project can create PVCs referencing it. How is this typically enforced in OpenShift?

Accepted Answer

Using admission control policies or validation webhooks to restrict StorageClass usage by namespace.. OpenShift does not natively support per-namespace StorageClass restrictions in the StorageClass spec itself, so enforcement is typically done through admission control — either a ValidatingAdmissionPolicy, a custom validating webhook, or OPA/Gatekeeper constraints that inspect PVC creation requests and reject those referencing a restricted StorageClass from unauthorised namespaces. This is the standard pattern for multi-tenant storage isolation.

Answer

By assigning RBAC RoleBindings to the StorageClass object directly.

Answer

By setting accessMode: Restricted in the StorageClass metadata.

Answer

By adding a namespaces array directly in the StorageClass spec.

Question 4

Which TWO of the following are valid volume modes supported by PersistentVolumes and PersistentVolumeClaims in OpenShift?

Accepted Answer

Block. In OpenShift/Kubernetes, the PersistentVolume spec.volumeMode field accepts exactly two values: Block and Filesystem. Option B (Block) is correct because a PV/PVC with volumeMode: Block exposes the volume as a raw block device with no filesystem, which is required for workloads like databases that manage their own storage layout. Option D (Filesystem) is correct because it is the default volumeMode, where the volume is formatted with a filesystem and mounted into a directory inside the pod. Options A (Object), C (Database), and E (Stream) are not valid volumeMode values — they are not recognized by the Kubernetes/OpenShift API for PersistentVolumes or PersistentVolumeClaims, so they would be rejected.

Answer

Object

Answer

Database

Answer

Stream

Question 5

Which THREE parameters or fields are valid when configuring a StorageClass object in OpenShift 4.14+?

Accepted Answer

provisioner. Option B (provisioner) is correct because every StorageClass must specify the provisioner field, which identifies the volume plugin (e.g., kubernetes.io/aws-ebs, ebs.csi.aws.com, or kubernetes.io/no-provisioner) used to dynamically provision PersistentVolumes. Option C (volumeBindingMode) is correct because it is a valid StorageClass field that controls when volume binding and dynamic provisioning occur, with supported values Immediate and WaitForFirstConsumer. Option E (reclaimPolicy) is correct because StorageClass supports the reclaimPolicy field to define the default PersistentVolume reclaim behavior for dynamically provisioned volumes, with valid values Delete and Retain. Option A (containerRuntime) is not a StorageClass parameter; it relates to container runtime configuration (e.g., CRI-O) and is not part of the storage.k8s.io/v1 StorageClass schema. Option D (nodeSelector) is not a StorageClass field; node selection for storage is handled via allowedTopologies or in PersistentVolume nodeAffinity, not a nodeSelector key on StorageClass.

Answer

containerRuntime

Answer

nodeSelector

Question 6

Which TWO methods can be used to populate data into a newly created PersistentVolumeClaim during provisioning?

Accepted Answer

Referencing an existing PersistentVolumeClaim in the PVC dataSource field for cloning.. Option C is correct because Kubernetes supports PVC cloning: a new PVC can specify an existing PVC in its spec.dataSource field (dataSource.kind: PersistentVolumeClaim), and the CSI driver then provisions the new volume with a copy of the source PVC's data. Option D is correct because a PVC can reference a VolumeSnapshot via spec.dataSource (dataSource.kind: VolumeSnapshot, apiGroup: snapshot.storage.k8s.io), which restores the snapshot's contents into the newly provisioned volume. Both mechanisms are standard ways to pre-populate a freshly created PVC at provisioning time. Option A is wrong because volumeMode only accepts Filesystem or Block and has nothing to do with populating data. Option B is wrong because PVC metadata cannot mount or pull from a container image registry. Option E is wrong because emptyDir is a pod-level ephemeral volume type and cannot be specified as a template inside a PVC spec.

Answer

Setting volumeMode to Populate in the PVC spec.

Answer

Mounting a container image registry directly via PVC metadata.

Answer

Specifying an emptyDir template in the PVC spec.

Question 7

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 8

Which TWO characteristics describe StorageClasses in OpenShift?

Accepted Answer

They specify the provisioner plugin responsible for creating volumes.. Option A is correct because a StorageClass defines the provisioner field (for example kubernetes.io/aws-ebs, ebs.csi.aws.com, or a custom CSI driver) that tells OpenShift which plugin dynamically creates the PersistentVolume backing a PVC. Option E is correct because StorageClasses are cluster-scoped resources, not namespaced, so they are visible across all projects and can be referenced by PVCs in any namespace. Options B, C, and D are incorrect: StorageClasses do not hold application data (that resides on the PersistentVolume), they are not namespace-scoped or project-unique, and creating them typically requires cluster-admin privileges rather than unprivileged developer access.

Answer

They store the actual application data files.

Answer

They are namespace-scoped and unique to each project.

Answer

They can only be created by unprivileged developer users.

Question 9

Which THREE items can be inspected using 'oc describe' when troubleshooting a failing storage attachment in OpenShift?

Accepted Answer

The PersistentVolumeClaim (to check binding status and provisioner errors). Option B is correct because 'oc describe pvc ' shows the PersistentVolumeClaim's status, bound volume, and provisioner-related events, which directly reveal binding failures or dynamic provisioning errors during a storage attachment problem. Option C is correct because 'oc describe pod ' surfaces scheduling decisions and volume mount events (such as FailedMount or FailedAttachVolume), pinpointing why a pod cannot attach or mount its storage. Option E is correct because 'oc describe pv ' reports the PersistentVolume's status, claim reference, reclaim policy, and node affinity/attachment details, helping verify whether the volume is available and attachable to the target node. Option A is not applicable because the cluster image registry configuration is inspected via registry operator resources or configs (for example 'oc get configs.imageregistry.operator.openshift.io'), not as a storage attachment object. Option D is not applicable because OAuth client credentials are stored in a Secret and relate to authentication, not to diagnosing storage attachment failures.

Answer

The cluster image registry configuration

Answer

The OAuth client credentials secret

Question 10

Which TWO conditions will prevent a pod from successfully mounting a PersistentVolumeClaim?

Accepted Answer

The PVC is in a Pending state because it failed to bind or provision.. Option B is correct because a PersistentVolumeClaim must be Bound before a pod can mount it; if the PVC remains Pending due to a binding or dynamic provisioning failure (e.g., no matching PV, missing StorageClass, or provisioner error), the kubelet cannot attach and mount the volume, so the pod stays in ContainerCreating. Option C is correct because a ReadWriteOnce (RWO) PersistentVolume can only be attached to a single node at a time; if the volume is already attached to another node, the new pod's mount fails with a Multi-Attach error until the volume is detached. Option A is wrong because running in the default namespace does not by itself prevent PVC mounting—namespaces only affect which PVCs/PVs are visible, and a valid PVC in the same namespace works fine. Option D is wrong because allowVolumeExpansion=true merely permits resizing a PVC after creation and has no negative effect on mounting. Option E is wrong because CPU limits are a scheduling/resource concern and do not block volume attach or mount operations.

Answer

The pod is running in the default project.

Answer

The StorageClass has allowVolumeExpansion set to true.

Answer

The pod namespace has excess CPU limits.

Question 11

Which THREE factors influence whether a pod requesting a storage volume can be successfully scheduled to a specific worker node when using topology-aware storage?

Accepted Answer

Volume accessibility constraints reported by the CSI driver. Option B is correct because topology-aware scheduling depends on the accessibility constraints the CSI driver reports through CSI topology keys (for example, via the CSINode object and CSIStorageCapacity), which tell the scheduler which nodes can actually reach the volume. Option D is correct because a StorageClass with volumeBindingMode: WaitForFirstConsumer delays PersistentVolume binding until the pod is scheduled, allowing the scheduler to co-locate the pod with the volume's topology instead of binding prematurely. Option E is correct because node topology labels such as topology.kubernetes.io/zone (or the older failure-domain.beta.kubernetes.io/zone) are the actual topology domains the scheduler matches against the volume's node affinity requirements. Option A is not relevant because OAuth token expiration affects API authentication, not volume topology or scheduling decisions. Option C is not relevant because the number of image layers affects image pull time and storage, not whether a topology-constrained volume can be scheduled to a node.

Answer

The cluster OAuth token expiration time

Answer

The number of container image layers in the pod spec

Question 12

An administrator needs to deploy a StorageClass that automatically provisions volumes only when a PersistentVolumeClaim is created and consumed by a Pod. Which StorageClass parameter determines this behavior?

Accepted Answer

volumeBindingMode: WaitForFirstConsumer. 'volumeBindingMode: WaitForFirstConsumer' in a StorageClass delays dynamic provisioning and PV binding until a Pod using the PVC is scheduled. This ensures the volume is created in the same topology zone/node as the Pod, which is essential for local storage and topology-constrained cloud volumes. 'Immediate' (the default) provisions as soon as the PVC is created, which can cause scheduling failures if the volume lands in an incompatible zone.

Answer

reclaimPolicy: Retain

Answer

provisioningMode: Immediate

Answer

allowVolumeExpansion: true

Question 13

An application running in OpenShift requires scratch space that lives and dies strictly with the Pod lifecycle, but needs to be mounted from a high-performance cluster-managed storage backend rather than local ephemeral node storage. Which feature should an administrator configure?

Accepted Answer

Generic ephemeral inline volumes via a volume template in the Pod specification. Generic ephemeral inline volumes allow a Pod to specify a volume template that dynamically provisions a PersistentVolumeClaim (PVC) for the Pod's lifetime. The resulting PVC and its backing PersistentVolume (PV) are automatically deleted when the Pod is deleted, satisfying the 'lives and dies with the Pod' requirement. Because the volume is backed by a cluster-managed StorageClass, it can use high-performance storage backends (e.g., NVMe, Ceph RBD) rather than local node storage. This is the only option that combines Pod-lifecycle-bound ephemeral semantics with cluster-managed persistent storage.

Answer

HostPath volumes mapped to a local directory on the worker node

Answer

A standard dynamically provisioned PVC with reclaimPolicy set to Delete

Answer

emptyDir with medium: Memory

Question 14

A cluster administrator has deleted a PersistentVolumeClaim, but the underlying PersistentVolume still exists in the cluster with a Released status and its data remains intact on the storage backend. What is the most likely cause of this behavior?

Accepted Answer

The persistentVolumeReclaimPolicy of the PersistentVolume was set to Retain.. When a PVC is deleted, the PersistentVolume's reclaim policy determines what happens to the underlying storage. If the PV's persistentVolumeReclaimPolicy is set to Retain, the PV transitions to Released status and the data on the backend is preserved; the PV must be manually reclaimed or deleted by an administrator. This exactly matches the described behavior.

Answer

The StorageClass associated with the PV has allowVolumeExpansion set to false.

Answer

The volume access mode was configured as ReadWriteMany instead of ReadWriteOnce.

Answer

The PVC was protected by a finalizer that prevented immediate deletion.

Question 15

An OpenShift administrator needs to allow users to expand the storage capacity of existing PersistentVolumeClaims without restarting their applications. Which action must be taken first to enable this capability?

Accepted Answer

Edit the StorageClass to set allowVolumeExpansion: true.. Online volume expansion in Kubernetes/OpenShift is gated by the StorageClass field allowVolumeExpansion. Until that field is set to true on the StorageClass backing the PVC, the API server will reject any attempt to increase the PVC's requested storage, so it must be enabled first.

Answer

Restart the csi-provisioner controller deployment in the openshift-cluster-storage-operator namespace.

Answer

Add the expansion-enabled annotation directly to each active Pod object.

Answer

Convert all existing static PersistentVolumes into dynamically provisioned volumes.