CKA Storage Practice Test 6 — 15 Questions

Question 1

Which TWO of the following are valid volumeBindingMode values for a StorageClass?

Accepted Answer

WaitForFirstConsumer. The `volumeBindingMode` field in a StorageClass determines when volume binding and dynamic provisioning occur. `WaitForFirstConsumer` is valid and delays binding until a pod using the PVC is scheduled, which is essential for topology-aware volumes like those in multi-zone clusters. `Immediate` is also valid and is the default mode, binding the volume as soon as the PVC is created.

Answer

Lazy

Answer

OnDemand

Answer

Deferred

Question 2

An administrator creates a PersistentVolume with the following YAML:

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

Which of the following is true about this PersistentVolume?

Accepted Answer

It can be mounted as read-write by only one node at a time.. The PersistentVolume specifies `accessModes: ReadWriteOnce`, which means the volume can be mounted as read-write by only a single node at a time. This is a Kubernetes access mode that restricts the volume to a single consumer (node) for read-write operations, preventing concurrent access from multiple nodes.

Answer

It can be mounted as read-write by multiple nodes simultaneously.

Answer

The PV will be automatically deleted when its PVC is released.

Answer

The PV supports dynamic provisioning.

Question 3

A user creates a PersistentVolumeClaim (PVC) with the following YAML:

```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
```

They then run 'kubectl get pvc' and see that the PVC is 'Pending'. Which is the most likely cause?

Accepted Answer

No PersistentVolume exists with sufficient capacity or matching access modes.. A PVC enters 'Pending' state when Kubernetes cannot bind it to a PersistentVolume (PV). The most common cause is that no existing PV matches the PVC's requested storage capacity (10Gi) and access mode (ReadWriteOnce). The scheduler does not dynamically provision a PV unless a StorageClass is specified; without one, the PVC waits indefinitely for a matching PV.

Answer

The node where the pod will run does not have enough CPU.

Answer

The pod that will use the PVC is in CrashLoopBackOff.

Answer

The PVC's name is too long for Kubernetes.

Question 4

An administrator needs to configure dynamic provisioning for persistent volumes using an external CSI driver. Which of the following is the correct approach?

Accepted Answer

Create a StorageClass with 'provisioner' set to the CSI driver name.. Dynamic provisioning in Kubernetes requires a StorageClass object that references the CSI driver as its provisioner. When a PVC requests a StorageClass with a CSI provisioner, the CSI external-provisioner sidecar automatically creates a PersistentVolume and binds it to the PVC. Without the StorageClass, Kubernetes has no way to know which CSI driver should handle the provisioning request.

Answer

Set the 'volumeBindingMode' to 'Immediate' in the PVC.

Answer

Install the CSI driver and then all PVCs will automatically be provisioned.

Answer

Create a PersistentVolume with the CSI driver name in the 'csi' section.

Question 5

Which THREE statements about PersistentVolumeClaims (PVCs) are correct?

Accepted Answer

A PVC binds to a PersistentVolume that satisfies its storage request and access modes.. A PersistentVolumeClaim (PVC) binds to a PersistentVolume (PV) only when the PV satisfies the PVC's requested storage size and access modes (e.g., ReadWriteOnce, ReadOnlyMany, ReadWriteMany). The binding is a one-to-one mapping, and the PVC remains unbound until a matching PV is available or dynamically provisioned.

Answer

A PVC defines the reclaim policy for the underlying PersistentVolume.

Answer

A PVC is a cluster-scoped resource.

Question 6

An administrator wants to configure a StatefulSet with persistent storage using volumeClaimTemplates. Which THREE statements are correct?

Accepted Answer

The PVC names are generated as '--'.. When volumeClaimTemplates are used in a StatefulSet, Kubernetes generates PVC names by concatenating the template name, the StatefulSet name, and the ordinal index of the Pod, separated by hyphens. This naming convention ensures each Pod gets a unique, predictable PVC name, which is essential for stateful workloads where each replica requires its own persistent storage.

Answer

All replicas share the same PVC if volumeClaimTemplates is used.

Answer

The reclaim policy for the volumes is defined in the volumeClaimTemplates.

Question 7

