CKA Troubleshooting — Timed 10 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