CKA Practice Test 31 — 15 Questions

Question 1

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 PV uses 'hostPath', which is typically used for single-node testing and does not support multi-node access. The access mode is ReadWriteOnce (RWO), meaning the volume can be mounted as read-write by a single node. Option A is correct.

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 2

Which access mode allows multiple pods running on different nodes to read from and write to a PersistentVolume at the same time?

Accepted Answer

ReadWriteMany. Option C is correct: ReadWriteMany (RWX) allows multiple nodes to mount the volume with read-write access. Option A (RWO) allows only one node. Option B (ROX) is read-only for many nodes. Option D (RWOP) is for a single pod, not multiple nodes.

Answer

ReadOnlyMany

Answer

ReadWriteOnce

Answer

ReadWriteOncePod

Question 3

A pod is scheduled to a node that has a local SSD mounted at /mnt/ssd. The administrator wants the pod to use this SSD for ephemeral storage that is accessible only while the pod runs on this specific node. Which volume type should be used?

Accepted Answer

hostPath. A hostPath volume mounts a file or directory from the host node's filesystem into the pod. This is suitable for using node-local storage like an SSD, but note it is not portable and ties the pod to the node. emptyDir is ephemeral but uses the pod's default storage (usually disk or tmpfs), not a specific host path. configMap and secret are for configuration data.

Answer

emptyDir

Answer

configMap

Answer

secret

Question 4

You need to allow a pod to use a specific device from the host node (e.g., /dev/sdb) as a raw block device. Which volume mode should you set in the PVC?

Accepted Answer

Block. To use a raw block device, the volume mode must be 'Block'. The default is 'Filesystem'.

Answer

Device

Answer

Raw

Answer

Filesystem

Question 5

You create a StorageClass with volumeBindingMode: WaitForFirstConsumer. A PVC using this StorageClass is created but remains in 'Pending' state. The PVC expects a node with label 'disktype=ssd'. A suitable node exists. What is the MOST likely reason the PVC is still Pending?

Accepted Answer

No pod has been created that uses this PVC.. With WaitForFirstConsumer, the volume is not provisioned until a pod using the PVC is scheduled. The PVC will remain Pending until a pod references it.

Answer

The node selector on the PVC is incorrect.

Answer

The PVC requests a storage size larger than available.

Answer

The persistentVolumeReclaimPolicy is set to Retain.

Question 6

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?

Accepted Answer

The CSI driver is failing to respond in time.. A DeadlineExceeded error from the CSI driver indicates that the mount operation timed out, possibly due to network issues or driver unavailability.

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 7

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.. To use a volume as a block device, the PV and PVC must be created with volumeMode: Block. You cannot change the mode after creation; you must create a new PVC 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 8

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.. The PVC remains Pending because the PV's capacity is 1Gi, which is sufficient, and access modes match. However, the PV does not specify a storageClassName, so it is considered a 'default storage class' PV only if the cluster has a default storage class and the PV has the annotation or a matching class. Since the PVC also has no storage class, it will try to use the default storage class (if any) for dynamic provisioning, but the PV is statically provisioned without a storage class. The PVC will not bind to a PV without a matching storage class. The issue is that the PV has no storageClassName and the cluster may have a default storage class, or the PV's storage class is empty, which does not match the PVC's empty storage class? Actually, both have empty storage class, so they should match. But there is another subtlety: the PVC's storage class name is empty string, and the PV's storage class name is also empty string (since not specified). In Kubernetes, an empty string storage class name means the PV does not use any storage class, and the PVC without a storage class will try to bind to a PV with the same empty storage class. However, if the cluster has a default storage class defined, the PVC without a storage class will use that default storage class for dynamic provisioning, not static binding. The PVC will remain Pending because dynamic provisioning may not be configured or the PV is not suitable. The most likely cause is that the PV's hostPath path does not exist on the node. In CKA, hostPath PVs require the path to exist on the node where the pod runs. If the path does not exist, the PV will be created but the pod will fail. However, the PVC is Pending, not the pod. Actually, PVC binding does not depend on the hostPath path existence. The PVC will bind to the PV if capacity and access modes match and storage class matches. The PVC is Pending, meaning it's not bound. Since both have empty storage class, they should match. But if the PV is not marked as Available (e.g., it might be Released or Failed), it won't bind. The reclaim policy is Retain, so after a PVC is deleted, the PV remains in Released state, not Available. But if this is a new PV, it should be Available. Possibly the PV has been used before and is in Released state. However, the question doesn't indicate that. Another common issue: the PV's capacity is 1Gi, PVC requests 500Mi, that's fine. The access modes match. The most likely cause in a real scenario is that the PVC's storage class name is empty and the PV's storage class name is also empty, but the cluster has a default storage class, so the PVC expects dynamic provisioning from that default class, ignoring static PVs. That could cause Pending. But the correct answer should be that the PV's hostPath path does not exist on the node? That would cause pod scheduling failure, not PVC Pending. The PVC Pending is usually due to no PV matching the request. Since both have empty storage class, they should match. However, if the PV is not using a storage class (empty string) and the PVC is also empty string, they should bind. But in Kubernetes, when you don't specify a storage class in PVC, it uses the default storage class if one exists, otherwise it looks for PVs with empty storage class. So if a default storage class exists, the PVC will try to dynamically provision from that default class, not bind to a static PV with no class. That is the likely cause. So the answer is that the cluster has a default storage class, causing the PVC to ignore the static PV. But the options may include that. Let's design the options.

