CKA Troubleshooting — 100 Questions

Question 1

A pod named 'web-frontend' is in CrashLoopBackOff. You run 'kubectl logs web-frontend' and see: 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause and how should you fix it?

Accepted Answer

The container process is not terminating gracefully; add a preStop hook or use a proper init system to release the port.. The error 'address already in use' indicates the container process is trying to bind to port 8080, but that port is still held by a previous instance of the process that did not release it. This typically happens when the container process does not handle SIGTERM gracefully (e.g., it ignores the signal or takes too long to shut down), so Kubernetes kills it with SIGKILL, leaving the socket in a TIME_WAIT or lingering state. Adding a preStop hook or using a proper init system (like tini or a signal-aware wrapper) ensures the process releases the port before the container stops, preventing the crash loop.

Answer

The NodePort is conflicting; change the service type to ClusterIP.

Answer

The container is missing an environment variable required for startup; add it via ConfigMap.

Answer

The pod has insufficient memory; increase memory limits in the deployment.

Question 2

A user reports that their application cannot resolve DNS names for services in the cluster. The application runs in a pod with dnsPolicy: ClusterFirst. What is the most likely cause?

Accepted Answer

The CoreDNS deployment has 0 ready replicas.. When dnsPolicy is ClusterFirst, the pod's DNS queries are forwarded to the cluster's DNS service (CoreDNS by default). If the CoreDNS deployment has 0 ready replicas, the DNS service has no backend endpoints to handle queries, causing all DNS resolutions to fail. This is the most direct and common cause of complete DNS failure in a cluster.

Answer

The pod's dnsPolicy is set to Default instead of ClusterFirst.

Answer

The node's network plugin is misconfigured, blocking UDP port 53.

Answer

The pod's /etc/resolv.conf contains incorrect nameserver entries.

Question 3

Which TWO of the following are valid methods to troubleshoot a pod that is stuck in 'Pending' state?

Accepted Answer

Run 'kubectl describe pod ' and check the Events section.. A is correct because 'kubectl describe pod ' displays the Events section, which includes detailed reasons for a pod being stuck in Pending state, such as insufficient CPU/memory, persistent volume claims not binding, or node selector mismatches. This is the primary diagnostic command for understanding scheduling failures.

Answer

Run 'kubectl logs <pod-name>' to view application logs.

Answer

Run 'kubectl exec -it <pod-name> -- /bin/sh' to inspect the container.

Answer

Run 'kubectl top pod <pod-name>' to check resource usage.

Question 4

Based on the exhibit, the pod is in CrashLoopBackOff. Which command should you run NEXT to identify the root cause?

Accepted Answer

kubectl logs api-6f4d7b9d4c-abcde -n production --previous. The pod is in CrashLoopBackOff, which means the container starts, crashes, and restarts repeatedly. The `kubectl logs --previous` command retrieves the logs from the previous (crashed) container instance, which is the fastest way to see the error that caused the crash. This directly reveals the root cause, such as a missing dependency, configuration error, or application panic.

Answer

kubectl describe node node-1

Answer

kubectl top pod api-6f4d7b9d4c-abcde -n production

Answer

kubectl get deployment api -n production -o yaml

Question 5

You are a CKA managing a production cluster with 5 worker nodes. A developer reports that a new deployment 'payment-service' is not accessible from other pods via its Service 'payment-svc' in the 'default' namespace. The Service is of type ClusterIP with selector 'app: payment'. The deployment has 3 replicas, all showing 'Running' status. From a test pod, you run 'curl http://payment-svc:8080' and get 'Connection refused'. You verify that the pods are listening on port 8080 and the container's readiness probe passes. 'kubectl get endpoints payment-svc' shows no endpoints. 'kubectl describe svc payment-svc' shows the selector 'app=payment'. What is the most likely cause?

Accepted Answer

The pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.. The most likely cause is that the pods' labels do not match the Service's selector. The Service 'payment-svc' uses selector 'app: payment', but the pods have label 'app: payment-service'. Since the selector does not match any pods, the Service's endpoints list is empty, causing 'Connection refused' when trying to reach the ClusterIP. The pods are running and listening on port 8080, but the Service has no backends to forward traffic to.

Answer

A NetworkPolicy is blocking traffic from the test pod to the service IP.

Answer

The service type should be NodePort to allow in-cluster access.

Answer

The readiness probe is failing on all pods, causing them to be removed from service endpoints.

