CKA Storage — Timed 30 Questions

Question 1

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?

30 minute time limit — choose an answer to begin.

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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

Question 14

Drag and drop the steps to perform a rolling update of a Deployment using kubectl into the correct order.

Accepted Answer

Update YAML, then Apply YAML, then Monitor status, then Check history, then Rollback if needed. The correct sequence for a rolling update is: update the YAML, apply it, monitor the rollout status, check the rollout history, and rollback if necessary. This ensures changes are properly applied and validated before considering a revert.

Answer

Apply YAML, then Update YAML, then Monitor status, then Check history, then Rollback if needed

Answer

Update YAML, then Monitor status, then Apply YAML, then Check history, then Rollback if needed

Answer

Update YAML, then Apply YAML, then Check history, then Monitor status, then Rollback if needed

Question 15

Match each etcd operation to its description.

Accepted Answer

snapshot: Creates a point-in-time backup of etcd data.. etcd is the key-value store for cluster state; these operations are vital for backup and recovery.

Answer

snapshot: Reclaims storage space by freeing unused pages.

Answer

compact: Creates a point-in-time backup of etcd data.

Question 16

Match each cluster upgrade step to its purpose.

Accepted Answer

Upgrade kubeadm: Update the cluster administration tool. A cluster upgrade typically follows the order: upgrade kubeadm, then control plane nodes, then worker nodes. Common confusions include mixing the purposes of kubeadm (admin tool) and kubelet (node agent), or confusing control plane upgrades with workload upgrades.

Answer

Upgrade kubeadm: Upgrade the node agent (kubelet) on each node

Answer

Upgrade control plane nodes: Upgrade workloads running on the cluster

Answer

Upgrade kubelet: Update the cluster administration tool (kubeadm)

Question 17

A StatefulSet named 'web' uses volumeClaimTemplates to dynamically provision PVCs. After updating the StatefulSet to increase the storage request from 1Gi to 5Gi, the existing pods' PVCs still show 1Gi. What is the most likely reason?

Accepted Answer

volumeClaimTemplates only apply when a new pod is created; existing PVCs are not modified. In Kubernetes, the `volumeClaimTemplates` field of a StatefulSet is immutable. To change it, administrators typically have to delete the StatefulSet without deleting the pods (using `--cascade=orphan`) and then recreate it with the updated template. Even after doing this, existing PVCs are not modified because `volumeClaimTemplates` are only evaluated when creating new PVCs for new Pods. To actually resize the existing volumes, the PVCs themselves must be edited directly (provided the StorageClass supports `allowVolumeExpansion`).

Answer

Expanding PVCs is not supported by StatefulSets

Answer

The StorageClass must have allowVolumeExpansion set to true

Answer

The StatefulSet must be deleted and recreated to apply changes

Question 18

A CSI driver is installed in the cluster. Which Kubernetes resource is used to register the CSI driver with the kubelet on each node?

Accepted Answer

CSIDriver. The CSIDriver object is a cluster-level resource that advertises a CSI driver's capabilities and identity to the kubelet on each node. When a CSI driver is installed, it creates a CSIDriver object that the kubelet uses to determine which CSI driver to call for volume operations, such as NodePublishVolume. Without this registration, the kubelet would not know which CSI driver endpoint to contact on the node.

Answer

StorageClass

Answer

CSINode

Answer

VolumeAttachment

Question 19

An admin runs: kubectl edit pvc my-pvc --namespace=default and changes spec.resources.requests.storage from 10Gi to 20Gi. The PVC's StorageClass has allowVolumeExpansion: true. What else is required for the expansion to take effect?

Accepted Answer

The pod using the PVC must be restarted to detect the new size. When a PVC is expanded via `kubectl edit`, the underlying volume (e.g., EBS, GCE PD) is resized by the CSI driver, but the filesystem inside the pod is not automatically resized. The pod must be restarted (or the filesystem manually resized) so that the kernel re-reads the block device size and the pod can use the new capacity. Without a restart, the pod continues to see the old 10Gi size.

Answer

The pod using the PVC must be deleted and recreated

Answer

No further action is needed; the PVC size will update immediately

Answer

The CSI driver must be updated to support expansion

Question 20

A PersistentVolumeClaim named 'pvc-data' is stuck in Pending state. Running 'kubectl describe pvc pvc-data' shows: 'waiting for a volume to be created, either by external provisioner or by manually creating a PersistentVolume'. The cluster has a default StorageClass named 'fast-ssd' with a provisioner 'kubernetes.io/gce-pd'. What is the most likely cause?

Accepted Answer

The volumeBindingMode is set to WaitForFirstConsumer.. When a StorageClass has volumeBindingMode set to WaitForFirstConsumer, the PersistentVolumeClaim will remain in Pending state until a pod that uses the PVC is scheduled. The describe output 'waiting for first consumer to be created before binding' confirms that the volume binding is delayed until a consumer pod is created.

Answer

The cluster has no nodes with the required storage driver.

Answer

The PVC requests a capacity that exceeds the available quota.

Answer

The PVC's storage class name is misspelled.