CKA Practice Exam 52 — 20 Questions

Question 1

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

Question 2

A pod is configured to use a PersistentVolumeClaim (PVC). The PVC is bound to a PersistentVolume (PV) that uses a cloud disk. The pod fails to start with the error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32'. What is the most likely cause?

Accepted Answer

The underlying storage device is still attached to a previous node. The error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32' typically indicates a filesystem-level mount failure. When a cloud disk (e.g., AWS EBS, GCE PD) is still attached to a previous node, the new node cannot mount it because the disk is already in use or has a stale filesystem lock. Kubernetes requires the disk to be detached from the old node before it can be attached and mounted on the new node.

Answer

The PV's access mode is ReadOnlyMany

Answer

The PV is not created

Answer

The PVC is unbound

Question 3

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.. Option B is correct because 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 4

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 5

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.. Option B is correct because 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 6

A pod is unable to start because the PersistentVolumeClaim it references is still in 'Pending' state. What is the most likely cause?

Accepted Answer

The PersistentVolumeClaim's storage class does not exist or cannot provision a volume. A PersistentVolumeClaim (PVC) remains in 'Pending' state when it cannot find a suitable PersistentVolume (PV) to bind to or when its storage class cannot dynamically provision one. The most common cause is that the referenced storage class does not exist, is misspelled, or lacks a provisioner that can create the volume, leaving the PVC unbound and the pod unable to start.

Answer

The pod's YAML has a syntax error

Answer

The pod is using a hostPath volume

Answer

The node has insufficient CPU resources

Question 7

A team is designing a storage solution for a Cassandra cluster on Kubernetes. Each pod must have its own dedicated storage, and the cluster must be able to scale up and down dynamically. Which Kubernetes resource should be used to manage the storage?

Accepted Answer

StatefulSet with a volumeClaimTemplate. StatefulSet is the correct choice because it provides stable, unique network identities and dedicated storage for each pod via a volumeClaimTemplate. This ensures each Cassandra pod gets its own PersistentVolume, which is essential for stateful applications that require data persistence and ordered scaling. The volumeClaimTemplate automatically provisions a unique PersistentVolumeClaim for each replica, enabling dynamic scaling up and down while preserving data integrity.

Answer

ReplicaSet with emptyDir volumes

Answer

DaemonSet with hostPath volumes

Answer

Deployment with a single PersistentVolume shared by all pods

Question 8

Match each cluster upgrade step to its purpose.

Question 9

A pod is stuck in ContainerCreating. Which condition is most likely if `kubectl describe pod` shows 'Failed to create pod sandbox'?

Accepted Answer

CNI plugin issue. The error 'Failed to create pod sandbox' indicates that the container runtime (e.g., containerd or CRI-O) was unable to set up the necessary Linux namespaces and cgroups for the pod. This is almost always caused by a CNI plugin issue, such as a misconfigured or missing network plugin (e.g., Calico, Flannel, Weave), which prevents the sandbox from being initialized. Image pull failures produce 'ErrImagePull' or 'ImagePullBackOff', not sandbox creation errors.

Answer

Image pull failure

Answer

Node disk pressure

Answer

Incorrect security context

Question 10

A pod is stuck in Pending state. You describe the pod and see: '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.' What is the most likely reason?

Accepted Answer

All nodes in the cluster are NotReady. The error message '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate' indicates that every node in the cluster is tainted with node.kubernetes.io/not-ready, which is automatically applied by the node controller when a node becomes unreachable or fails its health checks. Since no node is Ready, the pod cannot be scheduled, and the only way to schedule it would be to add a toleration for this taint, but that would not fix the underlying node issue. Therefore, the most likely reason is that all nodes are in the NotReady state.

Answer

The pod needs a toleration for node.kubernetes.io/not-ready

Answer

The pod has a resource request that cannot be met

Answer

The scheduler is not running

Question 11

A Pod is stuck in CrashLoopBackOff. You run `kubectl logs <pod-name>` but see no output. What is the most likely cause?

Accepted Answer

The container crashes before writing to stdout/stderr.. When a container crashes before it can write any output to stdout or stderr, `kubectl logs` returns no output because there is no log data to retrieve. This is a common symptom of a container that fails during initialization or immediately upon entry point execution, before any logging occurs.

Answer

The pod has no container defined.

Answer

The kubelet is not forwarding logs.

Answer

The pod is in a different namespace.

Question 12

A Deployment's pods are failing with 'CrashLoopBackOff'. The container exits with code 1. Which two approaches will help identify the issue? (Choose two.)

