CKA Storage Practice Test 7 — 15 Questions

Question 1

A cluster has a CSI driver installed. A pod using a CSI volume is in CrashLoopBackOff. 'kubectl describe pod' shows: 'failed to mount volume: rpc error: code = DeadlineExceeded desc = context deadline exceeded'. What is the MOST likely cause?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The CSI driver is failing to respond in time.. The error 'context deadline exceeded' indicates that the CSI driver's gRPC call to mount the volume did not complete within the default timeout (typically 30 seconds). This is most commonly caused by the CSI driver being unresponsive due to resource starvation, network issues, or a bug in the driver itself. Since the CSI driver is installed and the pod is attempting to mount, the failure is in the driver's response time, not in the PVC binding or volume mode.

Answer

The PVC is not bound.

Answer

The CSI driver is not installed.

Answer

The volume mode is Block but the pod expects Filesystem.

Question 2

Which of the following is a required field when defining a PersistentVolume?

Accepted Answer

capacity. In Kubernetes, a PersistentVolume (PV) must define its storage capacity using the `capacity` field, which specifies the amount of storage the PV provides (e.g., `storage: 10Gi`). This is a required field because the PV represents a piece of storage in the cluster, and the scheduler and PersistentVolumeClaim (PVC) binding logic need to know the available size to match claims. Without `capacity`, the PV definition is invalid and will be rejected by the API server.

Answer

storageClassName

Answer

nodeAffinity

Answer

persistentVolumeReclaimPolicy

Question 3

What is the default reclaim policy for a PersistentVolume?

Accepted Answer

Retain. The default reclaim policy for a PersistentVolume (PV) in Kubernetes is 'Retain'. This means that when a PersistentVolumeClaim (PVC) bound to the PV is deleted, the PV will not be automatically deleted or recycled; instead, it remains in a 'Released' state, preserving the underlying storage and data for manual administrator intervention. This is defined in the PV's spec.persistentVolumeReclaimPolicy field, which defaults to 'Retain' if not explicitly set.

Answer

Recycle

Answer

None

Answer

Delete

Question 4

You have a PVC that is bound to a PV with a filesystem volume mode. You want to use the volume as a block device in a pod. What should you do?

Accepted Answer

Create a new PVC with volumeMode: Block and bind it to a new PV.. A PVC with `volumeMode: Block` must be created and bound to a PV that also has `volumeMode: Block` to use the volume as a block device in a pod. The existing PVC is bound to a PV with `volumeMode: Filesystem`, which cannot be used as a block device without recreating the underlying storage. You cannot change the volume mode of an existing PV or PVC; you must provision new resources with the correct mode.

Answer

Use a hostPath volume instead.

Answer

Set volumeDevices in the pod spec instead of volumeMounts.

Answer

Modify the PV's volumeMode to Block.

Question 5

Which THREE of the following are true about expanding a PersistentVolumeClaim?

Accepted Answer

The StorageClass must have allowVolumeExpansion: true.. Option C is correct because a PersistentVolumeClaim can only be expanded if its StorageClass explicitly sets allowVolumeExpansion: true; without this field, the API server rejects the resize request. Option D is correct because even with allowVolumeExpansion enabled, the underlying CSI or in-tree volume plugin must actually support online or offline expansion for the operation to succeed. Option E is correct because the standard way to request more capacity is to edit the PVC's spec.resources.requests.storage field to a larger value, which triggers the resize workflow. Option A is not universally true: many CSI drivers support online expansion so the pod does not need to be recreated, and only certain filesystem-resize cases require a pod restart. Option B is incorrect because Kubernetes does not support shrinking a PVC; the requested storage can only be increased, never decreased.

Answer

After expanding the PVC, the pod must be recreated for the new size to take effect.

Answer

You can reduce the size of a PVC after creation.

Question 6

Which access mode allows multiple pods to read and write to a PersistentVolume simultaneously when all pods are on the same node?

Accepted Answer

ReadWriteOnce. ReadWriteOnce (RWO) allows a PersistentVolume to be mounted as read-write by a single node, but multiple pods on that same node can all access the volume simultaneously. This is because the access mode restriction is per node, not per pod, so all pods scheduled on the same node share the same mount and can read and write concurrently.

Answer

ReadOnlyMany

Answer

ReadWriteMany

Answer

ReadWriteOncePod

Question 7

A cluster administrator creates a PersistentVolume with the following YAML:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/pv

A user creates a PersistentVolumeClaim requesting 500Mi with access mode ReadWriteOnce and no storage class. The PVC remains in Pending state. What is the most likely cause?

Accepted Answer

The cluster has a default StorageClass defined, causing the PVC to attempt dynamic provisioning instead of binding to this static PV.. When a default StorageClass exists in the cluster, a PVC with no storage class name specified will automatically trigger dynamic provisioning via that default StorageClass, rather than attempting to bind to an existing static PV. This causes the PVC to remain in Pending state if the dynamic provisioner cannot fulfill the request (e.g., due to missing CSI driver or cloud provider configuration). The static PV pv-example is ignored because the PVC's provisioning mechanism is overridden by the default StorageClass.

Answer

The PV's reclaim policy is Retain, so it is in Released state and cannot be bound to a new PVC.

Answer

The hostPath path /data/pv does not exist on any node in the cluster.

Answer

The PVC requests 500Mi, but the PV has 1Gi capacity, which is larger than requested, so the PVC cannot bind to it.

Question 8

A cluster administrator is configuring a Pod to use a PersistentVolumeClaim (PVC) that is dynamically provisioned using a StorageClass with volumeBindingMode: WaitForFirstConsumer. The PVC is created before the Pod. When the Pod is created, which node will the PV be provisioned on?

Accepted Answer

