CKA Troubleshooting Practice Test 9 — 15 Questions

Question 1

A Pod is in 'CrashLoopBackOff' state. You run 'kubectl logs <pod> --previous' and see an error about a missing environment variable. The Pod spec defines the environment variable in a ConfigMap. What is the best next step to diagnose the issue?

Accepted Answer

Run 'kubectl get configmap <configmap-name>' to verify the ConfigMap exists and contains the expected key. Checking whether the ConfigMap exists and is correctly referenced will identify if the variable is missing due to misconfiguration. Option A is correct. Option B would not help if the variable is missing. Option C is irrelevant. Option D might show logs but doesn't address the ConfigMap.

Answer

Use 'kubectl exec -it <pod> -- env' to list environment variables

Answer

Increase the pod's memory limit to prevent OOM

Answer

Check the node's kubelet logs for errors

Question 2

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 <pod>. 'kubectl describe pod' shows resource limits and requests. Option A shows live usage but not limits. Option C shows node usage. Option D shows logs.

Answer

kubectl top pod <pod>

Answer

kubectl top node

Answer

kubectl logs <pod>

Question 3

You have a Deployment with 3 replicas. One of the pods is in 'Pending' state. 'kubectl describe pod' shows: 'Warning FailedScheduling 0/4 nodes are available: 1 node(s) had taint {key1: value1}, that the pod didn't tolerate, 3 node(s) didn't match pod anti-affinity rules.' Which two issues are preventing the pod from being scheduled?

Accepted Answer

Taint toleration mismatch and pod anti-affinity conflicts. The event message directly states two issues: one node has a taint not tolerated, and three nodes don't match pod anti-affinity rules. Option A correctly identifies both. Option B describes two similar issues but not the exact ones. Option C adds an incorrect issue (resource constraints). Option D doesn't match.

Answer

Pod anti-affinity and node selector issues

Answer

Node selector and taint toleration mismatch

Answer

Resource constraints and taint toleration mismatch

Question 4

You run 'kubectl get pods' and see a pod with status 'Init:CrashLoopBackOff'. What does this indicate?

Accepted Answer

An init container in the pod is failing and restarting. Init:CrashLoopBackOff means an init container in the pod is repeatedly crashing. Option A is correct. Option B describes a regular container crash. Option C is wrong because the pod is not running. Option D is wrong because init containers always run to completion before main containers start.

Answer

The pod's init container ran successfully but the main container has not started yet

Answer

The pod is still initializing but will eventually run

Answer

The main container is crashing and the pod is restarting

Question 5

Which TWO of the following are valid methods to diagnose why a node is in 'NotReady' state?

Accepted Answer

Check the kubelet service logs using 'journalctl -u kubelet'. Checking kubelet logs (journalctl) and verifying the network plugin are both standard troubleshooting steps. Option C (checking API server) is not node-level. Option D (restarting containers) is not relevant. Option E (checking kube-proxy) is for service connectivity, not node readiness.

Answer

Restart all containers on the node

Answer

Check the kube-apiserver logs on the control plane

Answer

Check kube-proxy configuration

Question 6

A pod is in 'CrashLoopBackOff' state. Which THREE of the following are possible causes?

Accepted Answer

The container's startup command has invalid arguments. Missing environment variables, invalid command arguments, and failure to bind to a port are common causes of container crashes. Option D (PVC not bound) causes Pending, not CrashLoopBackOff. Option E (image pull error) causes ImagePullBackOff.

Answer

The container image does not exist

Answer

The PersistentVolumeClaim is not bound

Question 7

Which TWO of the following are valid reasons a pod might be stuck in 'Pending' state?

Accepted Answer

Not enough CPU or memory available on any node. Insufficient resources and taint/toleration mismatch are common reasons for Pending. Option C (OOMKilled) would cause CrashLoopBackOff. Option D (image pull) causes ImagePullBackOff. Option E (node reboot) would cause the pod to be rescheduled or terminated.

Answer

Container is killed due to OOM

Answer

Container image pull fails because of authentication error

Answer

Node is rebooted

