CKA Troubleshooting Practice Test 12 — 15 Questions

Question 1

You need to check the current resource usage of nodes in your cluster. Which command should you use?

Accepted Answer

kubectl top nodes. `kubectl top nodes` retrieves and displays real-time CPU and memory usage metrics for all nodes in the cluster, directly answering the question about current resource usage. This command relies on the metrics server being deployed in the cluster to collect resource utilization data from kubelets via the Summary API.

Answer

kubectl top pods

Answer

kubectl get events

Answer

kubectl get nodes -o wide

Question 2

A pod is in 'ImagePullBackOff' state. You run 'kubectl describe pod' and see the event: 'Failed to pull image "nginx:latest": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 8.8.8.8:53: no such host'. What is the MOST likely cause?

Accepted Answer

DNS resolution is failing on the node. The error message 'no such host' when trying to resolve 'registry-1.docker.io' on DNS server 8.8.8.8:53 indicates that the node's DNS resolution is failing. Kubernetes nodes rely on DNS to resolve container registry hostnames; if the node cannot resolve the registry's domain, the container runtime cannot pull the image, resulting in ImagePullBackOff. This is a node-level DNS issue, not a container runtime or image tag problem.

Answer

The container runtime is not installed

Answer

The image tag is incorrect

Answer

The registry requires authentication

Question 3

You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff'. You want to see the logs of the last crashed instance. Which command should you run?

Accepted Answer

kubectl logs pod-name --previous. The `--previous` flag (or its shorthand `-p`) tells `kubectl logs` to retrieve logs from the previous instance of a container that has crashed and restarted. Since the pod is in `CrashLoopBackOff`, the current container has already exited, and you need to inspect the logs of the last terminated container to diagnose the crash. To avoid having two correct answers, Option C has been changed to an invalid flag.

Answer

kubectl logs pod-name --all-containers

Answer

kubectl logs pod-name --last

Answer

kubectl logs pod-name

Question 4

Which command can you run to see the events related to a specific pod?

Accepted Answer

kubectl describe pod pod-name. `kubectl describe pod pod-name` includes a dedicated 'Events' section that lists all lifecycle events for that specific pod, such as scheduling, container pulls, and restarts. This command filters events to only those relevant to the pod, making it the most direct way to view pod-specific events without needing to parse all cluster events.

Answer

kubectl logs pod-name

Answer

kubectl get pod pod-name

Answer

kubectl get events

Question 5

You have a pod that is stuck in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match pod anti-affinity rules.' What is the MOST likely solution?

Accepted Answer

Remove or modify the pod anti-affinity rules. The pod is unschedulable because two nodes are excluded by pod anti-affinity rules, not because of the master taint (only one node has that taint). The most direct solution is to remove or modify the anti-affinity rules so the pod can be scheduled on those two nodes. Adding a toleration would only address the single master node, leaving the anti-affinity issue unresolved.

Answer

Cordon the master node to remove it from scheduling

Answer

Add a toleration for the master taint to the pod spec

Answer

Delete and recreate the pod

Question 6

Which TWO of the following are valid steps to troubleshoot a pod that is in 'CrashLoopBackOff'?

Accepted Answer

Run 'kubectl logs pod-name --previous' to view logs from the previous crash. Option B is correct because when a pod is in CrashLoopBackOff the current container is usually not running, so 'kubectl logs pod-name --previous' retrieves the logs from the last terminated container instance, which is essential for diagnosing why it crashed. Option C is correct because 'kubectl describe pod pod-name' shows the pod's status, container states, restart counts, and the event stream (e.g., Back-off restarting failed container, image pull errors, OOMKilled), giving the key context for the crash loop. Option A is not a valid troubleshooting step here because 'kubectl exec' requires a running container, and a pod in CrashLoopBackOff has no live container to attach to. Option D is not a diagnostic step; 'kubectl rollout restart' merely triggers a new rollout and does not reveal the cause of the crash. Option E is also not troubleshooting; deleting the pod just causes the controller to recreate it, and the new pod will likely crash again for the same underlying reason.

Answer

Run 'kubectl exec -it pod-name -- /bin/bash' to inspect the container

Answer

Run 'kubectl rollout restart deployment/pod-name'

Answer

Run 'kubectl delete pod pod-name' to force restart

Question 7

A node in your cluster is reporting 'NotReady' status. You log into the node and run 'systemctl status kubelet'. The kubelet service is not running. Which command should you use to start the kubelet and enable it to start on boot?

Accepted Answer

systemctl enable --now kubelet. `systemctl enable --now kubelet` both starts the kubelet service immediately and creates the necessary symlinks to enable it to start automatically on boot. This is the most efficient way to handle a stopped service that needs to be persistent across reboots, which is critical for a Kubernetes node to rejoin the cluster after a reboot.

Answer

systemctl start --enable kubelet

Answer

systemctl enable kubelet

