CKA Storage — Timed 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. Option C is correct because regional Persistent Disks replicate data synchronously across two zones, providing zone-level fault tolerance while maintaining high I/O performance due to direct block storage access. This meets the requirement for surviving a single zone failure without the overhead of network filesystem protocols 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. Option C is correct because a PersistentVolumeClaim (PVC) will remain in the 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 until a suitable PV becomes available or a StorageClass is added.

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

Answer

A PVC can be bound to a PV with a different access mode if the PV supports multiple modes

Question 7

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

Accepted Answer

hostPath. A is correct because `hostPath` mounts a file or directory from the host node's filesystem into a pod, allowing the pod to access persistent data stored on the node. This is a valid Kubernetes volume type defined in the PodSpec, commonly used for accessing host-level logs or configuration files, though it lacks portability across nodes.

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. Option A is correct because 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 timeouts. Increasing the maximum number of concurrent operations allows the driver to handle more requests in parallel, while reducing the request timeout prevents long waits for unresponsive calls, aligning with the healthy storage array and successful test PVCs.

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.. Option B is correct because 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?

Accepted Answer

The PV's reclaim policy is 'Retain' and the PV must be manually recycled.. A PVC stuck in 'Pending' means it cannot find a suitable PV to bind to. The PV is in 'Released' status, which indicates it was previously bound to a PVC that has since been deleted. With a 'Retain' reclaim policy, the PV is not automatically recycled or made available for reuse; the administrator must manually delete and recreate the PV to clear its claimRef and make it available again. This manual intervention is required because the 'Retain' policy preserves the underlying storage and its data, leaving the PV in a 'Released' state that cannot be bound to a new PVC.

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

A cluster uses a CSI driver for dynamic provisioning. An administrator creates a StorageClass with 'volumeBindingMode: WaitForFirstConsumer' and a PVC. The pod using the PVC is scheduled to a node. However, the PV is never provisioned. What is the most likely cause?

Accepted Answer

The CSI driver is not installed or malfunctioning.. When `volumeBindingMode: WaitForFirstConsumer` is set, the PV is not provisioned until a pod using the PVC is scheduled to a node. If the PV is never provisioned after scheduling, the most likely cause is that the CSI driver is not installed or malfunctioning, because the dynamic provisioning request is sent to the CSI driver, and without a functioning driver, the PV creation will fail silently or not occur at all.

Answer

The PVC is not bound to a PV because no PV exists.

Answer

The pod does not have the correct node selector.

Answer

The StorageClass uses 'Immediate' binding mode.

Question 12

A developer wants to mount a ConfigMap as a volume in a pod. However, the pod should only see specific keys from the ConfigMap, not all keys. What is the best approach?

Accepted Answer

Use the 'items' field in the ConfigMap volume definition to specify which keys to include.. Option B is correct because the `items` field in a ConfigMap volume definition allows you to selectively project only specific keys from the ConfigMap into the pod's filesystem. This is the native Kubernetes mechanism for controlling which keys appear as files, avoiding the need to mount the entire ConfigMap or create a separate ConfigMap.

Answer

Use the ConfigMap to set environment variables instead of a volume mount.

Answer

Mount the entire ConfigMap and use a startup script to remove unwanted files.

Answer

Create a new ConfigMap with only the needed keys.

Question 13

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

Accepted Answer

Retain: The PV remains in the cluster and must be manually reclaimed.. Option A is correct because the Retain reclaim policy leaves the PersistentVolume (PV) in the cluster in a 'Released' state after the PersistentVolumeClaim (PVC) is deleted. The underlying storage asset (e.g., an EBS volume or NFS export) is not touched by Kubernetes, and the administrator must manually delete the PV object and then handle the storage asset (e.g., reuse or delete it) outside of Kubernetes.

Answer

Retain: The underlying storage asset is automatically deleted.

Answer

Recycle: The PV is automatically cleaned and made available for a new claim.

Answer

Delete: The PV must be manually deleted by the administrator.

Question 14

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

Accepted Answer

CSI supports both block and file volumes.. Option A is correct because 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 15

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.. Option D is correct because the pod app-db-0 is stuck in 'Pending' due to its PVC being bound to a PV that is pinned to the failed node1. Deleting both the PVC and the PV allows the StatefulSet's controller to automatically recreate the PVC, which will trigger dynamic provisioning via the 'fast-ssd' StorageClass. With volumeBindingMode 'WaitForFirstConsumer', the new PV will be provisioned on a healthy node that can schedule the pod, resolving the node affinity issue.

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 16

A DevOps team needs to deploy a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes. Which Kubernetes resource should they use to provision the storage?

Accepted Answer

A PersistentVolume with access mode ReadWriteMany. ReadWriteMany (RWX) is the only access mode that allows multiple pods across different nodes to simultaneously read and write to the same persistent storage volume. A PersistentVolume with access mode ReadWriteMany meets the requirement for a stateful application needing concurrent access from pods running on different nodes, typically backed by network filesystems like NFS, GlusterFS, or CephFS.

Answer

A hostPath volume

Answer

A PersistentVolume with access mode ReadWriteOnce

Answer

An emptyDir volume

Question 17

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 18

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. Option A is correct because 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 19

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

Accepted Answer

Delete policy: both the PV and the underlying storage are deleted.. Option A is correct because 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 20

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.. Option D is correct because 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.