CKA Troubleshooting Practice Test 4 — 15 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

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 most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to use more memory without being killed. Simply increasing CPU requests (Option A) does not address memory exhaustion, and deleting/recreating the pod or namespace (Options C and D) will not fix the underlying resource constraint.

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 2

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see the event: '0/3 nodes are available: 1 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate, 2 Insufficient memory.' Which issue is causing the pod to be pending?

Accepted Answer

The pod does not tolerate the taint on the unreachable node and there is insufficient memory on other nodes. The event clearly states two issues: a taint that the pod doesn't tolerate and insufficient memory. Multiple reasons are given, so the pod is pending due to both. Option A is partially correct but incomplete. Option B is not mentioned. Option D is incorrect because the event mentions both issues.

Answer

The node is unreachable

Answer

The pod has a memory request that cannot be fulfilled

Answer

The pod has a node selector that does not match any node

Question 3

A Pod is stuck in 'Pending' state. Upon inspection, you find that the PVC it references is also 'Pending'. Which of the following is NOT a common cause for a PVC to remain in Pending state?

Accepted Answer

The pod that references the PVC has a missing volume mount. A pod missing a volume mount does not affect the PVC's binding process; the PVC is bound independently before the pod uses it. Common causes for a PVC to remain in 'Pending' state include: A) the PVC requests more storage than available PVs; B) the specified storage class does not exist; and C) the cluster has no default storage class when no storage class is specified.

Answer

The persistent volume claim requests more storage than the available persistent volumes

Answer

The storage class does not exist

Answer

The cluster does not have a default storage class

Question 4

You want to check the status of the kube-apiserver on a control plane node. Which commands should you use? (Select the best option)

Accepted Answer

systemctl status kube-apiserver or crictl ps | grep kube-apiserver. On a kubeadm-provisioned control plane node, the kube-apiserver runs as a static pod managed by the kubelet. You can check its status either via systemctl if it is installed as a systemd unit (some distributions) or, more reliably, via crictl ps to see the static pod container. The combination in option B covers both the systemd and container-runtime views.

Answer

journalctl -u kubelet

Answer

ps aux | grep kube-apiserver

Answer

docker ps | grep kube-apiserver

Question 5

Which TWO of the following are valid reasons for a pod to be in 'CrashLoopBackOff' state? (Choose two.)

Accepted Answer

The application inside the container exits with a non-zero exit code immediately after starting. Options B and C are correct. A crash loop occurs when the container starts and then crashes repeatedly. The backoff delay increases with each restart. Option B: If the application exits with a non-zero exit code, it will be restarted, leading to a crash loop if it keeps failing. Option C: A failing liveness probe causes the container to be restarted, leading to a crash loop. Option A (insufficient CPU) causes the pod to be in Pending state, not CrashLoopBackOff. Option D (image not found) causes ImagePullBackOff. Option E (PVC not bound) causes Pending state.

Answer

The pod is requesting more CPU than any node can provide

Answer

The pod's persistent volume claim is not bound

Answer

The container image does not exist in the registry

Question 6

A pod remains in Pending state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What is the solution?

Accepted Answer

Add a toleration to the pod spec. The pod cannot tolerate the master taint. Remove the taint or add tolerations.

Answer

Increase the pod's CPU request

Answer

Remove the pod and recreate it

Answer

Delete the taint from the node

Question 7

A newly created Service of type ClusterIP is not accessible from within the cluster. You exec into a pod and run 'curl http://service-name:80' but get 'Connection refused'. What is the most likely cause?

Accepted Answer

The application inside the pod is not listening on the targetPort. Connection refused indicates the application in the backend pods is not listening on the expected port, or the service's targetPort is wrong.

Answer

The service selector does not match pod labels

Answer

The backend pods are not ready

Answer

The service is not in the same namespace

Question 8

A pod is in CrashLoopBackOff. You want to see the current container's logs. Which command do you use?

Accepted Answer

kubectl logs pod-name. `kubectl logs pod-name` retrieves the current container logs from the pod's standard output (stdout/stderr). For a pod in CrashLoopBackOff, the container is actively restarting, so the current logs (from the latest crash) are available without the `--previous` flag. This command directly shows the most recent container output, which is essential for diagnosing the crash reason.

Answer

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

Answer

kubectl describe pod pod-name

Answer

kubectl logs pod-name --previous

Question 9

