CKA Troubleshooting Practice Test 15 — 15 Questions

Question 1

You need to check the memory usage of all pods in the 'production' namespace. Which command fulfills this requirement?

Accepted Answer

kubectl top pod --namespace=production. `kubectl top pod --namespace=production` directly queries the metrics-server to retrieve real-time CPU and memory usage for each pod in the specified namespace. This command leverages the Kubernetes Metrics API to display resource consumption, making it the precise tool for checking memory usage of pods.

Answer

kubectl get pod --namespace=production -o wide

Answer

kubectl describe pod --namespace=production

Answer

kubectl top node

Question 2

A node is NotReady. You ssh into the node and run 'systemctl status kubelet'. It shows 'Active: inactive (dead)'. What is the most appropriate next step?

Accepted Answer

systemctl start kubelet. Starting the kubelet service with systemctl start kubelet is the correct action. Investigating logs may be needed if it fails to start.

Answer

journalctl -u kubelet

Answer

kubectl delete node <node-name>

Answer

systemctl restart docker

Question 3

A pod is in CrashLoopBackOff. You check the logs with 'kubectl logs my-pod --previous' and see 'Error: cannot connect to database at 10.0.0.1:3306'. The database service is named 'mysql' and runs on port 3306. What is the most likely cause?

Accepted Answer

The application is configured with an incorrect database hostname. The error message 'cannot connect to database at 10.0.0.1:3306' indicates the application is trying to connect to a hardcoded IP address (10.0.0.1) instead of the Kubernetes service name 'mysql'. In Kubernetes, services are accessed via DNS names (e.g., 'mysql.default.svc.cluster.local'), not static IPs, which are ephemeral and can change. This misconfiguration causes the connection failure, leading to the CrashLoopBackOff as the app repeatedly fails to start.

Answer

The pod does not have network access to the mysql service

Answer

The mysql service is not exposed on port 3306

Answer

The database pod is not running

Question 4

You run 'kubectl top nodes' and get an error: 'error: metrics not available yet'. What is the most likely cause?

Accepted Answer

The metrics-server is not installed or not running. The metrics server is not deployed or not ready; kubectl top requires the metrics server to collect resource usage data.

Answer

The nodes do not have enough resources to run the metrics collection

Answer

You do not have permission to view node metrics

Answer

The kubelet is not running on the nodes

Question 5

A pod is in Pending state. You run 'kubectl describe pod pending-pod' and see an event: '0/3 nodes are available: 3 Insufficient memory'. However, you believe there is enough memory across the cluster. What could be the issue?

Accepted Answer

The pod's memory request is higher than any node's allocatable memory. The '0/3 nodes are available: 3 Insufficient memory' event indicates that the scheduler could not place the pod because each node lacks enough allocatable memory to satisfy the pod's memory request. Even if the cluster has plenty of total memory, the scheduler evaluates each node individually against the pod's resource requests, not the cluster-wide sum. Therefore, if the pod's memory request exceeds the allocatable memory on every node, the pod will remain Pending.

Answer

The cluster is using a resource quota that is exhausted

Answer

The pod's memory limit is set too low

Answer

The nodes have taints that the pod does not tolerate

Question 6

Which three are possible reasons for a pod being in Pending state? (Choose three.)

Accepted Answer

PersistentVolumeClaim not bound. Pending means the pod hasn't been scheduled. Reasons include insufficient resources, persistent volume claim not bound, and taints/tolerations mismatch. Image pull issues cause ImagePullBackOff, not Pending.

Answer

Liveness probe failing

Answer

Container image does not exist

Question 7

You have a pod that is in CrashLoopBackOff. Which two troubleshooting steps should you take first? (Choose two.)

Accepted Answer

kubectl describe pod pod-name. `kubectl describe pod pod-name` provides detailed information about the pod's current state, including recent events, container restart counts, and the reason for the CrashLoopBackOff (e.g., exit code 137 from OOMKill or 1 from application error). This is the first step to understand the root cause of the crash loop.

Answer

kubectl delete pod pod-name

Answer

kubectl exec -it pod-name -- sh

Answer

kubectl rollout restart deployment

Question 8

You are troubleshooting a node that is in 'NotReady' state. Which command should you use to check the kubelet logs for errors?

Accepted Answer

journalctl -u kubelet. The kubelet is the primary node agent that communicates with the control plane and manages pods. When a node is in 'NotReady' state, checking the kubelet logs is the first step to diagnose issues such as certificate errors, resource pressure, or network problems. The command `journalctl -u kubelet` retrieves logs from the systemd unit for the kubelet service, which is the correct way to view its output on systems using systemd.

Answer

journalctl -u docker

Answer

journalctl -u kube-apiserver

Answer

journalctl -u kube-controller-manager

Question 9

You have a Deployment with 3 replicas. After updating the container image, the new pods are in 'ImagePullBackOff' state. You run 'kubectl describe pod <pod-name>' and see the event: 'Failed to pull image "myregistry/myapp:latest": rpc error: code = Unknown desc = Error response from daemon: manifest for myregistry/myapp:latest not found: manifest unknown: manifest unknown'. What is the MOST likely cause?

