Storage — CKA Practice Quiz

Question 1

A developer creates a PVC named 'cache-data' that dynamically provisions a PV through a StorageClass whose reclaimPolicy is 'Delete'. After testing, the developer deletes the PVC to free resources. A day later, the team asks you to recover the data that was on that volume. Which statement correctly describes what happened and why?

Accepted Answer

The PV and its underlying storage asset were automatically deleted when the PVC was removed, so the data is unrecoverable from Kubernetes.

Answer

The PV entered the 'Released' state and retained the data, so you can simply re-bind a new PVC to recover it.

Answer

The PV remains 'Bound' until an administrator manually deletes it, so the data is still intact and available.

Answer

Deleting a PVC never affects the PV regardless of reclaim policy; only deleting the StorageClass triggers volume cleanup.

Question 2

You have created a single PersistentVolume named 'data-pv' with capacity 50Gi, accessModes ReadWriteOnce, and no storageClassName. Two PersistentVolumeClaims are pending: 'claim-a' requests 20Gi ReadWriteOnce, and 'claim-b' requests 20Gi ReadWriteOnce. Both PVCs have no storageClassName set. After a few moments you observe that 'claim-a' is Bound to 'data-pv' but 'claim-b' remains Pending. Why does 'claim-b' stay Pending?

Accepted Answer

A PersistentVolume can only be bound to one PersistentVolumeClaim at a time, so the remaining 30Gi of 'data-pv' cannot be shared with 'claim-b'.

Answer

'claim-b' requests ReadWriteOnce, which prevents it from binding to any volume already bound by another claim, but ReadWriteMany would have allowed it to share 'data-pv'.

Answer

The PV's remaining capacity (30Gi) is insufficient because Kubernetes reserves 50% overhead on hostPath volumes.

Answer

'claim-b' must specify a storageClassName matching the PV in order to bind, while 'claim-a' bound because it was created first.

Question 3

A developer creates a PersistentVolumeClaim requesting 10Gi with accessMode ReadWriteOnce. The cluster has three manually-created PersistentVolumes with no storageClassName set: PV-a (5Gi, ReadWriteOnce, Available), PV-b (20Gi, ReadWriteMany, Available), and PV-c (15Gi, ReadWriteOnce, Available). No StorageClass and no dynamic provisioner exist. Which PV will the PVC bind to?

Accepted Answer

PV-c, because it satisfies both the requested capacity and access mode

Answer

PV-a, because it is the smallest volume that most tightly matches the request

Answer

PV-b, because ReadWriteMany is a superset that also allows ReadWriteOnce access

Answer

The PVC stays Pending because no StorageClass is defined for dynamic provisioning

Question 4

A stateful application uses a PVC bound to a PV backed by a block-storage CSI driver that only supports ReadWriteOnce. The PVC is currently mounted by a pod running on node worker-1. You scale the Deployment to 2 replicas, and the second pod is scheduled to worker-2 but remains stuck in ContainerCreating. Events on the second pod show a FailedAttachVolume / Multi-Attach error. What is the correct explanation and remedy?

Accepted Answer

ReadWriteOnce allows the volume to be mounted read-write by only one node at a time; use a ReadWriteMany-capable storage backend or ensure both pods land on the same node.

Answer

ReadWriteOnce means only one pod can ever use the volume; delete and recreate the PVC with ReadWriteOncePod to allow the second pod to attach.

Answer

The PV reclaim policy is set to Retain, which blocks additional attachments; change it to Delete so the volume can be shared across nodes.

Answer

The volumeBindingMode is Immediate, preventing multi-node attachment; recreate the StorageClass with WaitForFirstConsumer to allow simultaneous mounts.

Question 5

A developer creates a PersistentVolumeClaim requesting 5Gi with accessMode ReadWriteOnce, but the PVC remains stuck in 'Pending' status. The cluster has no manually created PersistentVolumes. You inspect the PVC and notice it does not specify a storageClassName field, and no default StorageClass is configured in the cluster. What is the most likely reason the PVC is not being bound?

Accepted Answer

Without a default StorageClass or an explicit storageClassName, dynamic provisioning cannot occur and no matching pre-provisioned PV exists to bind.

Answer

The requested size of 5Gi exceeds the maximum allowed for ReadWriteOnce volumes, which is capped at 1Gi.

Answer

ReadWriteOnce access mode requires at least two worker nodes to be available before a PVC can bind.

Answer

The PVC must include a reclaimPolicy of Retain in its spec before the scheduler will bind it to any volume.

Question 6

You statically provision a PersistentVolume named data-pv with a capacity of 50Gi, accessModes of ReadWriteOnce, and no storageClassName set. A developer then creates a PersistentVolumeClaim requesting 20Gi of storage with ReadWriteOnce and no storageClassName. The PVC binds successfully to data-pv. When the developer runs 'df -h' inside the pod that mounts this PVC, what usable capacity will the mounted volume report for a typical backing filesystem?

Accepted Answer

Approximately 50Gi, because the PVC binds to the entire PV and there is no per-claim capacity enforcement on a statically provisioned volume

Answer

Exactly 20Gi, because Kubernetes enforces the requested capacity as a hard quota on the mounted filesystem

Answer

0Gi, because the capacity mismatch prevents the volume from being usable despite the binding

Answer

