CKA Practice Test 6 — 10 Questions

Question 1

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?

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

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 2

You are managing a Kubernetes cluster that hosts a microservices application. One of the services, 'payment-processor', is critical and must always be available. It has a Deployment with 3 replicas, each requesting 1 CPU and 2Gi memory. Recently, the team added a new service 'data-analyzer' that runs as a DaemonSet on all nodes, consuming significant CPU and memory. After the addition, you notice that 'payment-processor' pods are occasionally being evicted, and new pods are slow to be scheduled. You check node resource usage and find that some nodes are overcommitted. You want to ensure that 'payment-processor' pods are never evicted and are scheduled before less critical workloads. Which action should you take?

Accepted Answer

Create a PriorityClass with a high value and assign it to the 'payment-processor' Deployment. PriorityClass with a high value ensures that 'payment-processor' pods are considered higher priority than other pods during scheduling and eviction. When nodes are overcommitted, the Kubernetes scheduler will preempt lower-priority pods to make room for higher-priority pods, and the kubelet will evict lower-priority pods first when resources are scarce. This directly addresses the requirement that 'payment-processor' pods are never evicted and are scheduled before less critical workloads.

Answer

Add a taint to nodes that have low resources and add tolerations only to 'payment-processor' pods

Answer

Increase the resource requests for 'payment-processor' pods to guarantee resources

Answer

Use node affinity to ensure 'payment-processor' pods run on dedicated nodes

Question 3

A pod is in 'Pending' state. 'kubectl describe pod' shows: '0/3 nodes are available: 1 Insufficient memory, 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' Which THREE actions would resolve the issue? (Choose three)

Accepted Answer

Remove the taint from the control-plane nodes.. The pod cannot be scheduled because one node lacks memory and two nodes have a control-plane taint. Any single action that resolves either the memory issue (decreasing memory request) or the taint issue (removing taint or adding toleration) will make a node available. Since the question asks for three actions, A, B, and D are the correct choices as each independently resolves the scheduling block. Options C and E do not address the reported problems.

Answer

Increase the CPU request of the pod.

Answer

Add a node selector to the pod that matches the control-plane nodes.

Question 4

Which TWO of the following are valid commands to view cluster events sorted by timestamp?

Accepted Answer

kubectl get events. Options A and B are correct. 'kubectl get events' shows events sorted by last timestamp by default, which satisfies the requirement. 'kubectl get events --sort-by=.metadata.creationTimestamp' explicitly sorts by creation timestamp, also valid. Option C uses -w to watch, not sort. Option D sorts by name, not timestamp. Option E shows events from all namespaces but does not sort by timestamp.

Answer

kubectl get events -w

Answer

kubectl get events --sort-by=.metadata.name

Answer

kubectl get events --all-namespaces

Question 5

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. Which command would help you determine the exact reason for the image pull failure?

Accepted Answer

kubectl describe pod . A is correct because 'kubectl describe pod ' provides detailed information about the pod, including the container status, events, and the exact error message from the image pull attempt. This output includes the reason for the ImagePullBackOff, such as a missing image, incorrect tag, authentication failure, or network issue, which is essential for troubleshooting.

Answer

kubectl top pod <pod-name>

Answer

kubectl logs <pod-name>

Answer

kubectl get events

Question 6

You run 'kubectl logs pod-name' and get no output. Which TWO steps should you take to troubleshoot further?

Accepted Answer

Run 'kubectl describe pod pod-name' to check container state and events. Run 'kubectl describe pod pod-name' (option C) to check container state and events, and 'kubectl logs --previous pod-name' (option D) to retrieve logs from the previous container instance if the pod restarted. These are the two most direct steps to troubleshoot missing logs.

Answer

Run 'kubectl get events --all-namespaces'

Answer

Run 'kubectl top pod pod-name' to check resource usage

Answer

Run 'kubectl exec pod-name -- cat /var/log/container.log'

Question 7

A pod is in 'ImagePullBackOff' state. Which of the following is NOT a common cause?

Accepted Answer

The container requires more memory than the limit allows. Insufficient memory would cause OOMKilled, not ImagePullBackOff. ImagePullBackOff is caused by issues pulling the container image: wrong image name (C), nonexistent tag (B), authentication failure (A), or registry unreachable. Options A, B, and C are all common causes of ImagePullBackOff.

Answer

The image registry requires authentication and no imagePullSecrets are configured

Answer

The image tag does not exist

Answer

The image name is misspelled

Question 8

You have a multi-node cluster. One node shows 'NotReady'. You run 'journalctl -u kubelet' on that node and see 'network plugin is not ready'. What is the most likely cause?

Accepted Answer

The CNI plugin pod (e.g., Calico) is not running on that node. The 'network plugin is not ready' error from kubelet indicates that the kubelet is waiting for a CNI (Container Network Interface) plugin to configure the pod network. If the CNI plugin pod (e.g., Calico, Flannel, Weave) is not running on that specific node, the kubelet cannot set up the network for pods, causing the node to remain in 'NotReady' state. This is the most direct cause because the kubelet relies on the CNI plugin to report readiness before marking the node as Ready.

Answer

The container runtime (e.g., containerd) is down

Answer

The kubelet service is not running

Answer

The node's IP address has changed

Question 9

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in a CrashLoopBackOff state with an 'OOMKilled' message, which indicates that the container's memory usage exceeded its configured memory limit, causing the kernel's Out-Of-Memory (OOM) killer to terminate the process. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause of the crash loop.

Answer

Delete the namespace and redeploy all workloads

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container

Question 10

You are troubleshooting a node that shows 'NotReady' status. Which TWO commands can help you investigate the kubelet state?

Accepted Answer

journalctl -u kubelet. journalctl -u kubelet (C) retrieves kubelet logs from the systemd journal, showing errors and warnings. systemctl status kubelet (D) displays the current status of the kubelet service, including whether it is running, enabled, and recent log entries. The other options: 'kubectl get nodes' (A) shows node status but not kubelet details; 'journalctl -u docker' (B) shows container runtime logs, not kubelet; 'kubectl describe pod' (E) is for pod details, not node-level kubelet troubleshooting.

Answer

kubectl get nodes

Answer

journalctl -u docker

Answer

kubectl describe pod