Accepted Answer

The image tag 'latest' does not exist in the registry. The error message 'manifest unknown' indicates that the registry successfully reached but the specific image tag 'latest' does not exist in the repository. This is a registry-side error, not a network or authentication issue. The container runtime can communicate with the registry but cannot find the manifest for the requested tag.

Answer

The registry is unreachable from the nodes

Answer

The registry requires authentication and the pod does not have an imagePullSecret

Answer

The container runtime is out of disk space

Question 10

You are trying to debug a network connectivity issue between two pods. Pod A can reach the internet but cannot reach Pod B's IP address. Which command should you use to test connectivity from within Pod A to Pod B's service?

Accepted Answer

kubectl exec pod-a -- curl http://service-b:80. It uses `kubectl exec` to run a command inside Pod A, then uses `curl` to reach Pod B's service by its DNS name (`service-b`) and port 80. This tests connectivity from Pod A's network namespace to the ClusterIP service, which is the correct way to verify pod-to-service communication within the cluster. Using the service name leverages Kubernetes internal DNS (CoreDNS) to resolve to the service's virtual IP, and `curl` sends an HTTP request to confirm reachability.

Answer

kubectl exec pod-a -- nslookup service-b

Answer

curl http://:

Answer

ssh node-ip 'curl http://<pod-b-ip>:80'

Question 11

You are troubleshooting a pod that is in 'CrashLoopBackOff' state. You run 'kubectl logs mypod' and get no output. You then run 'kubectl logs mypod --previous' and see an error: 'Error: failed to start container: context deadline exceeded'. What is the MOST likely cause?

Accepted Answer

The container runtime is unable to start the container due to a timeout. The error 'failed to start container: context deadline exceeded' indicates the container runtime (containerd/CRI-O) could not start the container within the allotted timeout, typically due to image pull slowness, runtime hang, or resource pressure. Because kubectl logs with --previous shows this runtime-level error rather than an application stack trace, the root cause is the runtime failing to launch the container, not the app crashing.

Answer

The container image is missing the entrypoint

Answer

The application inside the container is crashing immediately

Answer

The container command is incorrectly specified

Question 12

Which command can be used to view resource usage of nodes in a cluster?

Accepted Answer

kubectl top nodes. The 'kubectl top nodes' command displays resource usage (CPU and memory) for nodes in the cluster. It requires the Metrics Server to be installed and running. This command provides a quick view of node utilization.

Answer

kubectl describe nodes

Answer

kubectl top pods

Answer

kubectl get pods --show-resources

Question 13

You run 'kubectl get events --sort-by=.lastTimestamp' and see the following events for a pod: 'Warning FailedScheduling 0/3 nodes are available: 3 Insufficient cpu'. What is the most likely solution?

Accepted Answer

Reduce the CPU request for the pod or remove other workloads to free CPU. The event '0/3 nodes are available: 3 Insufficient cpu' indicates that all three nodes in the cluster lack sufficient allocatable CPU to satisfy the pod's CPU request. The most direct solution is to either reduce the pod's CPU request (so it fits on an existing node) or remove other workloads to free up CPU capacity. This aligns with Kubernetes resource scheduling, where the scheduler only considers requests (not limits) when placing pods.

Answer

Change the scheduler to a different one

Answer

Increase the CPU limit for the pod

Answer

Add more nodes to the cluster

Question 14

You are troubleshooting DNS resolution from within a pod. You exec into the pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command fails with 'connection timed out; no servers could be reached'. However, 'kubectl get svc -n kube-system' shows the kube-dns service with a ClusterIP. What is the MOST likely cause?

Accepted Answer

The CoreDNS pods are not running or are crashing. The error 'connection timed out; no servers could be reached' from nslookup indicates that the pod cannot reach any DNS server at all. Since the kube-dns service exists (as shown by kubectl), the most likely cause is that the backend CoreDNS pods are not running or are crashing, so there are no endpoints to forward traffic to. Without running CoreDNS pods, the service's ClusterIP has no backing pods, causing all DNS queries to time out.

Answer

The pod's /etc/resolv.conf has incorrect search domains

Answer

A network policy is blocking traffic to the kube-dns service

Answer

The DNS name does not exist

Question 15

You deploy a pod with the following YAML:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

The pod starts, but after a few minutes it is killed with OOMKilled. What is the MOST likely reason?

Accepted Answer

The container's memory usage exceeds the configured limit. OOMKilled occurs when a container exceeds its memory limit. In this YAML, the memory limit is set to 128Mi. If the nginx container's memory usage surpasses 128Mi, the Linux kernel's Out-Of-Memory (OOM) killer terminates the container process, resulting in an OOMKilled status. This is a direct enforcement of the resource limit configured in the pod spec.

Answer

The memory limit is lower than the memory request

Answer

The node has swap enabled

Answer

The container is using too much CPU