EX280 Storage And Persistent Volumes — 10 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