CKA Storage — 50 Questions

Question 1

A DevOps team needs to provide persistent storage to a set of pods that all require read-write access to the same data simultaneously. Which volume type should they use?

Accepted Answer

PersistentVolumeClaim with ReadWriteMany. A PersistentVolumeClaim with ReadWriteMany (RWX) is the correct choice because it allows multiple pods to mount the same volume simultaneously with read-write access. This access mode is supported by network-based storage backends like NFS, GlusterFS, or CephFS, which provide the necessary concurrency controls for shared access across pods.

Answer

hostPath

Answer

emptyDir

Answer

PersistentVolumeClaim with ReadWriteOnce

Question 2

A company is migrating a stateful application to Kubernetes. The application requires persistent storage that is 'zone-aware' to survive a single zone failure and must provide the highest possible I/O performance. Which storage solution best meets these requirements?

Accepted Answer

Use a StorageClass that provisions regional Persistent Disks with replication across two zones. Regional replicated block volumes (such as GCP's Regional PDs or Azure's ZRS Disks) replicate data synchronously across multiple zones, providing zone-level fault tolerance while maintaining high I/O performance due to direct block-level access. This meets the requirement for surviving a single zone failure without the overhead of network filesystem protocols (like NFS) or application-level replication.

Answer

Use a network filesystem (NFS) server running as a single pod with a PersistentVolume backed by a regional Persistent Disk

Answer

Create a StorageClass with WaitForFirstConsumer binding and volumeBindingMode: WaitForFirstConsumer

Answer

Deploy a StatefulSet with a local SSD on each node and use a DaemonSet to manage replication

Question 3

A pod is unable to start because the PersistentVolumeClaim it references is still in 'Pending' state. What is the most likely cause?

Accepted Answer

The PersistentVolumeClaim's storage class does not exist or cannot provision a volume. A PersistentVolumeClaim (PVC) remains in 'Pending' state when it cannot find a suitable PersistentVolume (PV) to bind to or when its storage class cannot dynamically provision one. The most common cause is that the referenced storage class does not exist, is misspelled, or lacks a provisioner that can create the volume, leaving the PVC unbound and the pod unable to start.

Answer

The pod's YAML has a syntax error

Answer

The pod is using a hostPath volume

Answer

The node has insufficient CPU resources

Question 4

A cluster administrator needs to provide storage to a pod that must read and write files, but the data does not need to persist beyond the pod's lifecycle. Which volume type should be used?

Accepted Answer

emptyDir. B is correct because emptyDir creates an empty volume that is provisioned when a pod is assigned to a node and exists as long as the pod is running. It allows both reading and writing files, and its contents are deleted when the pod is removed, matching the requirement that data does not need to persist beyond the pod's lifecycle.

Answer

hostPath

Answer

configMap

Answer

PersistentVolumeClaim

Question 5

A team is designing a storage solution for a Cassandra cluster on Kubernetes. Each pod must have its own dedicated storage, and the cluster must be able to scale up and down dynamically. Which Kubernetes resource should be used to manage the storage?

Accepted Answer

StatefulSet with a volumeClaimTemplate. StatefulSet is the correct choice because it provides stable, unique network identities and dedicated storage for each pod via a volumeClaimTemplate. This ensures each Cassandra pod gets its own PersistentVolume, which is essential for stateful applications that require data persistence and ordered scaling. The volumeClaimTemplate automatically provisions a unique PersistentVolumeClaim for each replica, enabling dynamic scaling up and down while preserving data integrity.

Answer

ReplicaSet with emptyDir volumes

Answer

DaemonSet with hostPath volumes

Answer

Deployment with a single PersistentVolume shared by all pods

Question 6

Which TWO statements about PersistentVolume (PV) and PersistentVolumeClaim (PVC) binding are correct?

Accepted Answer

