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. A free account includes a fixed set of 20 questions for this exam; paid access unlocks the full bank.

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 2Storage

   CipherGuard Security has a pod that requires access to sensitive TLS certificates. How should these certificates be stored and mounted in the pod?

   • AStore them in a Secret and mount as a volume with restrictive file permissionsCorrect
   • BStore them in a ConfigMap and mount the certificate files as a volume
   • CEmbed the certificates directly into the container image at build time
   • DStore them in a hostPath volume replicated onto each worker node
   ✓ Correct answer: A

   Kubernetes Secrets are the appropriate resource for storing sensitive data such as TLS certificates and private keys. Secrets are base64-encoded and can be encrypted at rest in etcd when encryption-at-rest is configured. When mounted as a volume, Secret data is stored in a tmpfs (RAM-backed) filesystem on the node, which means it is never written to persistent disk on the node. File permissions can be controlled using the defaultMode field, ensuring only the application process can read the certificate files. Using Secrets also enables RBAC policies to control which pods and service accounts can access the sensitive material.

   Why the other options are wrong

   • BConfigMaps store non-sensitive data in plaintext and lack the protections meant for TLS keys.
   • CBaking secrets into an image exposes them to anyone who can pull the image and prevents rotation.
   • DhostPath ties sensitive files to node disks with no access control or encryption at rest.
3. Question 3Storage

   Which volume type allows you to mount a directory from the host node's filesystem into a Pod?

   • AhostPathCorrect
   • BconfigMap
   • CemptyDir
   • Dnfs
   ✓ Correct answer: A

   A hostPath volume mounts a specified file or directory from the underlying Kubernetes node's filesystem directly into the Pod at the configured mountPath. This makes the contents of the node's filesystem visible to the container, which is useful in specific scenarios such as accessing the container runtime socket, reading node-level log files, or running privileged monitoring agents. However, hostPath introduces tight coupling to the node and significant security risks - a misconfigured hostPath can expose sensitive host data - so it should be avoided in multi-tenant or production environments.

   Why the other options are wrong

   • BconfigMap volumes expose Kubernetes ConfigMap key-value data as files inside a Pod; they do not provide access to the node's filesystem.
   • CemptyDir creates a fresh, empty temporary directory on the node for the Pod's exclusive use; it does not mount an existing path from the node's filesystem.
   • Dnfs mounts a remote Network File System share exported from a server into the Pod; it accesses network-attached storage rather than the local node's filesystem.
4. Question 4Storage

   How do you mount a Secret named "db-creds" as a volume at /etc/secrets in a pod?

   • Avolumes: [{ name: secret-vol, secret: { secretName: db-creds } }] and volumeMounts: [{ name: secret-vol, mountPath: /etc/secrets }]Correct
   • Bvolumes: [{ name: secret-vol, type: secret, name: db-creds }] and volumeMounts: [{ volume: secret-vol, path: /etc/secrets }]
   • CsecretVolume: { name: db-creds, mountPath: /etc/secrets }
   • Dcontainers: [{ secrets: [{ name: db-creds, path: /etc/secrets }] }]
   ✓ Correct answer: A

   Mounting a Kubernetes Secret as a volume follows the same two-part pattern as ConfigMap mounts: a volumes entry under the pod spec references the Secret using the secret.secretName field, and a volumeMounts entry in the container spec references that volume by name and provides the mountPath. Each key in the Secret becomes a file in the mounted directory, with the file content being the base64-decoded Secret value.

   Why the other options are wrong

   • Bvolumes with type: secret and a duplicate name key, along with volumeMounts using volume and path fields, uses non-existent field names. The correct Secret volume source field is secret.secretName, and volumeMounts requires mountPath, not path.
   • CsecretVolume: { name: db-creds, mountPath: /etc/secrets } is not a valid Kubernetes pod spec field. Secrets cannot be referenced through a top-level secretVolume field; they must be declared in the pod's volumes array using the standard secret volume source.
   • Dcontainers: [{ secrets: [{ name: db-creds, path: /etc/secrets }] }] uses a non-existent secrets field directly inside the container spec. Volume sources must be declared in the pod-level volumes array and referenced in the container's volumeMounts array.
5. Question 5Storage

   Which command deletes PV "old-volume"?

   • Akubectl pv delete old-volume
   • Bkubectl destroy persistentvolume old-volume
   • Ckubectl remove pv old-volume
   • Dkubectl delete pv old-volumeCorrect
   ✓ Correct answer: D

   kubectl delete pv old-volume is the correct imperative command to remove a PersistentVolume resource from the Kubernetes API. The resource type pv is the recognized short name for persistentvolume, and kubectl delete is the standard subcommand for removing any Kubernetes resource by its kind and name.

   Why the other options are wrong

   • Akubectl pv delete is invalid syntax; kubectl does not support placing the resource type before the verb. The correct form is kubectl delete pv.
   • Bkubectl destroy is not a valid kubectl subcommand; no such command exists in the Kubernetes CLI.
   • Ckubectl remove is not a valid kubectl subcommand; the correct verb for deleting resources in kubectl is delete.