You have a Deployment with 3 replicas. One pod is in CrashLoopBackOff. The other two are Running. You run 'kubectl get events' and see 'Liveness probe failed: HTTP probe failed with statuscode: 503'. What should you do?

Accepted Answer

Check the application health endpoint and fix it to return 200. Liveness probe failure causes container restart. The fix could be adjusting the probe or fixing the app to respond correctly.

Answer

Increase the initialDelaySeconds of the liveness probe

Answer

Scale down the deployment

Answer

Remove the liveness probe

Question 10

Which THREE are valid methods to debug DNS resolution inside a pod? (Select 3)

Accepted Answer

kubectl exec <pod> -- nslookup kubernetes.default.svc.cluster.local. Option B is correct because nslookup is a standard DNS query tool that, when run inside the pod via kubectl exec, directly queries the pod's configured resolver (e.g., CoreDNS at the kube-dns service IP) and shows the resolved IP or NXDOMAIN, making it a valid DNS debugging method. Option D is correct because dig performs an explicit DNS lookup against the pod's resolver and returns detailed records, response codes, and query times, which is ideal for diagnosing resolution failures inside the pod's network namespace. Option E is correct because curl http://kubernetes.default exercises the full path of DNS resolution plus HTTP connectivity to the kubernetes API service, so a successful response confirms that name resolution and routing work from the pod. Option A is not a valid DNS debugging method because ping only tests ICMP reachability and many clusters or services block ICMP, so a failed ping does not indicate a DNS problem. Option C is not valid because kubectl logs only retrieves the container's stdout/stderr and does not perform or reveal DNS resolution behavior.

Answer

kubectl exec <pod> -- ping kubernetes.default.svc.cluster.local

Answer

kubectl logs <pod>

Question 11

A pod is in Pending state. Which TWO are possible causes? (Select 2)

Accepted Answer

A PersistentVolumeClaim used by the pod is not bound. Pending means pod cannot be scheduled. Resource constraints and PVC not bound are common causes.

Answer

The pod's liveness probe is failing

Answer

The container image is invalid

Answer

The pod's readiness probe is failing

Question 12

Which THREE are valid steps to troubleshoot a node that is in 'NotReady' state? (Select 3)

Accepted Answer

Check kubelet logs with 'journalctl -u kubelet'. Check kubelet status, logs, and network plugin. Restarting kubelet may help; checking API server is not node-specific.

Answer

Run 'kubectl get events' from the control plane

Answer

Restart the kube-apiserver on the control plane

Question 13

You deploy a pod with the following YAML and it remains in 'Pending' state. What is the most likely cause?

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: myapp
    image: nginx
  resources:
    requests:
      memory: "64Gi"
```

Accepted Answer

The pod requests more memory than any node can allocate.. The pod requests 64Gi of memory, which is an extremely high amount that likely exceeds the allocatable memory of any node in the cluster. The Kubernetes scheduler cannot find a node with sufficient resources to satisfy the request, so the pod remains in 'Pending' state. This is a classic resource insufficiency scenario where the scheduler's predicates fail due to insufficient memory.

Answer

The pod is missing a required label.

Answer

The pod has a taint that no toleration matches.

Answer

The image 'nginx' does not exist.

Question 14

You run 'kubectl get pods' and see that a pod named 'web' is in 'ImagePullBackOff' state. Which command would help you see the reason for the image pull failure?

Accepted Answer

kubectl describe pod web. C is correct because 'kubectl describe pod web' is the standard, most comprehensive command to inspect pod details and lifecycle events. To prevent Option A from being a technically correct alternative, it should be changed to 'kubectl get events web'. Running 'kubectl get events web' is a common mistake; it attempts to find a specific event resource named 'web' rather than filtering events involving the pod 'web', resulting in a 'not found' error.

Answer

kubectl get events --field-selector involvedObject.name=web

Answer

kubectl logs web

Answer

kubectl exec web -- docker pull nginx

Question 15

You have a Deployment that is failing to update. You run 'kubectl rollout status deployment/myapp' and it hangs. Which command should you run to see the status of individual ReplicaSets and pods?

Accepted Answer

kubectl rollout history deployment/myapp. 'kubectl rollout history deployment/myapp' shows the revision history of the Deployment, including the ReplicaSets associated with each revision. This allows you to see the status of individual ReplicaSets and their corresponding pods, which is essential when a rollout hangs because you can identify which ReplicaSet is stuck or failing.

Answer

kubectl describe deployment myapp

Answer

kubectl logs deployment/myapp

Answer

kubectl get replicasets -l app=myapp