The node where the Pod is scheduled.. When a StorageClass uses volumeBindingMode: WaitForFirstConsumer, the PersistentVolume (PV) is not provisioned until a Pod that uses the PersistentVolumeClaim (PVC) is scheduled. The PV is then provisioned on the exact node where the Pod is scheduled, ensuring that the volume is created in the same zone or topology as the Pod. This avoids unnecessary cross-zone data transfer and ensures the PV is available locally to the Pod's node.

Answer

The PV is provisioned immediately on the node specified in the StorageClass's allowedTopologies.

Answer

Any node in the cluster that has sufficient resources for the PV.

Answer

The control plane node.

Question 9

A cluster administrator wants to expand an existing PersistentVolumeClaim (PVC) that is bound to a PersistentVolume (PV) with reclaim policy Delete and storage class 'fast'. The PV was dynamically provisioned. Which condition is required for the PVC expansion to succeed?

Accepted Answer

The StorageClass 'fast' must have allowVolumeExpansion: true.. For PVC expansion to succeed with a dynamically provisioned PV, the StorageClass must have the `allowVolumeExpansion: true` field set. This field explicitly enables volume expansion for all PVCs using that StorageClass. Without it, the PVC expansion request will be rejected even if other conditions are met.

Answer

The PV must be in Released state.

Answer

The reclaim policy must be changed to Retain before expansion.

Answer

The PVC must be using access mode ReadWriteOnce.

Question 10

Which volume type in Kubernetes allows a Pod to share data between its containers, with the data being deleted when the Pod is removed?

Accepted Answer

emptyDir. The emptyDir volume type is created when a Pod is assigned to a node and exists as long as the Pod is running. It provides a shared writable directory for all containers within the same Pod, and its contents are deleted when the Pod is removed from the node. This makes it the correct choice for ephemeral data sharing between containers.

Answer

hostPath

Answer

configMap

Answer

secret

Question 11

A cluster administrator creates a StorageClass with the following YAML:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Delete
volumeBindingMode: Immediate

A developer creates a PVC using this StorageClass. The PVC is created and remains in Pending state. What is the most likely cause?

Accepted Answer

The cluster is not running on AWS or the AWS cloud provider is not configured.. The StorageClass uses the provisioner `kubernetes.io/aws-ebs`, which is specific to the AWS cloud provider. If the cluster is not running on AWS or the AWS cloud provider is not properly configured (e.g., missing IAM roles, cloud-controller-manager not running), the provisioner cannot create the underlying EBS volume, leaving the PVC in a Pending state indefinitely.

Answer

The volumeBindingMode is Immediate, which requires a different access mode.

Answer

The PVC does not specify an access mode.

Answer

The reclaim policy is Delete, which prevents binding.

Question 12

A cluster administrator needs to create a PersistentVolume that can be mounted as a block device (not a filesystem) by a Pod. Which field in the PersistentVolume spec must be set to enable this?

Accepted Answer

volumeMode: Block. Setting `volumeMode: Block` in the PersistentVolume spec specifies that the volume is to be presented as a raw block device, without a filesystem. This allows a Pod to mount the volume as a block device (e.g., `/dev/sdb`) rather than a mounted directory, which is required for applications that need direct access to the underlying storage, such as databases or custom storage engines.

Answer

persistentVolumeReclaimPolicy: Retain

Answer

volumeMode: Filesystem

Answer

accessModes: ReadWriteOnce

Question 13

Which of the following is a valid CSI (Container Storage Interface) driver operation in Kubernetes?

Accepted Answer

CreateVolume. The Container Storage Interface (CSI) defines a set of standard operations that storage drivers must implement to provision, attach, mount, and manage volumes in container orchestrators like Kubernetes. `CreateVolume` is a core CSI RPC (Remote Procedure Call) that the CSI driver must support to dynamically create a new storage volume, which is then used by Kubernetes to satisfy a PersistentVolumeClaim. This operation is defined in the CSI specification and is essential for dynamic volume provisioning.

Answer

CreateDeployment

Answer

CreateService

Answer

CreatePod

Question 14

A cluster has a PersistentVolumeClaim (PVC) named 'data-claim' bound to a PersistentVolume (PV) with reclaim policy 'Retain'. The PVC is deleted. The PV now shows status 'Released'. What must be done so that the PV can be reused by a new PVC?

Accepted Answer

Delete and recreate the PersistentVolume.. When a PVC is deleted and the PV has a reclaim policy of 'Retain', the PV enters a 'Released' state, meaning it still contains the data but is no longer bound to the original PVC. The PV cannot be directly reused by a new PVC because its claim reference is still set to the deleted PVC's UID. To make the PV available again, you must manually delete and recreate the PV (or at least delete it and re-create it with a clean claimRef), which resets its status to 'Available'.

Answer

Nothing; the PV will automatically become Available after some time.

Answer

Create a new PVC with the same name.

Answer

Change the reclaim policy to Delete.

Question 15

A Pod is configured with a volume that uses a ConfigMap. The ConfigMap is updated after the Pod is running. How can the Pod access the updated data without restarting?

Accepted Answer

The Pod will automatically see the updated data within minutes.. When a ConfigMap is mounted into a Pod as a volume (without using subPath), updates to the ConfigMap are automatically reflected in the Pod's filesystem after a short delay (typically within minutes, controlled by the kubelet's sync period). However, if the ConfigMap is consumed via environment variables or mounted using subPath, the Pod must be restarted to see the changes. In this question, the volume uses a ConfigMap (presumably without subPath), so the Pod will automatically see the updated data within minutes.

Answer

The ConfigMap must be deleted and recreated.

Answer

The Node must be rebooted.

Answer

The Pod must be deleted and recreated.