Question 6

A developer reports that a newly deployed Deployment named 'web-app' is not serving traffic. The Deployment has 3 replicas, a Service of type ClusterIP, and an Ingress. Which TWO commands should you run first to diagnose the issue?

Accepted Answer

kubectl describe svc web-app. Option A is correct because `kubectl describe svc web-app` shows the Service's ClusterIP, port mapping, and endpoint list. If the endpoints are empty, the Service has no healthy Pods to route traffic to, which is a common cause of traffic failure. This command directly checks whether the Service is correctly wired to the Pods.

Answer

kubectl logs deployment/web-app

Answer

kubectl get events --sort-by='.lastTimestamp'

Answer

kubectl describe ingress web-app

Question 7

Based on the exhibit, what is the most likely cause of the pod not running?

Accepted Answer

The Secret 'my-secret' does not exist in the namespace.. The correct answer is D because the pod's status indicates it is waiting for a secret to be mounted, and the error message 'secret "my-secret" not found' directly points to the missing Secret resource. Without the Secret existing in the same namespace as the pod, the volume mount fails, preventing the pod from starting.

Answer

The volume driver is not installed on node-1.

Answer

The pod has exceeded its resource limits.

Answer

The node 'node-1' is experiencing disk pressure.

Question 8

You are tasked with troubleshooting a production Kubernetes cluster. A user reports that they cannot access a web application running in the cluster. The application is deployed as a Deployment named 'frontend' with 2 replicas, exposed via a Service of type LoadBalancer. You have kubectl access to the cluster. You run 'kubectl get pods -l app=frontend' and see both pods are Running and Ready. You run 'kubectl get svc frontend' and see the Service has an external IP of 192.168.1.100. However, when you curl http://192.168.1.100 from a machine outside the cluster, you get a connection timeout. You are able to curl the pod IPs directly from within the cluster and get a response. Which of the following is the most likely cause of the issue?

Accepted Answer

The cloud provider's load balancer is not properly configured or the security group/firewall is blocking traffic to the node ports.. The pods are running and ready, and the service has an external IP, but external access fails with a connection timeout while internal access to pod IPs works. This indicates the cloud provider's load balancer is not properly routing traffic to the node ports, or a security group/firewall is blocking inbound traffic on the node port range (30000-32767). The load balancer must forward traffic to the node ports, and the nodes must allow that traffic.

Answer

The Service selector does not match the pod labels.

Answer

The NodePort service type is not enabled in the cluster.

Answer

The Ingress resource is missing or misconfigured.

Question 9

A pod is in CrashLoopBackOff state. Which command should you use to see the logs of the previous instance?

Accepted Answer

kubectl logs -p . When a pod is in CrashLoopBackOff state, the current container instance has crashed and Kubernetes is restarting it. The `-p` flag (or `--previous`) in `kubectl logs` retrieves logs from the previous terminated container instance, which contains the crash output. Option B is correct because `kubectl logs -p ` is the exact syntax to view logs of the previous instance.

Answer

kubectl logs <pod-name>

Answer

kubectl describe pod <pod-name>

Answer

kubectl logs --previous <pod-name>

Question 10

You run kubectl get nodes and see one node is NotReady. The kubelet is running on the node. What is the most likely cause?

Accepted Answer

Network connectivity issue between kubelet and API server. When a node is NotReady but the kubelet is running, the most common cause is a network connectivity issue between the kubelet and the API server. The kubelet reports node status via periodic heartbeats (node-status-update-frequency, default 10s) and if the API server cannot receive these updates due to network problems (e.g., firewall rules, DNS resolution failure, or dropped packets), the node controller marks the node as NotReady after the node-monitor-grace-period (default 40s). The kubelet being running eliminates installation issues, and the API server being down would affect all nodes, not just one.

Answer

The kubelet is not installed

Answer

The node has been cordoned

Answer

The API server is down

Question 11

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

Accepted Answer

All nodes in the cluster are NotReady. The error message '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate' indicates that every node in the cluster is tainted with node.kubernetes.io/not-ready, which is automatically applied by the node controller when a node becomes unreachable or fails its health checks. Since no node is Ready, the pod cannot be scheduled, and the only way to schedule it would be to add a toleration for this taint, but that would not fix the underlying node issue. Therefore, the most likely reason is that all nodes are in the NotReady state.

Answer

The pod needs a toleration for node.kubernetes.io/not-ready

Answer