Which TWO access modes are valid for PersistentVolumes?

Accepted Answer

ReadWriteOnce. (ReadWriteOnce) is correct because it is one of the three standard access modes defined in the Kubernetes PersistentVolume (PV) specification. ReadWriteOnce allows the volume to be mounted as read-write by a single node, which is the most common access mode for block storage (e.g., AWS EBS, GCE PD). This mode is widely used for stateful workloads that require exclusive node-level access.

Answer

WriteMany

Answer

ReadOnlyOnce

Answer

ReadWriteOncePod

Question 8

Which THREE statements about StorageClasses are true?

Accepted Answer

A StorageClass can specify a provisioner to enable dynamic volume provisioning.. A StorageClass definition includes a `provisioner` field that specifies which volume plugin (e.g., `kubernetes.io/aws-ebs`, `kubernetes.io/gce-pd`, or `rancher.io/local-path`) should be used to dynamically provision a PersistentVolume when a PersistentVolumeClaim references that StorageClass. Additionally, the `volumeBindingMode` field can be set to `WaitForFirstConsumer`, which delays PV creation and binding until a pod using the PVC is scheduled. The `reclaimPolicy` field in a StorageClass determines what happens to dynamically provisioned PVs when the PVC is deleted; it can be set to `Delete` or `Retain`. These fields are configurable in a StorageClass, making C, D, and E true.

Answer

Only cluster administrators can create StorageClasses.

Answer

StorageClasses are namespaced resources.

Question 9

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 10

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.. 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 11

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

Accepted Answer

Retain: The PV remains in the cluster and must be manually reclaimed.. 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 12

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 13

You are a cluster administrator managing a production Kubernetes cluster that hosts a stateful application using StatefulSets with PersistentVolumeClaims (PVCs) backed by a cloud provider's persistent disk. A developer reports that a new pod in the StatefulSet is stuck in 'Pending' state. You describe the StatefulSet and see that it has 3 replicas. Two pods are Running, but the third pod (pod-2) is Pending. You check the PVC for pod-2 and see it is 'Pending'. The StorageClass uses 'WaitForFirstConsumer' volume binding mode. The node where pod-2 should run has sufficient resources. Other PVCs in the same namespace bound successfully. What is the most likely cause of the pending PVC and pod?

Accepted Answer

The PV that should bind to the PVC has a nodeAffinity that does not match any available node.. With 'WaitForFirstConsumer' volume binding mode, the PVC binding is deferred until a pod using it is scheduled. The PV that should bind to the PVC has a nodeAffinity that does not match any available node, preventing the scheduler from binding the PVC and scheduling the pod. This results in both the PVC and pod remaining in 'Pending' state, even though the node has sufficient resources.

Answer

The CSI driver is not installed on the node where pod-2 is scheduled.

Answer

The PVC's requested storage size exceeds the available capacity in the cloud provider's quota.

Answer

The PVC's access mode is ReadWriteOnce, but the pod requires ReadWriteMany.

Question 14

A developer accidentally runs 'kubectl delete pvc data-claim'. What is the immediate effect on the PersistentVolume pv-data?

Accepted Answer

The PV pv-data enters the Released state and is not deleted.. When a PVC is deleted, the associated PV enters the 'Released' state, not 'Available'. This is because the PV still contains data from the previous claim (the retain policy is 'Retain' by default), and Kubernetes does not automatically delete or reuse it. The PV remains in 'Released' until an administrator manually clears the claimRef or deletes the PV.

Answer

The PV pv-data is automatically deleted.

Answer

The PV pv-data remains Bound to the deleted PVC.

Answer

The PV pv-data immediately becomes Available and can be reused.

Question 15

An application requires a persistent volume that can be shared across multiple Pods running on different nodes, with read-write access from all Pods simultaneously. Which access mode should be specified in the PersistentVolumeClaim?

Accepted Answer

ReadWriteMany. The correct access mode is ReadWriteMany (RWX), which allows the volume to be mounted as read-write by multiple Pods across different nodes simultaneously. This matches the requirement for shared concurrent read-write access from all Pods.

Answer

ReadWriteOncePod

Answer

ReadOnlyMany

Answer

ReadWriteOnce