CKA Troubleshooting Practice Test 5 — 15 Questions

Question 1

Which TWO of the following are common causes for a pod to be stuck in Pending state?

Accepted Answer

Node taints that the pod does not tolerate. A is correct because node taints repel pods; if a pod does not have a matching toleration, the scheduler cannot place it on the node, leaving it in a Pending state. B is correct because if the cluster lacks sufficient CPU or memory to satisfy the pod's resource requests, the scheduler cannot find a suitable node, keeping the pod in a Pending state. C is incorrect because an image pull failure results in an ImagePullBackOff or ErrImagePull status after the pod has already been scheduled. D is incorrect because a failing liveness probe causes container restarts, which occurs during the Running phase. E is incorrect because OOMKilled occurs after a container has started running and exceeded its memory limit.

Answer

Image pull failure (ImagePullBackOff)

Answer

PersistentVolumeClaim is in Pending state

Answer

Container exited with OOMKilled

Question 2

Which THREE of the following are valid steps to troubleshoot a DNS issue within a Kubernetes cluster?

Accepted Answer

Verify that the kube-dns service has endpoints using 'kubectl get endpoints -n kube-system kube-dns'. The correct steps are A, B, and E. A: `kubectl get endpoints -n kube-system kube-dns` verifies the service has ready CoreDNS pods; empty endpoints mean DNS queries have no backend. B: `kubectl logs -n kube-system -l k8s-app=kube-dns` checks CoreDNS logs for plugin errors or configuration issues. E: `kubectl exec -it busybox -- nslookup kubernetes.default` directly tests DNS resolution from within the cluster. C is not valid because a node's /etc/resolv.conf is outside the pod network and does not affect cluster DNS for pods. D is not valid because restarting nodes is an unnecessary and disruptive action that does not fix DNS configuration.

Answer

Check the /etc/resolv.conf on the node

Answer

Restart all nodes to reset DNS settings

Question 3

Which TWO of the following are correct methods to check the health of the kube-apiserver?

Accepted Answer

Run 'kubectl get pods -n kube-system -l component=kube-apiserver'. In a standard Kubernetes cluster deployed via kubeadm (which is the basis for the CKA exam), the kube-apiserver runs as a static pod managed by the kubelet, not as a systemd service. Therefore, running `systemctl status kube-apiserver` (Option B) will fail with a service not found error.

Option C is correct because you can check the status of the static pod using `kubectl get pods -n kube-system -l component=kube-apiserver` (assuming the API server is responsive enough to serve the request).

Option E is correct because the kube-apiserver exposes dedicated health endpoints (`/healthz`, `/livez`, and `/readyz`) on its secure port (6443). Performing a `curl -k https://localhost:6443/healthz` is the standard way to directly query the API server's health status.

Option A is incorrect because `kubectl top nodes` shows resource metrics, not health. Option D is incorrect because `journalctl -u kubelet` checks the kubelet service logs, not the kube-apiserver directly.

Answer

Run 'kubectl top nodes'

Answer

Run 'systemctl status kube-apiserver'

Answer

Run 'journalctl -u kubelet'

Question 4

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

Accepted Answer

The nodes are unreachable or have network issues. The event '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/unreachable: }' indicates that all nodes in the cluster have the 'node.kubernetes.io/unreachable' taint, which is automatically applied by the node controller when a node becomes unreachable (e.g., due to network partition, node failure, or kubelet not reporting). Since the pod does not have a toleration for this taint, it cannot be scheduled on any node, resulting in a 'Pending' state. This is a classic scheduling failure caused by node unreachability, not by resource constraints or image issues.

Answer

The pod's container image is not found

Answer

The pod has a resource request that cannot be met by any node

Answer

The PersistentVolumeClaim is not bound

Question 5

You need to check the logs of a container that previously crashed. The pod is currently running, but the previous instance of the container exited with an error. Which command will show you the logs from the crashed container?

Accepted Answer

kubectl logs pod-name --previous. The `kubectl logs` command with the `--previous` flag retrieves the logs from the previous instance of a container in a pod, which is exactly what you need when the current container is running but the previous one crashed. This flag works by accessing the terminated container's logs stored by the kubelet, allowing you to debug the crash without needing to access the node directly.

Answer

kubectl exec pod-name -- cat /var/log/crash.log

Answer

kubectl attach pod-name

Answer

kubectl logs pod-name -c container-name

Question 6

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. Which of the following is NOT a common cause?

Accepted Answer

The node has a taint that tolerates the pod. NOT a common cause of ImagePullBackOff because taints and tolerations affect pod scheduling, not image pulling. ImagePullBackOff occurs when the kubelet fails to pull the container image from the registry, which is a runtime issue unrelated to node scheduling constraints.

Answer

The image tag does not exist

Answer

The image registry requires authentication

Answer

The image name is misspelled

Question 7

You need to verify if the kube-apiserver is running on the control plane node. Which command should you use?

Accepted Answer

kubectl get pods -n kube-system. The kube-apiserver runs as a static pod in the kube-system namespace on the control plane node. Using `kubectl get pods -n kube-system` lists all control plane components, including the kube-apiserver, allowing you to verify its running status directly via the Kubernetes API.

Answer

