EX280 Storage And Persistent Volumes — 15 Questions

Question 1

A developer requests a PersistentVolumeClaim using ReadWriteMany access mode. Which default storage type in a standard AWS ODF (OpenShift Data Foundation) deployment natively supports RWX?

Accepted Answer

openshift-storage.cephfs.csi.ceph.com. The CephFS CSI driver (openshift-storage.cephfs.csi.ceph.com) is the only default storage class in an AWS OpenShift Data Foundation deployment that natively supports ReadWriteMany (RWX) access mode. CephFS is a POSIX-compliant shared filesystem that allows multiple pods on different nodes to mount and write to the same volume simultaneously. RBD (RADOS Block Device) and EBS are block storage, which only support ReadWriteOnce (RWO) or ReadOnlyMany (ROX), not RWX.

Answer

openshift-storage.rbd.csi.ceph.com

Answer

gp2-csi.storage.k8s.io

Answer

ebs.csi.aws.com

Question 2

A user creates a VolumeSnapshot and notices that the resulting VolumeSnapshotContent status is marked as readyToUse: false. What is the most likely cause?

Accepted Answer

The PVC being snapshotted has active writes and the storage backend is still synchronizing snapshot data.. A VolumeSnapshotContent reports readyToUse: false while the CSI driver is still completing the snapshot operation against the backend storage. If the source PVC has active writes, the storage system must quiesce or flush data before the snapshot can be marked consistent and ready, so the status remains false until synchronization finishes. Once the CSI CreateSnapshot call returns successfully, the controller flips readyToUse to true.

Answer

The VolumeSnapshot object must be manually promoted before it becomes ready.

Answer

The VolumeSnapshotClass is missing the deletionPolicy parameter.

Answer

The PVC must be unmounted from all running pods before a snapshot can be marked ready.

Question 3

An administrator needs to provision persistent storage dynamically using an NFS server. Which provisioner is required in the StorageClass definition since OpenShift removed the in-tree NFS provisioner?

Accepted Answer

sig-storage.k8s.io/nfs-subdir-external-provisioner. The correct provisioner is sig-storage.k8s.io/nfs-subdir-external-provisioner. OpenShift removed the in-tree NFS provisioner, so dynamic provisioning for NFS requires an external provisioner. The nfs-subdir-external-provisioner is a Kubernetes SIG-Storage project that creates subdirectories on an existing NFS server, and its provisioner name must be specified in the StorageClass as sig-storage.k8s.io/nfs-subdir-external-provisioner. This provisioner is deployed separately and watches for PersistentVolumeClaims that reference this StorageClass.

Answer

nfs.csi.k8s.io

Answer

kubernetes.io/nfs

Answer

openshift.io/nfs-dynamic

Question 4

You are creating a StorageClass and want to ensure that PersistentVolumes created by it are only deleted when the PVC is explicitly deleted, rather than retaining them. Which parameter should you set?

Accepted Answer

reclaimPolicy: Retain. The reclaimPolicy field in a StorageClass controls what happens to the underlying PV when its PVC is deleted. Setting it to Retain ensures data persistence.

Answer

deletionPolicy: Retain

Answer

persistentVolumeReclaimPolicy: Keep

Question 5

Which object acts as a cluster-scoped abstraction that defines and parameterizes the type of storage (such as provisioner, parameters, and reclaim policy) that can be dynamically provisioned in OpenShift?

Accepted Answer

VolumeSnapshotClass. A StorageClass defines the provisioner and parameters used to dynamically provision PersistentVolumes.

Answer

PersistentVolume

Answer

PersistentVolumeClaim

Question 6

You are troubleshooting a PVC that remains unbound. You run 'oc describe pvc my-pvc' and see that the storageClassName is set to a class that was recently deleted. What is the correct way to fix this?

Accepted Answer

Recreate the deleted StorageClass with the exact same name.. PVCs cannot have their storageClassName mutated once created. The correct procedure is to delete the PVC and recreate it referencing a valid, existing StorageClass.

Answer

Edit the PVC spec and change the storageClassName field to a valid class.

Answer

Annotate the PVC with 'storageclass.kubernetes.io/override'.

Question 7

A cluster administrator needs to prevent users from accidentally deleting a VolumeSnapshot while associated PVC restores or clones depend on it. What protection mechanism is active by default in OpenShift?

Accepted Answer

VolumeSnapshot Content Protection finalizers. OpenShift enables VolumeSnapshotContentProtection by default, which adds a finalizer (snapshot.storage.kubernetes.io/volumesnapshotcontent-protection) to VolumeSnapshotContent objects. This finalizer prevents deletion of the snapshot content while any VolumeSnapshot or dependent PVC restore/clone still references it. It is the snapshot equivalent of the PVC protection finalizer and requires no administrator action to activate.

Answer

OCP Storage Mutating Webhooks

Answer

etcd Object Lock

Answer

StorageClass Retain Policy

Question 8

What happens to a PersistentVolume configured with reclaimPolicy: Delete when its corresponding PersistentVolumeClaim is deleted?

Accepted Answer

The underlying storage asset is automatically deleted from the storage backend.. With reclaimPolicy: Delete, when the bound PVC is removed, the PV object is deleted and the CSI driver is instructed to delete the underlying storage asset on the backend. This is the default for dynamically provisioned volumes in most cloud and CSI StorageClasses, ensuring storage is not orphaned.

Answer

The PV object is deleted, but the underlying storage asset remains intact on the storage backend.

Answer

The PV is automatically archived into an object storage bucket.

Answer

