CKA Storage Practice Questions

Free CKA Storage practice test questions

8 questions from this domain with answers and explanations - different from the samples on the main CKA page. Sign up free to practice the full set.

1. Question 1Storage

   What is the relationship between a PersistentVolume (PV) and a PersistentVolumeClaim (PVC)?

   • AA PV is a request for storage by a user; a PVC is the actual storage resource
   • BA PV and PVC are interchangeable terms for the same resource
   • CA PV is namespace-scoped while a PVC is cluster-scoped
   • DA PV is a cluster-level storage resource; a PVC is a user's request to consume that storageCorrect
   ✓ Correct answer: D

   A PersistentVolume (PV) is a cluster-scoped resource that represents a piece of physical or cloud storage - such as an NFS export, an AWS EBS volume, or a local disk - provisioned either statically by an administrator or dynamically by a StorageClass. A PersistentVolumeClaim (PVC) is a namespace-scoped resource created by a user that declares the required storage size, access modes, and optionally a StorageClass. The control plane binds a PVC to a PV that satisfies its requirements. Once bound, the pod references the PVC by name to mount the storage.

   Why the other options are wrong

   • AA PV is a request for storage by a user; a PVC is the actual storage resource reverses the definitions - it is the PVC that represents the user's request, while the PV represents the actual storage resource in the cluster.
   • BA PV and PVC are interchangeable terms for the same resource is incorrect - PV and PVC are distinct API objects with different scopes (cluster vs namespace) and different roles in the storage lifecycle; they are not synonyms.
   • CA PV is namespace-scoped while a PVC is cluster-scoped reverses the scoping - PVs are cluster-scoped (not tied to any namespace), while PVCs are namespace-scoped (created within a specific namespace and accessible only to pods in that namespace).
2. Question 2StorageSelect all that apply

   Frostbyte Systems is configuring a PersistentVolume. Which of the following are valid access modes for a PersistentVolume? (Select THREE)

   • AReadWriteAll (RWA)
   • BReadWriteOnce (RWO)Correct
   • CReadOnlyMany (ROX)Correct
   • DReadWriteMany (RWX)Correct
   • EWriteOnlyOnce (WOO)
   ✓ Correct answer: B, C, D

   Kubernetes recognizes four access modes for PersistentVolumes: ReadWriteOnce (RWO) allows read-write access from a single node, ReadOnlyMany (ROX) allows read-only access from multiple nodes, ReadWriteMany (RWX) allows read-write access from multiple nodes, and ReadWriteOncePod (RWOP), introduced in Kubernetes 1.22, restricts read-write access to a single pod. Support for each mode depends on the underlying storage backend. Abbreviations like RWA and WOO are not recognized by the Kubernetes API and will be rejected at admission.

   Why the other options are wrong

   • AReadWriteAll (RWA) is not a valid Kubernetes PersistentVolume access mode; no such mode exists in the Kubernetes storage API.
   • EWriteOnlyOnce (WOO) is not a valid Kubernetes PersistentVolume access mode; Kubernetes does not define write-only access semantics for volumes.
3. Question 3Storage

   After a bound PVC is deleted under a 'Retain' reclaim policy, what state is the PV left in?

   • AAvailable, wiped and ready to bind
   • BReleased, with its data intactCorrect
   • CDeleted along with its backing disk
   • DFailed, needing a full recreate
   ✓ Correct answer: B

   When the bound PVC is deleted and the policy is Retain, the PV moves to Released but keeps its data and does not automatically become bindable. An administrator must clear the claimRef and handle the data before reuse. This protects against accidental data loss.

   Why the other options are wrong

   • ARetain leaves the PV Released, not Available and wiped.
   • CDeleting the disk is the Delete policy's behavior, not Retain's.
   • DRetain does not fail the PV; it keeps the data for manual reclaim.
4. Question 4Storage

   Which access mode allows a volume to be mounted as read-only by multiple nodes simultaneously?

   • AReadWriteOnce
   • BReadOnlyOnce
   • CReadOnlyManyCorrect
   • DReadWriteMany
   ✓ Correct answer: C

   ReadOnlyMany (ROX) is the Kubernetes access mode that permits a PersistentVolume to be mounted as read-only by any number of nodes at the same time. This mode is commonly supported by network storage backends such as NFS and is appropriate for shared read-only data such as configuration files, static assets, or reference datasets accessed by many pods across multiple nodes.

   Why the other options are wrong

   • AReadWriteOnce (RWO) allows the volume to be mounted as read-write, but only by a single node at a time. It does not permit simultaneous access from multiple nodes and does not enforce read-only semantics.
   • BReadOnlyOnce is not a valid Kubernetes access mode. The three standard access modes are ReadWriteOnce, ReadOnlyMany, and ReadWriteMany, with ReadWriteOncePod added in Kubernetes 1.22.
   • DReadWriteMany (RWX) allows the volume to be mounted as read-write by multiple nodes simultaneously. It permits writes, which is the opposite of the read-only requirement described in the question.
