CKA Storage Practice Test 2 — 15 Questions

Question 1

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

An administrator needs to create a PersistentVolume with 10Gi capacity, ReadWriteOnce access mode, and a reclaim policy of Retain. Which YAML snippet correctly defines this PV?

Accepted Answer

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /data/pv. It defines a PersistentVolume with the required 10Gi capacity, ReadWriteOnce access mode (using the correct plural 'accessModes' field), and the Retain reclaim policy. The hostPath volume type is also specified correctly.

Answer

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

Answer

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

Answer

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

Question 10

A PersistentVolumeClaim named 'my-pvc' is created and remains in 'Pending' state. Which command should the administrator use to investigate the reason?

Accepted Answer

kubectl describe pvc my-pvc. `kubectl describe pvc my-pvc` provides detailed events and status information for the PVC, including any errors or conditions that prevent it from binding to a PersistentVolume (PV). A 'Pending' state typically indicates that the PVC cannot find a matching PV or that the storage class is not available, and the describe command surfaces these reasons in the 'Events' section.

Answer

kubectl get pv

Answer

kubectl get pvc my-pvc -o yaml

Answer

kubectl describe pod my-pvc

Question 11

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 12

An administrator runs 'kubectl get pvc' and sees a PVC with status 'Lost'. What does this status indicate?

Accepted Answer

The PV that was bound to the PVC has been deleted or is no longer available. A PVC with status 'Lost' indicates that the PersistentVolume (PV) it was bound to has been deleted or is no longer available. This breaks the binding between the PVC and the PV, leaving the PVC in a state where it cannot be used until the PV is restored or the PVC is recreated. The 'Lost' status is specific to this scenario and does not occur due to size mismatches, pod deletion, or storage class issues.

Answer

The PVC requested more storage than the available PV can provide

Answer

The pod using the PVC has been deleted

Answer

The PVC's storage class does not match any available PV

Question 13

A new StorageClass 'fast' is created with volumeBindingMode: WaitForFirstConsumer. A PVC using this StorageClass is created but no pod consumes it. What is the state of the PVC immediately after creation?

Accepted Answer

Pending. When a StorageClass uses volumeBindingMode: WaitForFirstConsumer, the PVC will remain in a Pending state until a pod that uses it is scheduled. This is because the volume binding and provisioning are deferred until the first consumer (pod) is created, allowing the scheduler to consider the pod's node constraints when selecting the volume. Since no pod consumes the PVC immediately after creation, it stays Pending.

Answer

Bound

Answer

Lost

Answer

The PVC will not be created

Question 14

An administrator applies the following YAML:
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: ""
---
What does setting storageClassName to an empty string achieve?

Accepted Answer

It ensures the PVC binds only to a PV with no storage class defined. Setting `storageClassName` to an empty string (`""`) explicitly tells Kubernetes to bind the PVC only to a PV that also has no `storageClassName` defined (i.e., a static PV with an empty or omitted storage class). This bypasses any default StorageClass in the cluster, preventing dynamic provisioning and ensuring the PVC matches only pre-provisioned PVs with no storage class.

Answer

It disables storage for the PVC

Answer

It triggers dynamic provisioning using the default StorageClass

Answer

It assigns the default StorageClass automatically

Question 15

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