A PVC will remain in Pending state if no PV matches its storage request and no StorageClass is defined. Two statements are correct: Option C and Option E. Option C is correct because a PersistentVolumeClaim (PVC) will remain in Pending state if no PersistentVolume (PV) matches its storage request and no StorageClass is defined to dynamically provision a volume. Without a matching PV or a StorageClass, the Kubernetes scheduler cannot bind or create a volume for the claim, leaving it pending indefinitely. Option E is correct because a PVC can bind to a PV that supports multiple access modes, as long as the PVC's requested access mode is among those supported by the PV. The binding does not require the PV to have only that single access mode; it is sufficient that the PV's list includes the mode requested by the PVC.

Answer

A PVC can be bound to a PV that has been released and is pending reclamation

Answer

A PV can be bound to multiple PVCs simultaneously if it has ReadWriteMany access mode

Answer

A PV can only be bound to a PVC that requests exactly the same amount of storage

Question 7

Which THREE of the following are valid ways to provide storage to a pod in Kubernetes?

Accepted Answer

hostPath. A, B, and E are correct.

- **hostPath** (A) mounts a file or directory from the host node's filesystem directly into your Pod.
- **emptyDir** (B) creates a transient volume that is first created when a Pod is assigned to a node, and exists as long as that Pod is running on that node. It is commonly used for temporary caching or scratch space.
- **PersistentVolumeClaim** (E) is the standard Kubernetes way to request durable storage, which binds to a PersistentVolume (PV) and mounts it into the Pod.

Docker volumes (D) are managed by the Docker daemon and cannot be directly referenced in a Kubernetes PodSpec. Direct cloud provider volumes like AWS EBS (C) via the legacy in-tree plugin (`awsElasticBlockStore`) have been deprecated and removed in modern Kubernetes versions in favor of the Container Storage Interface (CSI) and PVCs.

Answer

AWS Elastic Block Store (EBS) directly

Answer

Docker volume

Question 8

You are a cluster administrator for a multi-tenant Kubernetes cluster. Each tenant runs a set of microservices in their own namespace. The cluster uses a custom CSI driver that provisions storage on a NetApp storage array. Recently, several tenants reported that their pods are stuck in Pending state with events indicating 'failed to provision volume' and 'timeout waiting for a volume to be created'. Upon investigation, you notice that the CSI controller pod is running but has high memory usage, and logs show 'context deadline exceeded' errors when calling the storage array API. The storage array is healthy and responsive to manual API calls from your workstation. Meanwhile, PVCs created in a test namespace with the same StorageClass succeed. What is the most likely cause and the best course of action?

Accepted Answer

Adjust the CSI driver configuration to increase the maximum number of concurrent operations and reduce the request timeout. The 'context deadline exceeded' errors and high memory usage in the CSI controller pod indicate that the driver is overwhelmed by the number of concurrent volume provisioning requests, causing them to queue up and time out. Increasing the maximum number of concurrent operations allows the driver to handle more requests in parallel, while increasing the request timeout gives the storage array and driver sufficient time to complete the operations under heavy load.

Answer

Increase the memory limit of the CSI controller pod to reduce OOM risk

Answer

Restart the CSI controller pod to clear its memory and reset connections

Answer

Add a network policy to isolate tenant namespaces to reduce load on the CSI driver

Question 9

A team is deploying a stateful application that requires persistent storage. The application runs on multiple pods that need to share the same volume. Which volume type should be used?

Accepted Answer

Create a PersistentVolumeClaim with access mode ReadWriteMany and use a supported storage class like NFS.. A stateful application with multiple pods that need to share the same volume requires a ReadWriteMany (RWX) access mode, which allows concurrent read-write access from multiple pods. A supported storage class like NFS provides the necessary network filesystem protocol to enable this shared access across pods, potentially on different nodes.

Answer

Create a PersistentVolumeClaim with access mode ReadOnlyMany and mount it in each pod.

Answer

Create a PersistentVolumeClaim with access mode ReadWriteOnce and mount it in each pod.

Answer

Use a hostPath volume configured on each node where pods are scheduled.

Question 10

An administrator notices that a pod using a PersistentVolumeClaim is stuck in 'Pending' state. The PVC is bound to a PV with the status 'Released'. What is the most likely cause?