5. Question 5Storage

   How do you make a StorageClass the default for the cluster?

   • AAdd annotation storageclass.kubernetes.io/is-default-class: "true"Correct
   • Brun kubectl set-default storageclass <name>
   • CAdd label default-class: "true" to the StorageClass
   • DSet spec.default: true in the StorageClass
   ✓ Correct answer: A

   Kubernetes uses the annotation storageclass.kubernetes.io/is-default-class set to the string 'true' to identify the default StorageClass. When a PVC is created without a storageClassName field, the admission controller automatically assigns the default StorageClass to it. Only one StorageClass should be marked as default at a time; if multiple StorageClasses have this annotation, PVC creation will fail with an error about multiple defaults.

   Why the other options are wrong

   • Bkubectl set-default storageclass is not a valid kubectl command. There is no set-default subcommand in kubectl; the default StorageClass is configured by patching the annotation directly on the StorageClass object.
   • CAdding a label default-class: 'true' to the StorageClass has no special meaning in Kubernetes. The default StorageClass mechanism is driven by a specific annotation, not a label. Labels on StorageClasses are used only for selection and organization purposes.
   • DSetting spec.default: true in the StorageClass is not a valid StorageClass field. The StorageClass API does not have a spec.default boolean; the default designation is communicated exclusively through the storageclass.kubernetes.io/is-default-class annotation on the metadata.
6. Question 6Storage

   What is the correct pod spec to use PVC "logs-pvc" mounted at /var/log/app?

   • Aspec: { storage: [{ pvc: logs-pvc, mount: /var/log/app }], containers: [{ name: app }] }
   • Bspec: {volumes: [{name: lv, persistentVolumeClaim: {claimName: logs-pvc}}], containers: [{volumeMounts: [{name: lv, mountPath: /var/log/app}]}]}Correct
   • Cspec: { containers: [{ volumes: [{ persistentVolumeClaim: logs-pvc, mountPath: /var/log/app }] }] }
   • Dspec: { volumes: [{ name: log-vol, claim: logs-pvc }], containers: [{ volumeMounts: [{ name: log-vol, path: /var/log/app }] }] }
   ✓ Correct answer: B

   Mounting a PVC in a pod requires two cooperating sections in the pod spec. First, a volume entry at the top-level spec.volumes array references the PVC by name using persistentVolumeClaim.claimName. Second, the container spec includes a volumeMounts entry that references the volume by its name and specifies the mountPath inside the container. This two-step indirection allows multiple containers in the same pod to mount the same volume at different paths.

   Why the other options are wrong

   • AThere is no top-level spec.storage field; volumes are declared under spec.volumes.
   • Cvolumes are defined at the pod spec level, not nested inside a container.
   • DThe volume source key is persistentVolumeClaim.claimName, and mounts use mountPath, not claim and path.
7. Question 7Storage

   How do you mount a downwardAPI volume that exposes the pod labels as a file?

   • Avolumes: [{ name: podinfo, downwardAPI: { fields: [{ path: "labels", ref: "metadata.labels" }] } }]
   • Bvolumes: [{ name: podinfo, metadata: { items: [{ path: "labels", expose: "metadata.labels" }] } }]
   • Cvolumes: [{ name: podinfo, downwardAPI: { path: "labels", fieldPath: "metadata.labels" } }]
   • Dvolumes: [{ name: podinfo, downwardAPI: { items: [{ path: "labels", fieldRef: { fieldPath: metadata.labels } }] } }]Correct
   ✓ Correct answer: D

   The downwardAPI volume source exposes pod metadata to containers as files. Each file is defined by an entry in the items array, where path specifies the filename created in the mount directory and fieldRef.fieldPath references the pod metadata field to project. Using fieldPath: metadata.labels writes the pod's labels into a file named labels with each label on its own line in key="value" format. This is the only valid schema for projecting labels through the Downward API volume.

   Why the other options are wrong

   • AdownwardAPI uses items with a fieldRef object, not a fields list with a ref shorthand.
   • BThere is no metadata volume type; pod metadata is exposed through a downwardAPI volume.
   • CEach downwardAPI entry lives in items with a fieldRef; path and fieldPath are not top-level keys.
8. Question 8Storage

   You need to create a PV that uses an existing NFS share at server 10.0.0.5 with path /exports/data. Which volume type do you specify?

   • ACsi with driver nfs
   • BhostPath with path /exports/data
   • CNfs with server: 10.0.0.5 and path: /exports/dataCorrect
   • DLocal with path /exports/data
   ✓ Correct answer: C

   Kubernetes has a built-in nfs volume source that mounts an existing NFS export directly into a PersistentVolume. It is configured with server set to the NFS server's hostname or IP (10.0.0.5) and path set to the exported directory (/exports/data), plus an optional readOnly flag. No provisioner is needed because the export already exists; the kubelet uses the node's NFS client to mount it. This natively supports the ReadWriteMany access mode for shared access.

   Why the other options are wrong

   • Acsi with driver nfs is incorrect because using a CSI source would require deploying a separate NFS CSI driver, whereas the question targets the built-in nfs volume type that needs only server and path.
   • BhostPath with path /exports/data is incorrect because hostPath mounts a directory from the node's own filesystem, not a remote NFS export, and provides no networked sharing.
   • Dlocal with path /exports/data is incorrect because the local volume type references node-attached storage with node affinity, not a remote NFS server.

How Storage is tested

This domain holds 168 of the 903 questions in the CKA bank, about 19%. The mix is 157 single-answer multiple choice and 11 multiple-response, so it is worth practising the formats as well as the content.

Once you have a few attempts recorded, CertGrid scores every domain separately and points you at the weakest one, so you can drill Storage on its own rather than re-running full-length mocks.

Other CKA exam domains

• Cluster Architecture Installation and Configuration197 questions
• Workloads and Scheduling187 questions
• Services and Networking168 questions
• Troubleshooting183 questions
• All CKA practice questions903 total
• Storage study notesKey concepts
• Cloud Native practice examsAll Cloud Native

CKA Storage FAQ