CKA Troubleshooting Practice Test 17 — 15 Questions

Question 1

You try to run 'kubectl logs mypod' and get the error: 'Error from server (BadRequest): container "myapp" in pod "mypod" is waiting to start: PodInitializing'. What does this mean?

Accepted Answer

The pod is still being initialized and the container has not started yet.. The error message 'container "myapp" in pod "mypod" is waiting to start: PodInitializing' indicates that the pod's init containers (if any) are still running or the container runtime is pulling the image and setting up the container. The container has not yet entered the 'Running' state, so logs cannot be retrieved until it starts. This is a standard Kubernetes lifecycle phase where the pod is in 'PodInitializing' status, meaning the main container is not ready to serve logs.

Answer

The pod has crashed and is restarting.

Answer

The kubelet is not running on the node.

Answer

The container has a different name than specified.

Question 2

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 scheduler message shows two distinct problems: one node has Insufficient memory, and two nodes carry the taint node-role.kubernetes.io/control-plane that the pod does not tolerate. Option A is correct because removing that taint from the control-plane nodes makes them eligible for scheduling, directly eliminating the 'didn't tolerate' rejection. Option B is correct because lowering the pod's memory request lets it fit on the node that currently reports Insufficient memory, resolving that filter failure. Option D is correct because adding a matching toleration (e.g., key node-role.kubernetes.io/control-plane with the appropriate effect) allows the pod to be scheduled onto the tainted control-plane nodes without changing the cluster. Option C is wrong because increasing the CPU request only makes scheduling harder and does not address either reported failure. Option E is wrong because a node selector matching control-plane nodes does not bypass the taint; without a toleration the pod would still be rejected by those nodes.

Answer

Increase the CPU request of the pod.

Answer

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

Question 3

You run 'kubectl get pods' and see that a pod named 'db' is in 'CrashLoopBackOff'. Which TWO commands are most useful for diagnosing the issue? (Choose two)

Accepted Answer

kubectl describe pod db. Option B, 'kubectl describe pod db', is correct because it surfaces the pod's Events section, which shows scheduling failures, image pull errors, container restarts, and the exit codes/reasons behind the CrashLoopBackOff. Option C, 'kubectl logs db', is correct because it retrieves the container's stdout/stderr, revealing the application-level error or stack trace that caused the process to exit and restart repeatedly. Together these two commands cover both the kubelet-side view (describe) and the application-side view (logs) of why the container keeps crashing. Option A, 'kubectl top pod db', only reports CPU/memory usage and cannot explain a crash loop, and it often fails anyway if the container isn't running. Option D, 'kubectl get pod db -o yaml', shows the pod spec and status but not the event history or application output needed to diagnose the crash. Option E, 'kubectl exec db -- /bin/sh', is not useful because the container is not staying up long enough to exec into, and it doesn't reveal the prior crash cause.

Answer

kubectl top pod db

Answer

kubectl get pod db -o yaml

Answer

kubectl exec db -- /bin/sh

Question 4

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 5

You run 'kubectl get nodes' and one node shows 'NotReady'. Which command should you run first to check the kubelet status on that node?

Accepted Answer

journalctl -u kubelet. The kubelet is responsible for node status. On the node, you can check its logs with journalctl.

Answer

kubectl describe node <node-name>

Answer

cat /var/log/syslog | grep kubelet

Answer

systemctl status kube-apiserver

Question 6

A pod is in CrashLoopBackOff. The YAML for the initContainer is:

apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  initContainers:
  - name: init
    image: busybox
    command: ['sh', '-c', 'sleep 5 && exit 1']
  containers:
  - name: app
    image: nginx

What is the most likely reason for the CrashLoopBackOff?

Accepted Answer

The init container exits with non-zero exit code. Init containers must complete successfully (exit 0) before the main container starts. An exit code 1 causes the pod to fail and restart.

Answer

The main container image nginx is not pulled successfully

Answer

The init container command is misspelled

Answer

The pod has insufficient memory

Question 7

You run 'kubectl get pods' and one pod shows 'ImagePullBackOff'. Which command would help you diagnose the issue?

Accepted Answer