Question 8

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. Option B is correct. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification. Option A would not help — restarting the pod without addressing the root cause will result in the same failure. Option C addresses CPU, not memory. Option D (deleting the namespace) is destructive and unnecessary.

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 9

You have a Pod that is stuck in Pending state. Which command should you use to get detailed information about why the Pod is not running?

Accepted Answer

kubectl describe pod . Option A is correct. 'kubectl describe pod ' provides detailed information including events and conditions that explain why the Pod is Pending. Option B only shows a summary. Option C is for logs, not scheduling issues. Option D shows container logs, not Pod status.

Answer

kubectl logs <pod-name>

Answer

kubectl exec <pod-name> -- /bin/sh

Answer

kubectl get pod <pod-name>

Question 10

A node in the cluster is showing NotReady status. Which steps should you take to diagnose the issue? (Select the BEST initial step.)

Accepted Answer

Run 'journalctl -u kubelet' on the node to check kubelet logs. Option B is correct. The kubelet is the primary agent on each node responsible for node status. Checking its logs with journalctl is the standard first step. Option A is about the API server. Option C is for pods. Option D is for DNS.

Answer

Test DNS resolution from a pod on the node

Answer

Run 'kubectl describe pod' for pods on that node

Answer

Check the kube-apiserver logs on the master node

Question 11

After deploying a new Deployment, you notice that the pods are stuck in ImagePullBackOff. What is the most common cause?

Accepted Answer

The container image name or tag is incorrect. Option D is correct. ImagePullBackOff indicates Kubernetes cannot pull the container image. The most common cause is a wrong image name or tag. Option A would cause CrashLoopBackOff. Option B would cause Pending (Unschedulable). Option C would cause CrashLoopBackOff.

Answer

The liveness probe is misconfigured

Answer

The node has insufficient resources

Answer

The container command fails on startup

Question 12

You have a Pod that is stuck in Pending state. Running 'kubectl describe pod' shows events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, 3 node(s) had taint {key: value}, that the pod didn't tolerate.' How can you resolve this issue?

Accepted Answer

Add appropriate tolerations to the Pod's spec. Option B is correct. The Pod does not tolerate the taints on the nodes. Adding tolerations to the Pod's spec allows it to be scheduled. Option A is possible but not appropriate if the taints are intentional. Option C is unrelated. Option D is about pods, not nodes.

Answer

Increase the Pod's resource requests

Answer

Remove the taints from all nodes using 'kubectl taint nodes --all key:value-'

Answer

Delete the Pod and recreate it with a different name

Question 13

Which command should you use to view the logs of a container that has previously crashed in a Pod?

Accepted Answer

kubectl logs <pod-name> --previous. Option C is correct. 'kubectl logs --previous' retrieves logs from the previous instance of a container. Option A shows current logs. Option B shows only the container name. Option D is for describing.

Answer

kubectl logs <pod-name>

Answer

kubectl describe pod <pod-name>

Answer

kubectl logs -c

Question 14

A Pod is in CrashLoopBackOff. You run 'kubectl describe pod' and see that the container fails with 'Error: container command not found'. What is the most likely cause?

Accepted Answer

The container image does not contain the specified command. Option A is correct. The container image may not have the command specified in the Pod spec. Option B would also cause a failure but typically results in 'executable file not found in $PATH' if not using full path. Option C would cause OOMKilled. Option D would cause ImagePullBackOff.

Answer

The container is running out of memory

Answer

The image pull is failing

Answer

The container command is not in the PATH

Question 15

You have a Deployment with the following resource limits for containers: memory: 256Mi. The pod is repeatedly killed with OOMKilled. You need to change the limit to 512Mi. Which field should you modify in the Deployment YAML?

Accepted Answer

spec.template.spec.containers[].resources.limits.memory. Option C is correct. Memory limit is specified under resources.limits.memory. Option A is for requests, not limits. Option B is for CPU. Option D is for CPU.

Answer

spec.template.spec.containers[].resources.requests.memory

Answer

spec.template.spec.containers[].resources.requests.cpu

Answer

spec.template.spec.containers[].resources.limits.cpu