CKA Practice Exam 2 — 20 Questions

Question 1

A user tries to create a pod with the YAML file that requests 2 CPUs as a limit. The cluster has a ResourceQuota named 'compute-quota' with limits.cpu: 2. The user sees the above error. What is the likely issue?

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

Accepted Answer

The current total CPU limit usage in the namespace is 1, and adding a pod with limit 2 would exceed the quota of 2.. The ResourceQuota 'compute-quota' sets a hard limit of 2 CPUs for all pods in the namespace. If the current total CPU limit usage is already 1, adding a new pod with a limit of 2 would bring the total to 3, exceeding the quota. Kubernetes enforces ResourceQuota at admission time, rejecting the pod creation to prevent the namespace from exceeding its configured limits.

Answer

The pod is requesting 2 CPUs as a request, but the quota limits requests.

Answer

The pod is being created in the wrong namespace.

Answer

The pod is trying to use more CPU than the node capacity.

Question 2

A company deploys a web application with multiple replicas in a Kubernetes cluster. Users report intermittent connectivity issues. The application pods are exposed via a ClusterIP Service. To ensure stable connectivity, which action should be taken?

Accepted Answer

Set service.spec.sessionAffinity to ClientIP. Intermittent connectivity issues with multiple replicas often stem from requests being distributed across different pods, which can break session state if the application is not stateless. Setting `service.spec.sessionAffinity` to `ClientIP` ensures that all requests from a given client IP are routed to the same pod, providing stable connectivity for stateful sessions without changing the service type or removing the ClusterIP.

Answer

Change the Service type to NodePort

Answer

Remove the ClusterIP Service and use headless service

Answer

Add a readiness probe to the pods

Question 3

Which TWO of the following are valid reasons to use a Headless Service?

Accepted Answer

To enable a client to discover all pod IPs for a StatefulSet.. A Headless Service (with `clusterIP: None`) does not provide a single stable IP or load balancing. Instead, it returns DNS A/AAAA records for all pod IPs that match the service's selector. This is essential for StatefulSets, where each pod has a unique identity and clients need to discover and connect to specific pods directly, such as in a database cluster.

Answer

To provide a single stable IP address for the service.

Answer

To expose a service externally via a cloud load balancer.

Answer

To provide load-balanced access to a set of pods.

Question 4

A Node is in NotReady state. Which action should be taken first to diagnose the issue?

Accepted Answer

kubectl describe node . When a node is in NotReady state, the first diagnostic step is to gather information about the node's current status, conditions, and recent events using `kubectl describe node `. This command reveals the node's conditions (e.g., Ready, DiskPressure, MemoryPressure), the last heartbeat timestamp, and any relevant events that may indicate the root cause, such as network issues or kubelet failures. It provides a high-level overview without requiring direct node access, making it the most efficient initial action.

Answer

Check kubelet logs on the node

Answer

Restart kubelet

Answer

Check API server logs

Question 5

Which command shows resource usage (CPU and memory) for nodes in a cluster?

Accepted Answer

kubectl top nodes. kubectl top nodes displays resource usage if metrics-server is installed.

Answer

kubectl describe nodes

Answer

kubectl logs nodes

Answer

kubectl get nodes -o wide

Question 6

Which TWO actions can help troubleshoot a service that is not reachable from within a pod?

Accepted Answer

Use kubectl exec to curl the service IP from a pod. Checking endpoints and using curl from a pod are direct troubleshooting steps.

Answer

Use kubectl delete svc and recreate

Answer

Use kubectl logs on the service pod to see application logs

Answer

Use kubectl top nodes to check resource usage

Question 7

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 8

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event '0/1 nodes are available: 1 Insufficient cpu'. What is the most likely cause?

Accepted Answer

The pod's CPU request exceeds available node CPU. The event indicates that no node has enough free CPU to satisfy the pod's CPU request.

Answer

The pod's memory limit is too low

Answer

The pod is trying to use a GPU that is not available

Answer

The kubelet on the node is not running

Question 9

A pod is in ImagePullBackOff. Which command would help determine the exact reason?

Accepted Answer

kubectl describe pod . The `kubectl describe pod ` command provides detailed information about the pod, including the container state, the exact error message from the image pull (e.g., 'ImagePullBackOff'), and the underlying reason (e.g., 'Back-off pulling image', 'manifest for image not found', or 'unauthorized: authentication required'). This is the most direct way to see the specific error without needing to access the container or parse raw events.

Answer

kubectl logs <pod>

Answer

kubectl get events

Answer

kubectl exec -it <pod> -- sh

Question 10

A pod is in CrashLoopBackOff. 'kubectl logs my-pod --previous' shows: 'Error: failed to start: exec: "/app/start.sh": stat /app/start.sh: no such file or directory'. What is the most likely cause?

Accepted Answer

The container image is missing the startup script.. The error indicates the specified entrypoint script is missing. This is often due to the container image not containing the script at the expected path, or the command/args in the pod spec referencing a non-existent file.

Answer

The pod's service account lacks permissions.

Answer

The pod's liveness probe is misconfigured.

Answer

The pod has run out of memory.

Question 11

A Pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient cpu.' Which of the following is the most likely combination of issues?

Accepted Answer

Three nodes have insufficient CPU for the pod's request, and one node has a taint not tolerated by the pod. The event message explicitly states that 1 node has a taint (node-role.kubernetes.io/control-plane) that the pod does not tolerate, and 3 nodes have insufficient CPU. This means the pod's CPU request cannot be satisfied on three nodes, and the remaining node is tainted, leaving no schedulable node. Option A correctly identifies this combination of issues.

Answer

The pod has a resource request that exceeds available CPU on all nodes

Answer