The pod has a resource request that cannot be met

Answer

The scheduler is not running

Question 12

You need to investigate why a service is not reachable from within the cluster. Which of the following is the first step?

Accepted Answer

Check if the service has endpoints. Option C is correct because the most fundamental check when a service is unreachable from within the cluster is to verify whether the service has any endpoints. A service without endpoints means no pods are matching its selector, so traffic cannot be forwarded regardless of DNS or kube-proxy status. The `kubectl get endpoints <service>` command directly reveals this, making it the logical first step before deeper diagnostics.

Answer

Check kube-proxy logs on the nodes

Answer

Check DNS resolution

Answer

Restart the service

Question 13

A pod has status 'Init:Error'. What does this indicate?

Accepted Answer

An init container failed. The 'Init:Error' status indicates that a pod's init container has failed to complete successfully. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, the pod enters this error state. This is distinct from a main container crash, which would show as 'CrashLoopBackOff' or 'Error' after the pod has started.

Answer

The main container has crashed

Answer

The pod is being initialized

Answer

There is a network error during initialization

Question 14

Which of the following are valid methods to debug a failing CoreDNS pod? (Select TWO)

Accepted Answer

kubectl logs -n kube-system -l k8s-app=kube-dns. Option A is correct because `kubectl logs -n kube-system -l k8s-app=kube-dns` retrieves the logs from all CoreDNS pods (which are labeled `k8s-app=kube-dns` in the `kube-system` namespace). This is a direct method to inspect errors, crashes, or misconfigurations in the DNS service. Option C is correct because `kubectl get endpoints -n kube-system kube-dns` shows the IP addresses of the pods backing the `kube-dns` service; if the endpoint list is empty, it indicates that no CoreDNS pods are ready to serve DNS requests, which is a common failure point.

Answer

kubectl delete pod -n kube-system -l k8s-app=kube-dns

Answer

kubectl scale deployment coredns --replicas=2

Answer

kubectl run -it --rm test --image=busybox -- nslookup kubernetes.default

Question 15

A pod is in CrashLoopBackOff state. Which command shows the last termination reason?

Accepted Answer

kubectl describe pod . The `kubectl describe pod ` command displays detailed information about the pod, including the container state transitions and the last termination reason in the `Last State` field under the container status. This is the correct way to see why the container previously exited, which is essential for diagnosing a CrashLoopBackOff.

Answer

kubectl logs <pod>

Answer

kubectl get pod <pod> -o yaml

Answer

kubectl top pod <pod>

Question 16

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 17

A pod is stuck in ContainerCreating. Which condition is most likely if `kubectl describe pod` shows 'Failed to create pod sandbox'?

Accepted Answer

CNI plugin issue. The error 'Failed to create pod sandbox' indicates that the container runtime (e.g., containerd or CRI-O) was unable to set up the necessary Linux namespaces and cgroups for the pod. This is almost always caused by a CNI plugin issue, such as a misconfigured or missing network plugin (e.g., Calico, Flannel, Weave), which prevents the sandbox from being initialized. Image pull failures produce 'ErrImagePull' or 'ImagePullBackOff', not sandbox creation errors.

Answer

Image pull failure

Answer

Node disk pressure

Answer

Incorrect security context

Question 18

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 19

A Service of type ClusterIP is not reachable from within the cluster. Pods backing the Service are running and healthy. What is the most likely cause?

Accepted Answer

kube-proxy not running or misconfigured. When Pods are healthy but a ClusterIP Service is unreachable from within the cluster, the most common cause is that kube-proxy is not running or is misconfigured. kube-proxy is responsible for implementing the ClusterIP virtual IP by programming iptables (or IPVS) rules on each node to forward traffic to the selected Pods. Without these rules, packets destined for the ClusterIP are dropped or rejected, even though the Service and Endpoints objects exist.

Answer

DNS resolution failure

Answer

Ingress controller not set up

Answer

Service type should be NodePort

Question 20

A worker node is marked NotReady. Which two checks are most relevant to diagnose the node's kubelet health? (Choose two.)

Accepted Answer

systemctl status kubelet. A is correct because `systemctl status kubelet` directly queries the systemd service manager to report whether the kubelet process is running, its current state (active/inactive/failed), and recent log entries. Since the kubelet is the primary node agent responsible for registering the node and reporting status to the control plane, checking its service status is the most immediate step when a node is NotReady.

Answer

kubectl get nodes

Answer

Check API server logs