Answer

The PV's reclaim policy is 'Retain' and the PV must be manually recycled.

Answer

The PV has a faulty disk and needs replacement.

Answer

The StorageClass has an incorrect provisioner.

Answer

The PV is not bound to any PVC.

Question 11

Which THREE statements about CSI (Container Storage Interface) are correct?

Accepted Answer

CSI supports both block and file volumes.. The CSI specification defines support for both block and file volumes, enabling storage plugins to provision raw block devices or filesystems. This flexibility allows workloads like databases to use block storage for performance, while applications requiring shared access can use file volumes.

Answer

CSI only works with dynamic provisioning.

Answer

CSI drivers must be compiled into the Kubernetes binary.

Question 12

You are managing a Kubernetes cluster with 3 worker nodes (node1, node2, node3). A stateful application named 'app-db' uses a StatefulSet with 3 replicas, each requiring a PersistentVolumeClaim (PVC) of 10Gi with access mode ReadWriteOnce. The cluster uses a StorageClass 'fast-ssd' with a CSI driver that provisions volumes on a shared SAN. The StorageClass has reclaim policy 'Delete' and volumeBindingMode 'WaitForFirstConsumer'.

Recently, node1 failed and is unrecoverable. The pod running on node1 (app-db-0) is in 'Pending' state because its PVC is still bound to a PV that exists only on node1's local storage (the CSI driver incorrectly pinned the volume to node1). The other two pods (app-db-1 and app-db-2) are running fine. The application is critical and must be restored as soon as possible. You cannot recover node1.

What is the best course of action to get app-db-0 running again?

Accepted Answer

Delete the PVC and PV associated with app-db-0, and let the StatefulSet recreate the PVC and pod.. To resolve a pod stuck in Pending due to PV node affinity on a failed node, you must delete the PVC, the PV, and the Pod itself. The StatefulSet controller will then detect the missing PVC and Pod, recreate the PVC, and then recreate the Pod. With 'WaitForFirstConsumer', the new PV will be provisioned on a healthy node where the new pod is scheduled.

Answer

Scale down the StatefulSet to 0 replicas, then scale back to 3.

Answer

Manually repair node1 and rejoin it to the cluster.

Answer

Delete only the pod app-db-0, and let the StatefulSet recreate it.

Question 13

A pod is configured to use a PersistentVolumeClaim (PVC). The PVC is bound to a PersistentVolume (PV) that uses a cloud disk. The pod fails to start with the error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32'. What is the most likely cause?

Accepted Answer

The underlying storage device is still attached to a previous node. The error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32' typically indicates a filesystem-level mount failure. When a cloud disk (e.g., AWS EBS, GCE PD) is still attached to a previous node, the new node cannot mount it because the disk is already in use or has a stale filesystem lock. Kubernetes requires the disk to be detached from the old node before it can be attached and mounted on the new node.

Answer

The PV's access mode is ReadOnlyMany

Answer

The PV is not created

Answer

The PVC is unbound

Question 14

A team wants to ensure that a pod using a PersistentVolumeClaim (PVC) is scheduled only on nodes that have the underlying storage volume available locally. Which approach should they use?

Accepted Answer

Add a nodeSelector to the pod spec that matches a label present on nodes with local storage. A nodeSelector on the Pod spec ensures the Pod is scheduled only on nodes that have a specific label, which can be applied to nodes with local storage volumes. This directly ties Pod placement to nodes that physically host the storage, avoiding scheduling on nodes without the local volume.

Answer

Use a StorageClass with volumeBindingMode: Immediate

Answer

Use a podAffinity rule to schedule the pod near the storage node

Answer

Use a PersistentVolume with nodeAffinity in the PV spec

Question 15

Which TWO statements about PersistentVolume (PV) reclaim policies are correct?

Accepted Answer

Delete policy: both the PV and the underlying storage are deleted.. The Delete reclaim policy removes both the PersistentVolume object from the cluster and the associated underlying storage asset (e.g., an EBS volume or GCE PD). This is the default behavior for dynamically provisioned PVs, ensuring no orphaned storage resources remain after the PV is released.