The pod does not tolerate any taints, and all nodes have taints

Answer

The cluster has only one node with sufficient CPU, but it is cordoned

Question 12

A Deployment named 'web' is failing to schedule pods. You run 'kubectl describe pod web-xyz' and see the event: '0/3 nodes are available: 3 Insufficient cpu.' What is the most likely cause?

Accepted Answer

The CPU request in the pod spec is too high. The error indicates that CPU requests are too high for the available node resources. Reducing CPU requests or adding more nodes can fix it.

Answer

The network plugin is misconfigured

Answer

The nodes have insufficient memory

Answer

The kubelet is not running on the nodes

Question 13

Refer to the exhibit. The master node shows NotReady status. The kubelet is reporting 'container runtime is down'. Which command should be used to investigate and fix this issue?

Accepted Answer

systemctl status containerd && systemctl restart containerd. The kubelet is unable to communicate with the container runtime. Since the master uses containerd (common in kubeadm), checking the containerd service status and restarting it is the first step.

Answer

kubectl delete node master && kubeadm reset

Answer

systemctl status kubelet && systemctl restart kubelet

Answer

systemctl status docker && systemctl restart docker

Question 14

A node is NotReady. Which THREE conditions could cause this?

Accepted Answer

Network plugin (e.g., Calico) is not functioning. Kubelet stopped, network plugin issues, and disk pressure can all cause a node to become NotReady.

Answer

A pod is in CrashLoopBackOff

Answer

The API server is overloaded

Question 15

A CSI driver is installed in the cluster, but a PersistentVolumeClaim using a StorageClass that references this driver remains Pending. The administrator checks the logs of the CSI controller pod and sees no errors. What is a possible cause?

Accepted Answer

The StorageClass volumeBindingMode is set to WaitForFirstConsumer.. If the volumeBindingMode is set to WaitForFirstConsumer, the PV will not be provisioned until a pod using the PVC is scheduled. This is a common pitfall. The CSI driver may be working fine, but the binding mode delays provisioning.

Answer

The CSI driver is not registered correctly.

Answer

The StorageClass volumeBindingMode is set to Immediate.

Answer

The PVC requests a size that is not available.

Question 16

A company runs a batch job that processes a queue. The job should run to completion exactly once. Which resource should be used?

Accepted Answer

Job. A Kubernetes Job is designed to run a specified number of pods to successful completion. When the pod exits with a zero exit code, the Job is marked as complete and will not be restarted, making it the correct choice for a batch job that must run exactly once.

Answer

DaemonSet

Answer

CronJob

Answer

Deployment

Question 17

You run 'kubectl logs my-pod -c my-container' and get no output, but you know the container produces logs. What should you do next to see previous container logs?

Accepted Answer

kubectl logs my-pod -c my-container --previous. The --previous flag retrieves logs from the previous instance of a crashed container.

Answer

kubectl logs my-pod -c my-container -f

Answer

kubectl logs my-pod -c my-container --tail=50

Answer

kubectl logs my-pod -c my-container --all-containers

Question 18

Which TWO commands show cluster events that can help in troubleshooting?

Accepted Answer

kubectl describe pod . Option E, `kubectl get events`, is correct because it directly lists the cluster's event stream (backed by the Events API), showing scheduling failures, image pull errors, probe failures, and other warnings tied to specific resources. Option D, `kubectl describe pod `, is correct because its output includes an Events section at the bottom that surfaces the same per-pod events with timestamps, reasons, and messages, which is essential for troubleshooting a specific pod. Option A, `kubectl cluster-info`, only prints the addresses of the control plane and core add-ons, providing no event data. Option B, `kubectl logs `, shows application/container stdout and stderr, not Kubernetes cluster events. Option C, `kubectl top pods`, reports CPU and memory usage metrics from the metrics server, which is resource data rather than events.

Answer

kubectl cluster-info

Answer

kubectl logs <pod-name>

Answer

kubectl top pods

Question 19

An administrator needs to initialize a new Kubernetes control plane node using kubeadm. Which of the following is the correct command to initialize the control plane with a specific pod network CIDR of 10.244.0.0/16?

Accepted Answer

kubeadm init --pod-network-cidr=10.244.0.0/16. `kubeadm init` uses the `--pod-network-cidr` flag to specify the CIDR range for the pod network, which is required by many CNI plugins (e.g., Flannel defaults to 10.244.0.0/16). This flag tells kubeadm to configure the control plane components (like the controller manager) to allocate pod IPs from this range.

Answer

kubeadm init --cidr=10.244.0.0/16

Answer

kubeadm init --network-cidr=10.244.0.0/16

Answer

kubeadm init --service-cidr=10.244.0.0/16

Question 20

You have a cluster with multiple worker nodes. You need to upgrade the cluster from v1.28.0 to v1.29.0 using kubeadm. What is the correct sequence of steps?

Accepted Answer

Upgrade kubeadm on the control plane node, upgrade control plane components, then drain and upgrade each worker node by upgrading kubelet and kubectl.. The official kubeadm upgrade workflow requires upgrading kubeadm first on the control plane node, then using `kubeadm upgrade apply` to upgrade control plane components, and finally draining and upgrading each worker node by updating kubelet and kubectl. This sequence ensures the cluster's management plane is updated before worker nodes, maintaining control plane stability and API compatibility during the rolling upgrade.

Answer

Upgrade kubeadm on the control plane node, then upgrade kubelet and kubectl on worker nodes, then upgrade kubelet and kubectl on control plane node.

Answer

Drain all nodes, upgrade kubelet and kubectl on all nodes, then upgrade kubeadm on the control plane node.

Answer

Upgrade kubelet and kubectl on all nodes first, then upgrade kubeadm on the control plane node.