The PV status changes to Released and waits for administrator intervention.

Question 9

A cluster administrator needs to ensure that a specific PVC can only bind to a pre-allocated PersistentVolume. How can this binding relationship be strictly enforced?

Accepted Answer

Specify the exact PV name in the spec.volumeName field of the PVC.. Specifying the exact PersistentVolume name in the PVC's spec.volumeName field creates a strict one-to-one binding between the PVC and that specific PV. This bypasses the normal dynamic provisioning and label-matching process and enforces the binding relationship directly. Other options do not enforce a strict binding to a pre-allocated PV.

Answer

Apply matching labels and set volumeBindingMode to Strict.

Answer

Set allowVolumeExpansion to false on the PV.

Answer

Annotate the PVC with 'volume.kubernetes.io/target-pv'.

Question 10

A developer needs to configure a Pod where multiple containers need concurrent read-write access to the exact same PersistentVolumeClaim. Which access mode is mandatory on the PVC?

Accepted Answer

ReadWriteMany. ReadWriteMany (RWX) is the only access mode that permits multiple pods (and therefore multiple containers across nodes) to mount the same PVC with read-write access concurrently. RWO and RWOP restrict write access to a single node or single pod respectively, so they cannot satisfy concurrent read-write from multiple containers. RWX requires a storage backend that supports shared filesystems (NFS, CephFS, GlusterFS, etc.).

Answer

ReadOnlyMany

Answer

ReadWriteOnce

Answer

ReadWriteOncePod

Question 11

A cluster uses a CSI driver that does not support volume expansion. A user edits an existing PVC to request a larger size. What action does the OpenShift API server take?

Accepted Answer

The resize request fails or is marked with an error condition because expansion is unsupported.. When a user edits a PVC to request a larger size, the API server validates the change against the StorageClass's allowVolumeExpansion field and the CSI driver's capabilities. If the driver does not support volume expansion (or allowVolumeExpansion is false), the resize request is rejected or the PVC is marked with a ResizeError/FileSystemResizePending condition indicating expansion is unsupported. The PVC's requested size is not silently accepted without backend action.

Answer

The PVC size is updated in Kubernetes metadata, but physical storage is left unchanged.

Answer

OpenShift automatically converts the PVC to use a default storage class that supports expansion.

Answer

The pod is immediately terminated and restarted on a node with more disk space.

Question 12

An administrator needs to configure volume snapshot data protection where the underlying snapshot content object must remain intact even if the user deletes the VolumeSnapshot object. How is this controlled?

Accepted Answer

Set reclaimPolicy to Retain in the StorageClass.. The deletionPolicy in the VolumeSnapshotClass controls whether the underlying VolumeSnapshotContent is deleted (Delete) or retained (Retain) when the user deletes the VolumeSnapshot.

Answer

Apply the annotation snapshot.storage.k8s.io/preservation: "true" on the PVC.

Answer

Set snapshotRetention: permanent in the VolumeSnapshot spec.

Question 13

Which TWO of the following statements regarding PersistentVolume access modes are correct?

Accepted Answer

ReadWriteOnce (RWO) permits a volume to be mounted as read-write by a single node.. Option B is correct because ReadWriteOnce (RWO) means the PersistentVolume can be mounted as read-write by a single node at a time, though multiple pods on that same node may still use it. Option E is correct because ReadWriteMany (RWX) allows the volume to be mounted as read-write by many nodes simultaneously, which is the defining characteristic of that access mode. Option A is wrong because RWO restricts access to a single node, not to pods on different nodes reading the volume; pods on the same node can still read it. Option C is wrong because access modes are requested by the PersistentVolumeClaim (PVC) via the accessModes field, not determined dynamically by the pod. Option D is wrong because ReadOnlyMany (ROM) allows multiple nodes to mount the volume read-only, not to write to it concurrently.

Answer

ReadWriteOnce (RWO) prevents pods on different nodes from reading the volume.

Answer

Access modes are determined dynamically by the pod and cannot be requested by the PVC.

Answer

ReadOnlyMany (ROM) allows multiple nodes to write to the volume concurrently.

Question 14

Which TWO conditions must be met for a PVC to successfully bind to a dynamically provisioned PersistentVolume?

Accepted Answer

The StorageClass name specified in the PVC must match the StorageClass of the provisioned PV.. The PVC and PV must match in storage class, requested size/access modes, and volume mode compatibility.

Answer

The PVC must belong to the kube-system namespace.

Question 15

Which THREE components are typically deployed as part of a CSI driver architecture on OpenShift worker nodes and control planes?

Accepted Answer

CSI Node Plugin (running as a DaemonSet on worker nodes). Option A is correct because the CSI Node Plugin runs as a DaemonSet on every worker node, handling node-local operations such as mounting and unmounting volumes for pods scheduled there. Option D is correct because the Node Driver Registrar is a sidecar that registers the CSI driver with kubelet via the kubelet plugin registration socket (e.g., /var/lib/kubelet/plugins_registry), enabling kubelet to discover and call the driver. Option E is correct because the CSI Controller Plugin runs on the control plane (typically as a Deployment) with sidecars such as external-provisioner, external-attacher, and external-resizer that watch Kubernetes API objects and perform cluster-level volume operations. Option B is not a real CSI component; etcd is Kubernetes' key-value datastore and is not deployed as a storage engine daemon for CSI. Option C is also not a CSI component; CRI-O is the container runtime and does not include a 'Runtime Proxy' deployed as part of CSI driver architecture.

Answer

etcd Storage Engine Daemon

Answer

CRI-O Runtime Proxy