Storage And Persistent Volumes practice questions

openshift-storage.rbd.csi.ceph.com

Why it fails: Ceph RBD provides block storage and typically only supports ReadWriteOnce (RWO) in standard configurations.

gp2-csi.storage.k8s.io

Why it fails: General Purpose SSD EBS provisioner only supports RWO.

ebs.csi.aws.com

Why it fails: AWS EBS CSI only supports ReadWriteOnce (RWO).

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

Why it fails: VolumeSnapshots become ready automatically once the underlying CSI driver completes the operation.

The VolumeSnapshotClass is missing the deletionPolicy parameter.

Why it fails: Deletion policy governs what happens when the snapshot object is deleted, not its initial readiness.

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

Why it fails: Most modern CSI drivers support taking crash-consistent snapshots of mounted and actively written volumes.

nfs.csi.k8s.io

Why it fails: While a CSI driver for NFS exists, the most widely documented and utilized dynamic solution for basic NFS in admin workflows is the external-provisioner.

kubernetes.io/nfs

Why it fails: This in-tree provisioner is deprecated and removed in modern OpenShift versions.

openshift.io/nfs-dynamic

Why it fails: This provisioner name does not exist in OpenShift.

deletionPolicy: Retain

Why it fails: deletionPolicy is not a valid field in a StorageClass resource.

persistentVolumeReclaimPolicy: Keep

Why it fails: The correct key name is reclaimPolicy, not persistentVolumeReclaimPolicy at the StorageClass spec level.

PersistentVolume

Why it fails: A PV is a piece of storage in the cluster, not the template/class definition.

PersistentVolumeClaim

Why it fails: A PVC is a user's request for and claim upon storage.

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

Why it fails: storageClassName is an immutable field on an existing PVC.

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

Why it fails: This annotation does not exist.

OCP Storage Mutating Webhooks

Why it fails: Webhooks handle default injection and validation, but deletion protection relies on object finalizers.

etcd Object Lock

Why it fails: etcd does not provide object-level lock mechanisms for user applications.

StorageClass Retain Policy

Why it fails: Retain policy applies to PersistentVolumes upon PVC deletion, not VolumeSnapshots.

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

Why it fails: That behavior is characteristic of the Retain policy.

The PV is automatically archived into an object storage bucket.

Why it fails: Archiving is not a native Kubernetes reclaim policy.

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

Why it fails: Released status occurs before deletion or recycling when reclaim policy is Retain or Recycle.

Apply matching labels and set volumeBindingMode to Strict.

Why it fails: volumeBindingMode does not have a 'Strict' setting.

Set allowVolumeExpansion to false on the PV.

Why it fails: allowVolumeExpansion controls resizing capability, not binding.

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

Why it fails: This annotation is not used for binding; spec.volumeName is.

ReadOnlyMany

Why it fails: ReadOnlyMany restricts mounts to read-only.

ReadWriteOnce

Why it fails: ReadWriteOnce limits the volume to a single node.

ReadWriteOncePod

Why it fails: ReadWriteOncePod restricts access to a single pod in the entire cluster, but RWX is for multiple pods/nodes.

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

Why it fails: The controller updates the resizing status conditions rather than silently desynchronizing metadata and backend.

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

Why it fails: OpenShift never mutates storage classes or migrates PVC data automatically in this manner.

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

Why it fails: PVC expansion has no relationship to node disk space availability.

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

Why it fails: This annotation does not exist.

Set snapshotRetention: permanent in the VolumeSnapshot spec.

Why it fails: This field is invalid in VolumeSnapshot specs.

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

Why it fails: RWO restricts write access and multi-node attachment for block devices, but read-only sharing varies, and RWO is about node attachment exclusivity.

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

Why it fails: Access modes are explicitly requested by the PVC spec.

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

Why it fails: ROM is read-only, not write.

The PVC must belong to the kube-system namespace.

Why it fails: PVCs can be created in any user project/namespace.