35Gi, the average of the PV capacity and the PVC request

Question 7

A developer created a PVC named 'data-pvc' requesting 5Gi from the 'fast-ssd' StorageClass, and it successfully bound to a dynamically provisioned PV. The application now needs 20Gi. The developer edits the PVC and changes 'spec.resources.requests.storage' to 20Gi, but the change is rejected with an error, and the PVC remains at 5Gi. The 'fast-ssd' StorageClass does NOT have 'allowVolumeExpansion' set. What is the correct way to give the application 20Gi of storage while keeping data loss to a minimum?

Accepted Answer

Set 'allowVolumeExpansion: true' on the existing 'fast-ssd' StorageClass, then edit the PVC to request 20Gi so the volume expands in place.

Answer

Delete and recreate the PVC with a 20Gi request; the existing PV will automatically resize to match the new claim.

Answer

Edit the bound PV directly to increase its capacity to 20Gi, which propagates the new size to the PVC.

Answer

Enable expansion by adding 'allowVolumeExpansion: true' to the StorageClass, but note that in-flight PVCs bound before the change cannot be expanded and must be recreated.

Question 8

A PersistentVolume named 'data-pv' was created with persistentVolumeReclaimPolicy set to Retain. After the bound PVC was deleted by a developer, the underlying storage still contains critical data, but the PV now shows STATUS 'Released' and cannot be bound to a new PVC even though the new PVC requests the same storage class, capacity, and access mode. What must you do to make the existing 'data-pv' bindable again while preserving the data?

Accepted Answer

Edit the PV and remove the 'spec.claimRef' field so its status returns to Available, allowing a new matching PVC to bind

Answer

Delete and recreate the PV; the Retain policy guarantees the data survives PV deletion and the new PV will auto-bind

Answer

Change the reclaim policy to Recycle so Kubernetes scrubs and re-advertises the volume as Available

Answer

Patch the PV status field to 'Available' using kubectl patch --subresource=status

Question 9

You deploy a StatefulSet named 'db' with 3 replicas. Its spec includes a volumeClaimTemplates entry with metadata.name 'data', accessModes ReadWriteOnce, storageClassName 'fast-ssd', and a 10Gi request. The 'fast-ssd' StorageClass supports dynamic provisioning. After the StatefulSet becomes fully ready, how many PersistentVolumeClaims exist and what is their naming pattern?

Accepted Answer

3 PVCs, each dynamically provisioned, named data-db-0, data-db-1, and data-db-2

Answer

1 PVC named data, shared by all three pods via ReadWriteOnce access

Answer

3 PVCs named db-data-0, db-data-1, and db-data-2, but you must pre-create the matching PVs manually

Answer

0 PVCs, because volumeClaimTemplates only defines an ephemeral volume that lives with each pod

Question 10

A developer needs to increase the size of a PersistentVolumeClaim named 'data-pvc' from 5Gi to 20Gi because the application is running out of space. The PVC was dynamically provisioned by a StorageClass named 'fast-ssd' backed by a CSI driver that supports online resizing. When the developer edits the PVC and increases spec.resources.requests.storage to 20Gi, the change is rejected with the error 'persistentvolumeclaims "data-pvc" is forbidden: only dynamically provisioned pvcs can be resized and the storageclass that provisions the pvc must support resize'. What must be done to allow the resize to succeed?

Accepted Answer

Set 'allowVolumeExpansion: true' on the 'fast-ssd' StorageClass, then edit the PVC to request 20Gi.

Answer

Delete the PVC and recreate it with the larger 20Gi request, since PVC size is immutable.

Answer

Change the PVC's accessModes to ReadWriteMany, which enables volume expansion.

Answer

Set the PersistentVolume's persistentVolumeReclaimPolicy to Retain before editing the PVC size.

Question 11

A developer submits a PersistentVolumeClaim that does not specify a storageClassName. The cluster has three StorageClasses defined, but the PVC remains Pending and no PersistentVolume is dynamically provisioned. You run 'kubectl get storageclass' and see that none of the classes shows '(default)' next to its name. What is the most likely cause and correct fix?

Accepted Answer

No StorageClass is marked as default; add the 'storageclass.kubernetes.io/is-default-class: "true"' annotation to the desired StorageClass so PVCs without a storageClassName use it.

Answer

The PVC requires an explicit accessModes field to trigger provisioning; add 'accessModes: [ReadWriteMany]' to the claim.

Answer

Dynamic provisioning only works when a matching PersistentVolume is manually pre-created; create a PV that matches the claim's size.

Answer

The provisioner field on the StorageClass must be set to 'kubernetes.io/no-provisioner'; update all three classes to enable dynamic provisioning.

Question 12

You define a StorageClass backed by a topology-constrained CSI driver where volumes can only be attached to nodes in the same availability zone. Developers report that PVCs bind immediately, but Pods using them sometimes fail to schedule because the volume was provisioned in a zone that has no available nodes for the Pod. Which StorageClass setting should you configure to ensure the volume is provisioned in a zone compatible with where the Pod will actually be scheduled?

Accepted Answer

Set volumeBindingMode: WaitForFirstConsumer

Answer

Set volumeBindingMode: Immediate

Answer

Set reclaimPolicy: Retain

Answer

Set allowVolumeExpansion: true

More CKA practice