kubectl describe node controlplane

Answer

kubectl get services -n default

Answer

systemctl status kube-apiserver

Question 8

A pod is in 'CrashLoopBackOff' state. You run 'kubectl logs my-pod' and see 'exec format error: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

Accepted Answer

The container image is missing the specified command or entrypoint. The error 'exec: "/app": stat /app: no such file or directory' indicates that the container's entrypoint or command (in this case, '/app') does not exist inside the container image at the specified path. This typically happens when the Pod spec's 'command' or the image's 'ENTRYPOINT'/'CMD' references a file that is missing or misspelled. Note that because the container failed to start entirely, this error is found in the pod's events or status via 'kubectl describe pod', rather than in the application logs via 'kubectl logs'.

Answer

The container has insufficient memory

Answer

The container runtime is not installed

Answer

The pod's service account lacks permissions

Question 9

You see events like 'Failed to pull image' when running 'kubectl get events'. Which command can you use to get more detailed information about a specific pod's events?

Accepted Answer

kubectl describe pod . C is correct because 'kubectl describe pod ' provides a detailed summary of the pod's current state, including a chronological list of events related to that specific pod (e.g., image pull failures, container restarts, scheduling issues). This command surfaces the exact error messages and timestamps for each event, making it the most direct way to investigate a 'Failed to pull image' event.

Answer

kubectl get pod <pod-name> -o yaml

Answer

kubectl top pod <pod-name>

Answer

kubectl logs <pod-name>

Question 10

Which THREE of the following are valid methods to troubleshoot a CrashLoopBackOff pod?

Accepted Answer

Run 'kubectl describe pod' to check events. To troubleshoot a pod in CrashLoopBackOff, the most effective and valid methods are checking the pod's events using 'kubectl describe pod' (to see if there are OOMKills, configuration issues, or probe failures) and viewing the logs of the previously failed container instance using 'kubectl logs pod --previous'. Attempting to use 'kubectl exec' (Option A) will fail because the container is not in a running state during the backoff period.

Answer

Run 'kubectl exec -it pod -- bash' and inspect the container

Answer

Run 'kubectl delete pod' and recreate it

Answer

Run 'kubectl scale deployment --replicas=0'

Question 11

You have a pod that is in 'Pending' state. Which command would you run to get more information about why the pod cannot be scheduled?

Accepted Answer

kubectl describe pod . `kubectl describe pod ` provides detailed information about the pod, including events, conditions, and scheduler-related messages. For a pod stuck in 'Pending', the 'Conditions' and 'Events' sections will reveal scheduling failures such as insufficient resources, node selector mismatches, or taint toleration issues, which are not visible in logs or basic status output.

Answer

kubectl logs <pod-name>

Answer

kubectl get events

Answer

kubectl get pod <pod-name> -o wide

Question 12

A node in your cluster shows status 'NotReady'. You have SSH access to the node. What is the first command you should run to check the kubelet status?

Accepted Answer

systemctl status kubelet. When a node is NotReady, the first step is to check if the kubelet service is running, because the kubelet is the primary agent responsible for reporting node status to the control plane. Running `systemctl status kubelet` immediately shows whether the kubelet service is active, failed, or stopped, along with recent log snippets, making it the fastest diagnostic command.

Answer

systemctl status docker (or containerd)

Answer

cat /var/log/kubelet.log

Answer

journalctl -u kubelet

Question 13

You create a Deployment with the following YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        resources:
          limits:
            cpu: "500m"
            memory: "256Mi"
          requests:
            cpu: "200m"
            memory: "128Mi"

After applying it, the pods are in 'CrashLoopBackOff'. You check logs and see 'Error: container process exited with error'. What is the MOST likely cause?

Accepted Answer

The application is crashing at startup due to a missing dependency. The error message 'container process exited with error' indicates the application itself is failing to start, not that it is being killed by Kubernetes. Since the container exits immediately after starting, the most likely cause is a missing dependency or misconfiguration in the application code, such as a missing environment variable, database connection, or file. Resource limits and probes affect running containers, not initial startup failures.

Answer

The container is being OOMKilled because memory limit is too low

Answer

The readiness probe is failing

Answer

The container has insufficient CPU resources

Question 14

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 15

You have a multi-node cluster. One node is healthy but pods scheduled on another node are failing to resolve DNS names. You exec into a pod and run 'nslookup kubernetes.default.svc.cluster.local' and get 'server can't find kubernetes.default.svc.cluster.local: NXDOMAIN'. Running the same command on a pod on the healthy node works. What is the MOST likely cause?

Accepted Answer

The CoreDNS pod is not scheduled on that node, and network policy blocks cross-node DNS traffic. The CoreDNS pod runs as a Deployment and may not be scheduled on every node. If a network policy (or a misconfigured CNI plugin) blocks DNS traffic from the failing node to the node hosting the CoreDNS pod, the DNS resolution fails. The fact that `nslookup` works from a pod on the healthy node confirms that the CoreDNS service itself is functional, isolating the issue to cross-node connectivity.

Answer

The container runtime on the failing node is misconfigured

Answer

The kube-dns service is not running in the cluster

Answer

The node's /etc/resolv.conf is pointing to an external DNS server