kubectl describe pod . The 'ImagePullBackOff' error indicates that Kubernetes is unable to pull the container image from the registry. 'kubectl describe pod ' provides detailed pod events, including the exact error message from the kubelet (e.g., 'Failed to pull image', 'manifest not found', or 'unauthorized'), which directly reveals the root cause.

Answer

kubectl logs <pod-name>

Answer

kubectl top pod <pod-name>

Answer

kubectl exec -it <pod-name> -- sh

Question 8

A pod is in Pending state. You see the event: '0/2 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. What should you do to schedule the pod on one of the control-plane nodes?

Accepted Answer

Add a toleration to the pod spec matching the taint. The pod is in Pending state because the control-plane nodes have a taint (node-role.kubernetes.io/control-plane) that the pod does not tolerate. By default, pods are not scheduled on control-plane nodes unless they explicitly tolerate that taint. Adding a toleration to the pod spec that matches the taint's key, effect, and optionally value allows the scheduler to place the pod on a control-plane node.

Answer

Increase the pod's resource requests

Answer

Remove the taint from the control-plane node

Answer

Use a different namespace

Question 9

You need to test DNS resolution from within a pod. Which command should you run?

Accepted Answer

kubectl exec -- nslookup . `kubectl exec -- nslookup ` runs the `nslookup` command directly inside an existing pod, which tests DNS resolution from within the pod's network namespace. This is the most direct way to verify that the pod's DNS resolver (typically CoreDNS or kube-dns) can resolve a Kubernetes service name to a cluster IP, as it uses the pod's `/etc/resolv.conf` and the cluster DNS service.

Answer

kubectl describe svc <service-name>

Answer

kubectl logs <pod> | grep dns

Answer

kubectl run nslookup --image=busybox -- nslookup <service-name>

Question 10

Which command shows resource usage (CPU/memory) of all pods in the default namespace?

Accepted Answer

kubectl top pods. kubectl top pod shows CPU and memory metrics for pods.

Answer

kubectl describe pods

Answer

kubectl logs pods

Answer

kubectl get pods -o wide

Question 11

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 12

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 13

You have a pod that is in 'Pending' state. Which command would you use to view detailed information about the pod's status, including events that may indicate why it is not running?

Accepted Answer

kubectl describe pod. C is correct because `kubectl describe pod` provides detailed information about the pod's current state, including status conditions, container statuses, and a chronological list of events associated with the pod. These events often contain error messages (e.g., 'FailedScheduling', 'ImagePullBackOff', 'CrashLoopBackOff') that directly explain why the pod is stuck in 'Pending' state, such as insufficient resources or persistent volume claim issues.

Answer

kubectl get endpoints

Answer

kubectl logs pod

Answer

kubectl get pod

Question 14

A node in your cluster is reporting 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'Active: inactive (dead)'. Which command should you run FIRST to attempt to resolve this?

Accepted Answer

systemctl start kubelet. The kubelet service is the primary Kubernetes agent on each node, and when it is 'inactive (dead)', the node cannot report its status to the control plane. The first step to restore the node is to start the kubelet service using 'systemctl start kubelet', which will attempt to bring the kubelet process back online and allow it to reconnect to the API server.

Answer

journalctl -u kubelet

Answer

systemctl status kubelet

Answer

reboot

Question 15

You have a pod that is in 'CrashLoopBackOff' state. Which command should you use to view the logs from the previous instance of the container?

Accepted Answer

kubectl logs pod-name --previous. The correct option is A, `kubectl logs pod-name --previous`, because when a container is in CrashLoopBackOff the current container instance may not have started or may have already been replaced, so the `--previous` (or `-p`) flag retrieves the logs from the last terminated instance of that container in the pod. This is the standard way to inspect why the container crashed on its prior run. Option D, `kubectl logs pod-name`, only shows logs from the currently running container instance, which may be empty or unavailable during a crash loop. Option B, `kubectl get events`, shows cluster-level event messages but not the container's stdout/stderr logs, and option C, `kubectl describe pod pod-name`, shows pod status, conditions, and recent events but not the previous container's application logs.

Answer

kubectl get events

Answer

kubectl describe pod pod-name

Answer

kubectl logs pod-name