Answer

Recycle policy: the PV is deleted and data is scrubbed.

Answer

Delete policy: the PV remains but the underlying storage is deleted.

Answer

Retain policy: the PV is automatically deleted after 30 days.

Question 16

Refer to the exhibit. A pod is defined with an emptyDir volume using memory medium. The pod is scheduled on a node with 4 GB of RAM. The container writes 3 GB of data to /cache. What will happen?

Accepted Answer

The pod will run normally because there is no memory limit and the node has sufficient RAM.. An emptyDir volume with `medium: Memory` creates a tmpfs filesystem that uses the node's RAM, but it does not impose any inherent limit on how much memory the container can consume via that volume. Since the pod has no memory limit set (no `resources.limits.memory`), the container can write up to the node's available memory (4 GB) without being throttled or killed, as long as the node has sufficient free RAM.

Answer

The container will be throttled by the kernel's memory management.

Answer

The pod will be evicted because emptyDir with memory is not allowed to use more than 1 GB.

Answer

The pod will be OOMKilled because the emptyDir memory usage exceeds the default limit.

Question 17

A DevOps team is deploying a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes in a Kubernetes cluster. Which storage solution should they choose to meet this requirement?

Accepted Answer

Configure a PersistentVolume backed by NFS and a PersistentVolumeClaim with accessModes: ReadWriteMany. NFS supports ReadWriteMany (RWX) access mode, allowing multiple pods across different nodes to read and write to the same persistent storage simultaneously. A PersistentVolume backed by NFS, combined with a PersistentVolumeClaim specifying accessModes: ReadWriteMany, meets the requirement for a stateful application needing shared storage across nodes.

Answer

Use an emptyDir volume and share it among pods via a service

Answer

Create a local PersistentVolume on each node and use nodeSelector to pin pods

Answer

Use a hostPath volume mounted in each pod with the same path on each node

Question 18

Which TWO statements about Kubernetes PersistentVolumes and PersistentVolumeClaims are correct?

Accepted Answer

A PVC will bind to a PV that satisfies its requested storage size and access modes.. A PVC binds to a PV that satisfies its requested storage size and access modes (e.g., ReadWriteOnce, ReadOnlyMany, ReadWriteMany). The binding process matches a PVC to a PV that meets or exceeds the PVC's requirements, and once bound, the PVC consumes the PV's capacity. This is the core mechanism for dynamic or static storage provisioning in Kubernetes.

Answer

A PersistentVolume can only be created by a cluster administrator using static provisioning.

Answer

A PVC is a cluster-scoped resource, similar to a PV.

Answer

A PVC can be deleted while bound to a PV without affecting the PV.

Question 19

Which THREE of the following are valid ways to provide storage to Pods in Kubernetes?

Accepted Answer

Using an emptyDir volume. B is correct because an emptyDir volume is a simple, ephemeral storage option that is created when a Pod is assigned to a node and exists as long as that Pod is running. It is initially empty and allows containers within the same Pod to share data, making it a valid and commonly used volume type for temporary storage.

Answer

Using a ConfigMap volume

Answer

Using a Secret volume

Question 20

Drag and drop the steps to configure a NetworkPolicy that allows ingress traffic from a specific pod into the correct order.

Accepted Answer

Ensure namespace exists, define NetworkPolicy YAML with podSelector and ingress from specific pods, apply using kubectl, test ingress connectivity. First ensure the namespace exists, then define the policy with podSelector and ingress from specific pods, apply, and test.

Answer

Define NetworkPolicy YAML with podSelector and ingress from specific pods, ensure namespace exists, apply using kubectl, test ingress connectivity

Answer

Ensure namespace exists, apply using kubectl, define NetworkPolicy YAML with podSelector and ingress from specific pods, test ingress connectivity

Answer

Ensure namespace exists, define NetworkPolicy YAML with podSelector and ingress from specific pods, test ingress connectivity, apply using kubectl