etcd Storage Engine Daemon

Why it fails: etcd is managed by the control plane operator, not CSI drivers.

CRI-O Runtime Proxy

Why it fails: CRI-O is the container runtime, not a CSI component.

The storage backend archives the data into an immutable snapshot.

Why it fails: Delete destroys data rather than archiving it.

The PV status changes to Released and remains indefinitely.

Why it fails: Released status happens with Retain, not Delete.

Format all worker nodes with XFS filesystems.

Why it fails: Filesystem choice on worker nodes does not govern snapshot controller deployment.

metadata.annotations['snapshot.storage.kubernetes.io/restore']

Why it fails: Annotations carry metadata only; the CSI snapshot restore controller reads spec.dataSource, not annotations, so no restore is initiated. It is tempting because annotation-driven provisioning exists for other storage classes, but snapshot restoration is a first-class API field. Without dataSource naming the VolumeSnapshot, a blank volume is provisioned.

spec.resources.requests.storage matching the exact snapshot block ID

Why it fails: Storage requests size the resulting volume; they cannot reference a snapshot, which is identified by a VolumeSnapshot object, not a block ID. It is tempting because capacity must match or exceed the snapshot's restored size, but that is a sizing constraint, not the restore trigger. The dataSource field with kind VolumeSnapshot names the source.

spec.volumeName matching the UUID of the snapshot storage backend

Why it fails: Binding a PVC to a pre-existing PersistentVolume via spec.volumeName cannot restore snapshot contents; it only claims an already-provisioned volume. Snapshot restoration requires spec.dataSource referencing the VolumeSnapshot, which the CSI driver uses to populate a fresh volume. spec.volumeName suits static provisioning, where an administrator has manually created a PV for the claim to bind.

Neither volume will bind because the access modes do not match exactly.

Why it fails: Access modes do not need to match exactly; the volume's access mode must be a superset of the claim's. ReadWriteMany supports both read and write by many nodes, which includes the single-node read-write semantics of ReadWriteOnce. Therefore pv-b is compatible. pv-a is also compatible in access mode but has a larger capacity, so binding is possible but not with pv-a as the best fit.

pv-a, because it is the first matching volume in alphabetical order.

Why it fails: Alphabetical order is not a criterion for binding. OpenShift uses a best-fit algorithm that considers capacity, access modes, and other factors. pv-a has 10Gi, which is larger than the requested 5Gi, so it is a less precise fit than pv-b, which exactly matches the requested size and supports the required access mode. Thus pv-a would not be chosen over pv-b.

pv-a, because it has the larger capacity and can accommodate future growth.

Why it fails: The binding process does not consider future growth. It selects the smallest volume that satisfies the claim's requirements. pv-a is larger than needed, so it is not the best fit. pv-b exactly matches the requested size and access mode, making it the preferred choice. Using a larger volume would waste storage and is not how the scheduler selects volumes.

oc get pvc -n <namespace> -l app=db

Why it fails: This command filters PVCs by the label app=db, but PersistentVolumeClaims created by a StatefulSet's volumeClaimTemplates do not automatically receive the StatefulSet's pod labels. StatefulSet PVCs are named after the template and replica, and they carry no app=db label by default, so this query returns no results for this scenario.

oc describe statefulset db -n <namespace>

Why it fails: Describing the StatefulSet shows its volumeClaimTemplates specification and pod status, but it does not report the dynamically created PersistentVolumeClaims' actual storage class or capacity. The template defines what should be created, while the live PVC objects hold the provisioned result, so this command does not verify the claims themselves.

oc get pvc -n <namespace> --field-selector metadata.name=db

Why it fails: A field selector on metadata.name=db would only match a PVC whose exact name is 'db', but StatefulSet volumeClaimTemplates generate PVCs with names combining the template name and ordinal, such as 'data-db-0'. No PVC named exactly 'db' exists, so this selector returns nothing and fails to list the replica claims.