Answer

systemctl start kubelet

Question 8

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 9

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 10

A developer reports that a Pod named 'web-pod' in namespace 'frontend' is crashing repeatedly. You run 'kubectl logs web-pod -n frontend' but see no output. Which command should you run next to see the logs from the previous, crashed container instance?

Accepted Answer

kubectl logs web-pod -n frontend --previous. The `kubectl logs --previous` flag retrieves logs from the previous instance of a container in a Pod, which is exactly what you need when the current container has crashed and restarted, leaving no logs from the current instance. Since `kubectl logs web-pod -n frontend` returned no output, the current container likely started fresh after a crash, and the logs from the crashed container are stored in the terminated container's log file. This flag accesses those logs without needing to specify a container name explicitly when there is only one container in the Pod.

Answer

kubectl get events -n frontend --sort-by=.metadata.creationTimestamp

Answer

kubectl logs web-pod -n frontend -c web-pod

Answer

kubectl exec -it web-pod -n frontend -- sh

Question 11

You need to check the CPU and memory usage of all pods in the 'production' namespace. Which command should you use?

Accepted Answer

kubectl top pods -n production. The `kubectl top pods` command retrieves real-time CPU and memory metrics for pods from the metrics server, which is required for the CKA exam. The `-n production` flag restricts the output to the 'production' namespace, making option A the correct choice for checking resource usage of all pods in that namespace.

Answer

kubectl get pods -n production --show-labels

Answer

kubectl get resourceusage pods -n production

Answer

kubectl top nodes -n production

Question 12

A pod is in 'Pending' state. After running 'kubectl describe pod', you see the event: '0/3 nodes are available: 3 PersistentVolumeClaim is not bound'. What is the most likely cause?

Accepted Answer

The PersistentVolumeClaim referenced by the pod does not exist or is not bound. The event '0/3 nodes are available: 3 PersistentVolumeClaim is not bound' indicates that the pod's PersistentVolumeClaim (PVC) is not in a 'Bound' state. This means the PVC either does not exist in the namespace or has not been successfully bound to a PersistentVolume (PV). The scheduler cannot schedule the pod because the PVC requirement is unsatisfied, which is a prerequisite for pod startup.

Answer

The storage class used by the PVC does not match any PV

Answer

The scheduler is not configured to handle persistent volumes

Answer

The nodes do not have enough CPU or memory

Question 13

A Pod is in 'CrashLoopBackOff' state. You run 'kubectl logs <pod> --previous' and see an error about a missing environment variable. The Pod spec defines the environment variable in a ConfigMap. What is the best next step to diagnose the issue?

Accepted Answer

Run 'kubectl get configmap <configmap-name>' to verify the ConfigMap exists and contains the expected key. The first step in diagnosing a missing environment variable that should come from a ConfigMap is to verify that the ConfigMap itself exists and contains the expected key. If the ConfigMap is missing or the key is absent, the Pod will fail to start or crash, leading to CrashLoopBackOff. Running 'kubectl get configmap' directly confirms whether the resource is present and correctly populated, which is the most efficient next step before deeper investigation.

Answer

Use 'kubectl exec -it <pod> -- env' to list environment variables

Answer

Increase the pod's memory limit to prevent OOM

Answer

Check the node's kubelet logs for errors

Question 14

You have a Deployment with 3 replicas. One of the pods is in 'Pending' state. 'kubectl describe pod' shows: 'Warning FailedScheduling 0/4 nodes are available: 1 node(s) had taint {key1: value1}, that the pod didn't tolerate, 3 node(s) didn't match pod anti-affinity rules.' Which two issues are preventing the pod from being scheduled?

Accepted Answer

Taint toleration mismatch and pod anti-affinity conflicts. The error message explicitly states two distinct scheduling failures: '1 node(s) had taint {key1: value1}, that the pod didn't tolerate' and '3 node(s) didn't match pod anti-affinity rules.' These correspond directly to a taint toleration mismatch and pod anti-affinity conflicts. No other issues (node selector, resource constraints) are mentioned in the describe output.

Answer

Pod anti-affinity and node selector issues

Answer

Node selector and taint toleration mismatch

Answer

Resource constraints and taint toleration mismatch

Question 15

You run 'kubectl get pods' and see a pod with status 'Init:CrashLoopBackOff'. What does this indicate?

Accepted Answer

An init container in the pod is failing and restarting. The status 'Init:CrashLoopBackOff' indicates that an init container within the pod is failing and being repeatedly restarted by Kubernetes. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, Kubernetes retries it with an exponential backoff delay, leading to the CrashLoopBackOff state. This is distinct from a main container crash, which would show 'CrashLoopBackOff' without the 'Init:' prefix.

Answer

The pod's init container ran successfully but the main container has not started yet

Answer

The pod is still initializing but will eventually run

Answer

The main container is crashing and the pod is restarting