CKA Troubleshooting Practice Test 3 — 15 Questions

Question 1

Which THREE of the following are possible causes for a pod to remain in 'Pending' state?

Accepted Answer

A PersistentVolumeClaim used by the pod is not bound. Options A, B, C, and D are all valid causes of a pod staying in Pending. A: If a PersistentVolumeClaim referenced by the pod is not bound to a PersistentVolume, the scheduler cannot place the pod and it remains Pending. B: An image that cannot be pulled (ImagePullBackOff/ErrImagePull) prevents the container from starting, so the pod never reaches Running and stays Pending. C: When no node has sufficient allocatable CPU or memory to satisfy the pod's resource requests, the scheduler reports Insufficient cpu/memory and leaves the pod Pending. D: If the pod's tolerations do not match the taints on all candidate nodes, the scheduler cannot find a feasible node and the pod remains Pending. Option E is incorrect because a misconfigured startup command causes a CrashLoopBackOff after the container has been scheduled and started, not a Pending state.

Answer

The container's startup command is misconfigured

Question 2

You have a Deployment with one replica. The Pod enters CrashLoopBackOff. 'kubectl describe pod' shows the container exits with code 137. What is the most likely cause?

Accepted Answer

The container is exceeding its memory limit and is OOMKilled. Exit code 137 (128 + 9) indicates the container was killed by SIGKILL, which is the signal sent by the Linux OOM killer when a process exceeds its memory limit. In Kubernetes, when a container's memory usage surpasses its `resources.limits.memory`, the kubelet triggers an OOM kill, causing the container to exit with code 137 and enter CrashLoopBackOff.

Answer

The node is being drained and the pod is being terminated

Answer

The container's startup command is invalid

Answer

The liveness probe is failing and Kubernetes is restarting the container

Question 3

You have a Service named 'my-svc' in namespace 'app'. A Pod in the same namespace cannot resolve the hostname 'my-svc' to an IP address. Which command should you run inside the Pod to test DNS name resolution?

Accepted Answer

nslookup my-svc.app.svc.cluster.local. The fully qualified domain name (FQDN) for a Kubernetes Service is `..svc.cluster.local`. Running `nslookup my-svc.app.svc.cluster.local` inside the Pod queries the cluster's DNS (CoreDNS/kube-dns) directly, which is the standard way to verify DNS resolution for a Service. The short name `my-svc` may not resolve if the Pod's DNS search domains are misconfigured or if the Pod is in a different namespace, but the FQDN always works.

Answer

ping my-svc

Answer

nslookup my-svc

Answer

curl http://my-svc

Question 4

A Pod that was running fine is now showing 'OOMKilled' in its status. Which kubectl command would show you the memory limit and usage for the container?

Accepted Answer

kubectl describe pod . `kubectl describe pod ` displays detailed information about the pod, including the resource requests and limits for each container. When a pod is OOMKilled, the container's memory limit (from the `limits.memory` field) and the reason for termination (OOMKilled) are shown in the container status section, allowing you to compare the limit with the actual usage reported in the `Last State` or `State` fields.

Answer

kubectl top pod <pod>

Answer

kubectl top node

Answer

kubectl logs <pod>

Question 5

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in CrashLoopBackOff with an OOMKilled message, which means the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeded its memory limit. The correct fix is to increase the memory limit in the container's resource specification, allowing the container to use more memory without being killed. Simply deleting and recreating the pod would not resolve the underlying memory constraint, and adjusting CPU or deleting the namespace are irrelevant actions.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 6

Which of the following is a valid command to check the status of the kubelet service on a node running systemd?

Accepted Answer

systemctl status kubelet. 'systemctl status kubelet' is the appropriate command for systemd-managed services. Option B is for systemd units that are not services. Option C is for init.d. Option D is a deprecated command.

Answer

initctl status kubelet

Answer

systemctl list-units kubelet

Answer

service kubelet status

Question 7

You have two Pods in different namespaces. Pod A (namespace: frontend) cannot reach Pod B (namespace: backend) via the ClusterIP service 'backend-svc' in the backend namespace. Which command should you use from within Pod A to test connectivity?

Accepted Answer

kubectl exec pod-a -n frontend -- curl http://backend-svc.backend.svc.cluster.local:80. To test connectivity from Pod A (in the 'frontend' namespace) to a service in the 'backend' namespace, you can run a `kubectl exec` command from your control plane/bastion node. The correct FQDN for the service is `backend-svc.backend.svc.cluster.local`. Option A correctly uses `curl` with this FQDN. Option B is incorrect because ClusterIP services do not respond to ICMP `ping`. Options C and D are incorrect because they omit the target namespace ('backend') in the DNS resolution path, which is required when accessing a service in a different namespace.

Answer

kubectl exec pod-a -n frontend -- ping backend-svc.backend.svc.cluster.local

Answer

kubectl exec pod-a -n frontend -- curl http://backend-svc:80

Answer

kubectl exec pod-a -n frontend -- curl http://backend-svc.backend:80

Question 8

Which command shows all events in the cluster, sorted by timestamp?