6. Question 6Storage

   Which StorageClass parameter sets the filesystem type for dynamically provisioned volumes?

   • Aparameters.fsTypeCorrect
   • Bspec.fileSystem
   • Cspec.formatType
   • Dparameters.filesystem
   ✓ Correct answer: A

   In a StorageClass definition, the parameters map passes driver-specific settings to the provisioner. The fsType key within parameters tells the CSI driver or in-tree provisioner which file system to create when formatting a new volume, with common values being ext4 and xfs. This setting only applies to dynamically provisioned volumes using that StorageClass; statically created PVs have their file system set during manual formatting.

   Why the other options are wrong

   • Bspec.fileSystem is incorrect because fileSystem is not a field in the StorageClass spec; file system type for dynamic provisioning is expressed inside the parameters map, not as a top-level spec field.
   • Cspec.formatType is incorrect because formatType is not a recognized StorageClass field; the provisioner reads file system type from parameters.fsType.
   • Dparameters.filesystem is incorrect because the conventional and widely-supported key name used by CSI drivers and in-tree provisioners is fsType, not filesystem; using the wrong key name means the provisioner ignores it and uses its default.
7. Question 7Storage

   A StatefulSet pod cannot start because its PVC is bound to a PV on a different node, and the PV uses local storage. What is the problem?

   • AStatefulSets cannot use PersistentVolumeClaims for their pod storage
   • BThe PV must be expanded before the StatefulSet pod can attach it
   • CThe StatefulSet replica count exceeds the number of available local PVs
   • DLocal PVs are node-specific; use volumeBindingMode: WaitForFirstConsumerCorrect
   ✓ Correct answer: D

   A local PersistentVolume carries nodeAffinity that ties it to one node, and the scheduler honours it, so a pod whose PVC is already bound to that PV can run only on that node. With immediate binding, the PVC is bound before the pod is scheduled, without considering the pod's other constraints such as resource requests, taints or anti-affinity, so the only node the PV allows may be unable to run the pod. Setting the StorageClass volumeBindingMode to WaitForFirstConsumer delays binding until a consuming pod is scheduled, so the binding decision is evaluated together with the pod's other node constraints. The Kubernetes documentation recommends this mode for local-volume StorageClasses.

   Why the other options are wrong

   • AStatefulSets are specifically designed to use PVCs through volumeClaimTemplates.
   • BResizing does not move a local PV; the issue is node affinity binding the pod to the wrong node.
   • CThe failure is node placement of a local PV, not a shortage relative to replica count.
8. Question 8StorageSelect all that apply

   An administrator creates a static PV by hand and a PVC that should bind to it, but they stay unbound. Which TWO conditions must the pair satisfy? (Choose TWO)

   • AThe PV's capacity is at least the size the PVC requestsCorrect
   • BThe PV and PVC name the same storageClassName, empty counting as a valueCorrect
   • CThe PV and PVC exist in the same namespace as one another
   • DThe PV's reclaimPolicy matches the persistentVolumeReclaimPolicy on the PVC
   • EThe PV lists every access mode the cluster supports, not just the requested one
   ✓ Correct answer: A, B

   For a static PV the control loop looks for an Available volume that satisfies the claim: capacity at least the requested size, access modes that include those requested, and an equal storageClassName. That last one causes most of the trouble, because an omitted storageClassName is the empty string rather than a wildcard, so a PVC that omits it will not bind to a PV that names one, and a PVC naming a class will not bind to a PV that omits it. If a default StorageClass exists it is stamped onto a PVC that omits the field, which quietly turns an intended static binding into a dynamic provisioning request instead.

   Why the other options are wrong

   • CA PersistentVolume is cluster-scoped and has no namespace, so being in the same namespace is not a condition that can be met.
   • DA PVC has no reclaim policy field; the reclaim policy belongs to the PV alone and plays no part in matching.
   • EThe PV only needs to offer the access modes the claim requests; listing every mode the cluster supports is neither required nor possible.

How Storage is tested

This domain holds 145 of the 793 questions in the CKA bank, about 18%. The mix is 179 single-answer multiple choice and 12 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 Configuration167 questions
• Workloads and Scheduling173 questions
• Services and Networking152 questions
• Troubleshooting156 questions
• All CKA practice questions793 total
• Storage study notesKey concepts
• Cloud Native practice examsAll Cloud Native

CKA Storage FAQ