CKA Practice Test 42 — 15 Questions

Question 1

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. Option B is correct. 'kubectl exec pod-a -- curl http://service-b:80' runs the curl command inside Pod A to test connectivity to Service B. Option A tests from the node, not from within the pod. Option C tests DNS resolution but not HTTP connectivity. Option D tests connectivity from outside the cluster.

Answer

kubectl exec pod-a -- nslookup service-b

Answer

curl http://:

Answer

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

Question 2

Which TWO of the following kubectl commands can be used to view the logs of a container in a pod? (Choose two.)

Accepted Answer

kubectl logs pod-name. Options A and C are correct. 'kubectl logs pod-name' streams the current logs of the default container. 'kubectl logs pod-name --previous' shows logs from the previous instance of the container (useful for crash loops). Option B 'kubectl describe pod pod-name' shows pod details, not logs. Option D 'kubectl exec pod-name -- logs' is not a standard command; logs are not an executable inside the container. Option E 'kubectl get pod pod-name -o yaml' shows the pod manifest, not logs.

Answer

kubectl describe pod pod-name

Answer

kubectl exec pod-name -- logs

Answer

kubectl get pod pod-name -o yaml

Question 3

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 shows logs of the currently running container.

Answer

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

Answer

kubectl describe pod pod-name

Answer

kubectl logs pod-name --previous

Question 4

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' shows revision history and details of each ReplicaSet, which helps in troubleshooting rollout issues.

Answer

kubectl describe deployment myapp

Answer

kubectl logs deployment/myapp

Answer

kubectl get replicasets -l app=myapp

Question 5

You run 'kubectl get pods' and see that a pod named 'db' is in 'CrashLoopBackOff'. Which TWO commands are most useful for diagnosing the issue? (Choose two)

Accepted Answer

kubectl describe pod db. Describe and logs are the standard first steps to see events and container output.

Answer

kubectl top pod db

Answer

kubectl get pod db -o yaml

Answer

kubectl exec db -- /bin/sh

Question 6

A Deployment is configured with replicas: 3, but only 2 pods are running. 'kubectl describe deployment' shows 'Replicas: 3 desired | 2 current | 2 available'. What could be the reason for the missing pod?

Accepted Answer

A PersistentVolumeClaim used by the pod is not bound. A persistent volume claim in Pending state can prevent a pod from starting if the pod uses a PVC that is not bound.

Answer

The ReplicaSet is not created

Answer

The Deployment's selector does not match the pod template labels

Answer

The node has a disk pressure condition

Question 7

A node in your cluster is reporting 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'Active: inactive (dead)'. Which command should you run FIRST to attempt to resolve this?

Accepted Answer

systemctl start kubelet. Option C is correct. Since the kubelet service is inactive/dead, you need to start it using 'systemctl start kubelet'. Option A shows status only. Option B restarts the node, which is too aggressive. Option D checks logs but does not start the service.

Answer

journalctl -u kubelet

Answer

systemctl status kubelet

Answer

reboot

Question 8

A pod has been in Pending state for a long time. 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate, 2 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate.' What is the most likely cause?

Accepted Answer

The kubelet on each node is not running. The event indicates that all nodes have taints that the pod does not tolerate. This can happen if the nodes are NotReady or unreachable, often due to a network plugin issue or kubelet failure.

Answer

The pod's image is incorrect

Answer

The pod has resource requests that exceed node capacity

Answer

The nodes are all cordoned

Question 9

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

Accepted Answer

The nodes are unreachable or have network issues. The taint 'node.kubernetes.io/unreachable' indicates nodes are unreachable, often due to node failure or network issues.

Answer

The pod's container image is not found

Answer

The pod has a resource request that cannot be met by any node

Answer

The PersistentVolumeClaim is not bound

Question 10

You see events like 'Failed to pull image' when running 'kubectl get events'. Which command can you use to get more detailed information about a specific pod's events?

Accepted Answer

kubectl describe pod <pod-name>. 'kubectl describe pod' shows events related to the pod, including pull failures.

Answer

kubectl get pod <pod-name> -o yaml

Answer

kubectl top pod <pod-name>

Answer

kubectl logs <pod-name>

Question 11

You create a Deployment with the following YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        resources:
          limits:
            cpu: "500m"
            memory: "256Mi"
          requests:
            cpu: "200m"
            memory: "128Mi"

After applying it, the pods are in 'CrashLoopBackOff'. You check logs and see 'Error: container process exited with error'. What is the MOST likely cause?

Accepted Answer

The application is crashing at startup due to a missing dependency. Correct answer is D. The image tag 'latest' can cause issues if the image does not exist or is not available. CrashLoopBackOff with no specific error often indicates an image pull failure or application error. Option A is not necessarily a crash; OOMKilled would show. Option B is unlikely because resources seem fine. Option C is not the most likely; the error is about the container exiting, not readiness.

Answer

The container is being OOMKilled because memory limit is too low

Answer

The readiness probe is failing

Answer

The container has insufficient CPU resources

Question 12

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. Correct answers are A, B, and D. Resource constraints, taint/toleration issues, and PVC not bound are common causes. C would cause CrashLoopBackOff, not Pending. E would cause the pod to run.

Answer

The container image is not found and the pod is in ImagePullBackOff

Answer

The container's startup command is misconfigured

Question 13

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. Check the logs with kubectl logs --previous to see the crash reason, and describe the pod to see events and state.

Answer

kubectl delete pod pod-name

Answer

kubectl exec -it pod-name -- sh

Answer

kubectl rollout restart deployment

Question 14

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 15

Which command can you run to see the events related to a specific pod?

Accepted Answer

kubectl describe pod pod-name. Correct answer is A. 'kubectl describe pod pod-name' includes events at the bottom. Option B shows all events cluster-wide. Option C is for logs. Option D shows pod status briefly.

Answer

kubectl logs pod-name

Answer

kubectl get pod pod-name

Answer

kubectl get events