Answer

kubectl logs --all-namespaces

Answer

kubectl top events

Answer

kubectl describe events

Answer

kubectl get events -A --sort-by='.metadata.creationTimestamp'

Question 9

You are debugging a CrashLoopBackOff. The pod YAML includes the following container spec:

```yaml
  containers:
  - name: app
    image: myapp:1.0
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3
```

The application starts successfully but crashes after about 10 seconds. What is the most likely cause?

Accepted Answer

The application's health endpoint /healthz is not responding with HTTP 200. The liveness probe is failing, causing the container to be killed and restarted. The app starts but then the probe fails after a few seconds. Options A, C, and D are inconsistent with the scenario.

Answer

The container image myapp:1.0 does not exist

Answer

The liveness probe is too aggressive, causing the container to be killed before it fully initializes

Answer

The pod is running out of memory

Question 10

You need to view the logs of the previous instance of a container in a pod. Which command is correct?

Accepted Answer

kubectl logs -c --previous. The correct command to view logs from the previous instance of a specific container in a pod is `kubectl logs -c --previous`. Option A is incorrect because `kubectl describe` shows pod events and status, not container logs. Option B is incorrect because `kubectl exec` runs a command in the current container, not for viewing previous instance logs. Option D is incorrect because while it includes `--previous` and would show previous logs for all containers, the question asks for logs of a specific container; `--all-containers` is not needed and makes the command less precise.

Answer

kubectl describe pod <pod-name>

Answer

kubectl exec <pod-name> -- cat /var/log/previous.log

Answer

kubectl logs <pod-name> --all-containers --previous

Question 11

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

Accepted Answer

The pod does not tolerate the control-plane taint. The pod does not tolerate the control-plane taint, so it cannot be scheduled on control-plane nodes. Adding a toleration or removing the taint from a worker node would help.

Answer

The pod has a nodeSelector that doesn't match any node

Answer

The persistent volume claim is not bound

Answer

The pod has a resource request that exceeds available node capacity

Question 12

You have a Deployment with 3 replicas. Two pods are Running, one is CrashLoopBackOff. You run 'kubectl logs pod-crash -c app' and see: 'Error: failed to connect to database at 10.0.0.5:5432'. The database is a separate Pod with a ClusterIP service. How should you verify network connectivity from the crashing pod to the database service?

Accepted Answer

kubectl exec -it running-pod -- sh -c 'curl http://db-service:5432'. Since the crashing pod is in CrashLoopBackOff, you cannot reliably run `kubectl exec` inside it. To verify if the database service is reachable from the application's network environment, you should run the connectivity test from one of the healthy, running peer pods in the same Deployment. This isolates whether the issue is a general network/routing problem or specific to the crashing pod's internal configuration.

Answer

kubectl port-forward svc/db-service 5432:5432

Answer

kubectl exec -it pod-crash -- sh -c 'curl http://db-service:5432'

Answer

kubectl logs db-pod

Question 13

You are troubleshooting DNS resolution from a pod. You exec into the pod and run 'nslookup kubernetes.default.svc.cluster.local'. It fails with 'server can't find kubernetes.default.svc.cluster.local: NXDOMAIN'. What is the most likely cause?

Accepted Answer

The pod's /etc/resolv.conf points to an incorrect DNS server IP. The NXDOMAIN error from nslookup indicates the DNS server itself is reachable but does not have a record for the queried name. The most likely cause is that the pod's /etc/resolv.conf points to an incorrect DNS server IP, so the query goes to a server that is not the cluster's DNS (kube-dns/CoreDNS) and thus cannot resolve internal service names. This is a common misconfiguration when the pod's DNS settings are not properly inherited from the cluster's DNS policy.

Answer

The kubernetes service does not exist

Answer

The pod does not have network connectivity

Answer

The kube-dns service is not exposed

Question 14

You want to see events sorted by timestamp in the 'kube-system' namespace. Which command should you use?

Accepted Answer

kubectl get events -n kube-system --sort-by='.metadata.creationTimestamp'. kubectl get events --sort-by='.metadata.creationTimestamp' -n kube-system shows events sorted by creation time.

Answer

kubectl describe events -n kube-system

Answer

kubectl get events -n kube-system --sort-by='.lastTimestamp'

Answer

kubectl logs -n kube-system events

Question 15

Which two commands can be used to view the logs of a container that has crashed? (Choose two.)

Accepted Answer

kubectl logs pod-name --previous. To view the logs of a container that has crashed, you can use `kubectl logs pod-name` (Option E) to view the logs of the current container instance (even if it is currently in a terminated or waiting state), or `kubectl logs pod-name --previous` (Option B) to view the logs of the previous instance if the container has restarted.

`journalctl -u kubelet` (Option A) and `systemctl status kubelet` (Option D) show the logs and status of the kubelet system service itself, not the stdout/stderr of individual containers. `kubectl describe pod` (Option C) shows pod events and metadata but does not display the container's stdout/stderr logs.

Answer

journalctl -u kubelet

Answer

kubectl describe pod pod-name

Answer

systemctl status kubelet