Accepted Answer

kubectl logs . A is correct because `kubectl logs ` retrieves the container's stdout/stderr output, which often contains the error message or stack trace that caused exit code 1. This is the first step in debugging a CrashLoopBackOff, as it reveals what the application printed before terminating.

Answer

kubectl get pods -o wide

Answer

kubectl edit deployment <deploy>

Question 13

A Service of type ClusterIP is not reachable from within the cluster. Pods backing the Service are running and healthy. What is the most likely cause?

Accepted Answer

kube-proxy not running or misconfigured. When Pods are healthy but a ClusterIP Service is unreachable from within the cluster, the most common cause is that kube-proxy is not running or is misconfigured. kube-proxy is responsible for implementing the ClusterIP virtual IP by programming iptables (or IPVS) rules on each node to forward traffic to the selected Pods. Without these rules, packets destined for the ClusterIP are dropped or rejected, even though the Service and Endpoints objects exist.

Answer

DNS resolution failure

Answer

Ingress controller not set up

Answer

Service type should be NodePort

Question 14

You have a Deployment that is not scaling up beyond 1 replica despite setting replicas: 3. Which of the following could be the cause? (Select all that apply)

Accepted Answer

A ResourceQuota in the namespace limits the number of pods. A ResourceQuota in the namespace can limit the total number of Pods that can be created. If the quota is set to a value that allows only one Pod (or the current count already meets the quota), the Deployment cannot scale beyond 1 replica. This is enforced by the API server during Pod creation, and the ReplicaSet controller will see the quota limit and stop creating additional Pods.

Answer

A PodDisruptionBudget is set with minAvailable: 1

Question 15

A Service of type LoadBalancer is created but the EXTERNAL-IP remains <pending>. The cluster is running on-premises without a cloud load balancer integration. Which of the following is the most likely reason?

Accepted Answer

No load balancer controller (e.g., MetalLB) is installed.. A Service of type LoadBalancer in Kubernetes requires an external load balancer controller to provision an external IP address. In on-premises clusters without cloud integration, no such controller exists by default, so the EXTERNAL-IP remains <pending> until a bare-metal load balancer like MetalLB is installed and configured. Option C is correct because without a load balancer controller, Kubernetes cannot assign an external IP.

Answer

The cluster has no default storage class.

Answer

The nodes are not reachable from the internet.

Answer

The Service selector does not match any pods.

Question 16

A pod is in CrashLoopBackOff state. Which command shows the last termination reason?

Accepted Answer

kubectl describe pod . The `kubectl describe pod ` command displays detailed information about the pod, including the container state transitions and the last termination reason in the `Last State` field under the container status. This is the correct way to see why the container previously exited, which is essential for diagnosing a CrashLoopBackOff.

Answer

kubectl logs <pod>

Answer

kubectl get pod <pod> -o yaml

Answer

kubectl top pod <pod>

Question 17

Based on the exhibit, the pod is in CrashLoopBackOff. Which command should you run NEXT to identify the root cause?

Accepted Answer

kubectl logs api-6f4d7b9d4c-abcde -n production --previous. The pod is in CrashLoopBackOff, which means the container starts, crashes, and restarts repeatedly. The `kubectl logs --previous` command retrieves the logs from the previous (crashed) container instance, which is the fastest way to see the error that caused the crash. This directly reveals the root cause, such as a missing dependency, configuration error, or application panic.

Answer

kubectl describe node node-1

Answer

kubectl top pod api-6f4d7b9d4c-abcde -n production

Answer

kubectl get deployment api -n production -o yaml

Question 18

Drag and drop the steps to back up and restore etcd data for a Kubernetes cluster into the correct order.

Question 19

Drag and drop the steps to set up a PersistentVolumeClaim for a pod into the correct order.

Question 20

A developer reports that a newly deployed Deployment named 'web-app' is not serving traffic. The Deployment has 3 replicas, a Service of type ClusterIP, and an Ingress. Which TWO commands should you run first to diagnose the issue?

Accepted Answer

kubectl describe svc web-app. Option A is correct because `kubectl describe svc web-app` shows the Service's ClusterIP, port mapping, and endpoint list. If the endpoints are empty, the Service has no healthy Pods to route traffic to, which is a common cause of traffic failure. This command directly checks whether the Service is correctly wired to the Pods.

Answer

kubectl logs deployment/web-app

Answer

kubectl get events --sort-by='.lastTimestamp'

Answer

kubectl describe ingress web-app