Options:
A: The PVC requests 500Mi but the PV has 1Gi, which is not a match? (Incorrect, PV capacity must be >= PVC, 1Gi >= 500Mi)
B: The hostPath /data/pv does not exist on any node (Incorrect, that affects pod, not PVC binding)
C: The PV's reclaim policy is Retain, so it cannot be bound to a new PVC (Partially correct: if PV is in Released state, it won't bind, but a new PV is Available)
D: The cluster has a default StorageClass defined, causing the PVC to expect dynamic provisioning instead of binding to this static PV (Correct)

Thus D is correct.

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 9

A cluster administrator runs the following command to create a PersistentVolumeClaim:
kubectl create pvc mypvc --storage-class=fast --access-modes=ReadWriteOnce --storage=1Gi
However, the PVC is created but remains in Pending state. The StorageClass 'fast' uses provisioner 'kubernetes.io/no-provisioner' (a static provisioner). What is the most likely reason?

Accepted Answer

No PersistentVolume with storage class 'fast' exists in the cluster.. The provisioner 'kubernetes.io/no-provisioner' is used for static provisioning, meaning no dynamic provisioning occurs. The StorageClass is used only to match PVs with the same storage class name. Since no PV with storage class 'fast' exists, the PVC will remain Pending until a matching PV is created manually.

Answer

The StorageClass 'fast' is not annotated as the default storage class.

Answer

The access mode must be ReadWriteMany to bind.

Answer

The PVC must specify volumeMode: Block to bind.

Question 10

Which THREE statements about PersistentVolumeClaims (PVCs) are correct?

Accepted Answer

A PVC binds to a PersistentVolume that satisfies its storage request and access modes.. PVCs request storage from PVs (A). PVCs can be used by pods once bound (B). PVCs can be expanded if the StorageClass allows (D). PVCs do not define the reclaim policy (that's on PV) (C), and PVCs are namespaced resources (E is false).

Answer

A PVC defines the reclaim policy for the underlying PersistentVolume.

Answer

A PVC is a cluster-scoped resource.

Question 11

What does the 'volumeMode: Block' setting in a PersistentVolume spec indicate?

Accepted Answer

The volume will be presented as a raw block device to the pod. Option B is correct: Block volume mode presents the volume as a raw block device, not formatted with a filesystem. Option A is incorrect; it's not a filesystem. Option C is incorrect; it does not mount via NFS. Option D is incorrect; it does not enable encryption.

Answer

The volume will be formatted with a filesystem automatically

Answer

The volume will have encryption enabled by default

Answer

The volume will be mounted using NFS protocol

Question 12

Which of the following is a valid command to create a PersistentVolume named 'pv-demo' using a YAML manifest file named 'pv.yaml'?

Accepted Answer

kubectl apply -f pv.yaml. The correct command is 'kubectl apply -f pv.yaml' which creates or updates resources defined in the manifest file. The other options use incorrect or nonexistent flags.

Answer

kubectl create pv -f pv.yaml

Answer

kubectl create persistentvolume -f pv.yaml

Answer

kubectl run pv-demo --image=pv --restart=Never

Question 13

An administrator runs 'kubectl get pv' and sees a PersistentVolume in 'Released' status. Which of the following is true about this PV?

Accepted Answer

The PV's data is still intact and the PV can be re-claimed.. A Released PV was previously bound to a PVC that has been deleted. The PV's reclaim policy determines what happens next. If the policy is Retain, the PV remains Released and must be manually reclaimed. If Delete, it will be deleted. Recycle is deprecated.

Answer

The PV has been deleted from the cluster.

Answer

The PV is automatically deleted when it becomes Released.

Answer

The PV is still bound to a PVC.

Question 14

Which TWO of the following statements about StorageClass are correct? (Select two.)

Accepted Answer

A StorageClass can be used for dynamic provisioning of PersistentVolumes.. StorageClass allows dynamic provisioning and has a reclaimPolicy that defaults to Delete. It also can specify volumeBindingMode. The provisioner field is required. So correct: A and C.

Answer

A StorageClass must have a provisioner field set to 'kubernetes.io/no-provisioner' to use static provisioning.

Answer

A StorageClass is a namespaced resource.

Answer

The reclaimPolicy in a StorageClass defaults to Retain.

Question 15

Which access mode allows a PersistentVolume to be mounted as read-write by multiple pods across different nodes?

Accepted Answer

ReadWriteMany (RWX). ReadWriteMany (RWX) allows multiple pods on different nodes to mount the volume as read-write.

Answer

ReadWriteOnce (RWO)

Answer

ReadWriteOncePod (RWOP)

Answer

ReadOnlyMany (ROX)