Courseiva

CCNA Cka Troubleshooting Questions

75 of 290 questions · Page 2/4 · Cka Troubleshooting topic · Answers revealed

Practice these questionsExam hubAll questions
76
MCQhard

You run 'kubectl get nodes' and one node shows 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. Kubelet is active but 'journalctl -u kubelet -n 50' shows 'network plugin is not ready: cni config uninitialized'. What is the most likely cause?

A.The container runtime is not installed
B.The CNI configuration file is missing or incorrect
C.Kubelet is not running
D.The node's IP address has changed
AnswerB

The error indicates CNI config is uninitialized.

Why this answer

The CNI plugin configuration is missing, causing the network plugin to be unready.

Practice this question →
77
MCQeasy

Which command shows CPU and memory usage of nodes in the cluster?

A.kubectl describe nodes
B.kubectl get nodes
C.kubectl logs nodes
D.kubectl top nodes
AnswerD

Displays CPU and memory usage for nodes.

Why this answer

kubectl top nodes displays resource usage for nodes, provided the Metrics Server is installed.

Practice this question →
78
Multi-Selectmedium

A pod is in ImagePullBackOff. Which TWO of the following are possible causes? (Select 2)

Select 2 answers
A.The node has insufficient memory
B.The image is in a private registry and no imagePullSecrets are defined
C.The pod has a resource limit that is too low
D.The image tag is misspelled
E.The kubelet is not running
AnswersB, D

Without credentials, pulling from a private registry fails.

Why this answer

Common causes: invalid image tag (typo) and authentication failure when the image is in a private registry.

Practice this question →
79
MCQeasy

You have a pod that is in 'CrashLoopBackOff' state. Which command should you use to view the logs from the previous instance of the container?

A.kubectl logs pod-name --previous
B.kubectl get events
C.kubectl describe pod pod-name
D.kubectl logs pod-name
AnswerA

The --previous flag retrieves logs from the previous (crashed) container.

Why this answer

Option C is correct. The '--previous' flag shows logs from the previous (crashed) container instance. Option A shows current logs.

Option B shows events. Option D describes the pod.

Practice this question →
80
Multi-Selecthard

You are troubleshooting a node that is 'NotReady'. Which THREE of the following are possible causes? (Choose three.)

Select 3 answers
A.The kubelet cannot contact the API server
B.The kubelet service is stopped
C.The node has disk pressure
D.A pod on the node is consuming excessive memory
E.The network plugin (e.g., Calico, Flannel) is not running
AnswersA, B, E

If the kubelet loses connectivity to the API server, it cannot report its status, and the node will eventually become NotReady.

Why this answer

Options B, C, and E are correct. A node becomes NotReady when the kubelet stops reporting its status. Option B: If the kubelet service is stopped, the node will become NotReady.

Option C: If the network plugin (e.g., Calico, Flannel) is down, the node may become NotReady because it cannot communicate with the control plane. Option E: If the kubelet cannot contact the API server (e.g., due to network issues), it can't report its status, leading to NotReady. Option A (disk pressure) causes node conditions like DiskPressure but does not directly cause NotReady; the node might still be Ready with pressure conditions.

Option D (a pod using too much memory) does not cause node NotReady; it might cause OOMKilled or resource pressure but not the node status to change to NotReady.

Practice this question →
81
MCQmedium

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?

A.The pod has a nodeSelector that doesn't match any node
B.The persistent volume claim is not bound
C.The pod has a resource request that exceeds available node capacity
D.The pod does not tolerate the control-plane taint
AnswerD

The event explicitly states the pod didn't tolerate the control-plane taint.

Why this answer

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.

Practice this question →
82
MCQmedium

A pod is stuck in Pending state. 'kubectl describe pod' shows '0/2 nodes are available: 1 node(s) had taint that the pod didn't tolerate, 1 node(s) didn't match pod anti-affinity rules'. What should you check?

A.The pod's resource requests
B.The pod's image pull policy
C.The node's taints and the pod's tolerations
D.The pod's liveness probe configuration
AnswerC

Why this answer

The events clearly indicate taint toleration and anti-affinity issues; checking tolerations and affinity rules is the right step.

Practice this question →
83
MCQhard

You have a pod that is CrashLoopBackOff. The logs show 'error: dial tcp: lookup service.default.svc.cluster.local: no such host'. What is the most likely cause?

A.The CoreDNS pod is down
B.The service 'service' does not exist in the 'default' namespace
C.The pod's DNS policy is set to 'None'
D.A network policy is blocking UDP port 53
AnswerB

Why this answer

The error message 'no such host' indicates that the DNS lookup for 'service.default.svc.cluster.local' failed because the hostname does not exist. In Kubernetes, this FQDN resolves only if a Service named 'service' exists in the 'default' namespace. Since the lookup fails with 'no such host', the most likely cause is that the Service does not exist, not a DNS infrastructure issue.

Exam trap

The trap here is that candidates often assume any DNS error means CoreDNS is down, but the specific 'no such host' message points to a missing DNS record, not a DNS service failure.

Why the other options are wrong

A

While CoreDNS being down could cause this, the error is about a specific service name not found, not a generic DNS failure. More likely the service doesn't exist.

C

If DNS policy was None, the pod would not even attempt cluster DNS; the error shows it tried but failed.

D

Network policies block traffic; but DNS would likely timeout or connection refused, not 'no such host'.

Practice this question →
84
MCQhard

You are troubleshooting a pod that cannot start. Running 'kubectl describe pod' shows the event: 'Failed to pull image "myregistry.io/myapp:1.0": rpc error: code = Unknown desc = Error response from daemon: manifest for myregistry.io/myapp:1.0 not found'. What is the MOST likely cause?

A.The registry is unreachable due to network issues
B.The image tag '1.0' does not exist in the registry
C.The image registry requires authentication and the imagePullSecret is missing
D.The image has been deleted from the registry
AnswerB

The specific error 'manifest not found' indicates the tag does not exist.

Why this answer

Correct answer is B. The error indicates the image tag does not exist in the registry. Option A would show authentication errors.

Option C would show connection errors. Option D would show digest mismatch errors.

Practice this question →
85
MCQeasy

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?

A.The node is unreachable
B.The pod has a memory request that cannot be fulfilled
C.The pod does not tolerate the taint on the unreachable node and there is insufficient memory on other nodes
D.The pod has a node selector that does not match any node
AnswerC

The event indicates both a taint tolerance issue and insufficient memory. Both must be resolved for the pod to schedule.

Why this answer

Option C is correct. 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.

Practice this question →
86
Multi-Selectmedium

A node is 'NotReady'. Which THREE steps should you take to troubleshoot?

Select 3 answers
A.Check the kube-apiserver logs on the control plane
B.Reboot the node immediately
C.Check kubelet logs with 'journalctl -u kubelet'
D.SSH to the node and run 'systemctl status kubelet'
E.Run 'kubectl describe node <node-name>' to see conditions
AnswersC, D, E

Shows kubelet log entries.

Why this answer

Checking kubelet status (A), kubelet logs (B), and node conditions (D) are direct steps. Restarting the node (C) is drastic. Checking API server logs (E) is not the first step for a node issue.

Practice this question →
87
MCQeasy

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?

A.kubectl get events --field-selector involvedObject.name=web
B.kubectl logs web
C.kubectl describe pod web
D.kubectl exec web -- docker pull nginx
AnswerC

The describe command shows events including image pull errors.

Why this answer

'kubectl describe pod web' provides detailed information including events that show the exact error from the image pull attempt.

Practice this question →
88
MCQmedium

A pod is in ImagePullBackOff state. Which command is MOST useful to diagnose the issue?

A.kubectl logs <pod-name>
B.kubectl exec <pod-name> -- ls
C.kubectl get events --field-selector type=Warning
D.kubectl describe pod <pod-name>
AnswerD

Why this answer

kubectl describe pod shows events with the exact image pull error (e.g., unauthorized, not found).

Practice this question →
89
MCQhard

You run 'kubectl get pods' and see a pod with status 'ImagePullBackOff'. Which of the following is a possible cause?

A.The node has a disk pressure condition
B.The pod's resource limits are too low
C.The container image name is misspelled
D.The pod's liveness probe is failing
AnswerC

A misspelled image name will cause the kubelet to fail to pull the image, resulting in ImagePullBackOff.

Why this answer

Option A is correct. ImagePullBackOff occurs when the kubelet cannot pull the container image, often due to a wrong image name, tag, or authentication issue. Options B, C, and D cause other pod states.

Practice this question →
90
MCQmedium

You try to run 'kubectl logs mypod' and get the error: 'Error from server (BadRequest): container "myapp" in pod "mypod" is waiting to start: PodInitializing'. What does this mean?

A.The pod has crashed and is restarting.
B.The kubelet is not running on the node.
C.The container has a different name than specified.
D.The pod is still being initialized and the container has not started yet.
AnswerD

PodInitializing means init containers or container startup is in progress.

Why this answer

The pod is still initializing (e.g., pulling images, running init containers). Logs are not available until the main container starts.

Practice this question →
91
MCQmedium

A pod in the 'production' namespace is in CrashLoopBackOff state. Running 'kubectl describe pod web-app -n production' shows the event 'OOMKilled'. What is the most appropriate action to resolve this issue?

A.Increase the CPU request for the container
B.Delete the namespace and redeploy
C.Increase the memory limit in the container spec
D.Delete and recreate the pod
AnswerC

The container was killed due to memory limit; increasing it allows more memory.

Why this answer

OOMKilled means the container exceeded its memory limit. Increasing the memory limit is the correct fix.

Practice this question →
92
MCQmedium

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

A.kubectl get pod --namespace=production -o wide
B.kubectl describe pod --namespace=production
C.kubectl top node
D.kubectl top pod --namespace=production
AnswerD

Correct command to show resource usage of pods.

Why this answer

kubectl top pod --namespace=production shows CPU and memory usage for pods in that namespace.

Practice this question →
93
Multi-Selecteasy

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

Select 2 answers
A.kubectl describe pod pod-name
B.kubectl logs pod-name
C.kubectl exec pod-name -- logs
D.kubectl get pod pod-name -o yaml
E.kubectl logs pod-name --previous
AnswersB, E

This shows the current logs of the first container in the pod.

Why this answer

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.

Practice this question →
94
MCQhard

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?

A.Use 'kubectl exec -it <pod> -- env' to list environment variables
B.Run 'kubectl get configmap <configmap-name>' to verify the ConfigMap exists and contains the expected key
C.Increase the pod's memory limit to prevent OOM
D.Check the node's kubelet logs for errors
AnswerB

This directly checks if the ConfigMap exists.

Why this answer

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.

Practice this question →
95
MCQhard

A pod is in Running state but cannot connect to a service by its DNS name. 'kubectl exec <pod> -- curl http://my-service' fails. Which is the most likely cause?

A.The service type is NodePort
B.The pod's container image does not have curl installed
C.The pod is in a different namespace than the service
D.The service has no endpoints
AnswerC

Correct. DNS short name only works within the same namespace.

Why this answer

The service must be in the same namespace for DNS resolution by short name; otherwise, you need the full name <service>.<namespace>.svc.cluster.local.

Practice this question →
96
MCQeasy

A node in your cluster is reporting 'NotReady' status. You log into the node and run 'systemctl status kubelet'. The kubelet service is not running. Which command should you use to start the kubelet and enable it to start on boot?

A.systemctl start --enable kubelet
B.systemctl enable kubelet
C.systemctl enable --now kubelet
D.systemctl start kubelet
AnswerC

This enables the service on boot and starts it immediately.

Why this answer

The correct command is 'systemctl enable --now kubelet' which enables the service to start on boot and starts it immediately. Option A does not start it immediately. Option B is for restarting, not starting from stopped.

Option D is incorrect syntax.

Practice this question →
97
Multi-Selecthard

Which THREE of the following are valid commands to troubleshoot network connectivity between pods? (Select 3)

Select 3 answers
A.kubectl exec pod-a -- nslookup service-name
B.kubectl describe node | grep Network
C.kubectl logs pod-a | grep network
D.kubectl exec pod-a -- curl http://pod-b
E.kubectl exec pod-a -- ping pod-b-ip
AnswersA, D, E

Tests DNS resolution from within a pod.

Why this answer

kubectl exec can run networking tools inside a pod. curl is a common tool. nslookup tests DNS. ping tests basic connectivity.

Practice this question →
98
MCQmedium

After deploying a new Deployment, you run 'kubectl get events' and see 'FailedScheduling' events. What is a possible cause?

A.The container port is already in use on the node
B.The pod has a node selector that matches no nodes
C.The node has a taint that tolerates the pod
D.The pod's image pull secret is missing
AnswerB

If no node matches the node selector, the scheduler cannot place the pod.

Why this answer

FailedScheduling indicates the scheduler cannot place the pod, often due to taints or resource constraints.

Practice this question →
99
Multi-Selectmedium

Which TWO of the following are valid methods to view the logs of a container that has terminated?

Select 2 answers
A.kubectl exec <pod-name> -- cat /var/log/container.log
B.kubectl attach <pod-name>
C.kubectl describe pod <pod-name>
D.kubectl logs <pod-name> --previous
E.kubectl top pod <pod-name>
AnswersC, D

Shows last state and exit code, but not full logs.

Why this answer

kubectl logs --previous retrieves logs of the last terminated container. kubectl describe pod shows the last termination state and exit code. The other options are not valid.

Practice this question →
100
MCQhard

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?

A.The persistent volume claim requests more storage than the available persistent volumes
B.The storage class does not exist
C.The cluster does not have a default storage class
D.The pod that references the PVC has a missing volume mount
AnswerD

The pod's volume mount does not affect the PVC binding. The PVC can be bound independently of the pod.

Why this answer

Option D is correct. A pod using the PVC does not affect the PVC's binding process. The PVC is bound before the pod uses it.

Common causes are A (no storage class), B (no provisioner), and C (quota exceeded).

Practice this question →
101
MCQhard

You run 'kubectl top nodes' and get an error: 'error: metrics not available yet'. Which of the following is the MOST likely cause?

A.The Kubernetes API server is down
B.The kubelet is not running on all nodes
C.The Metrics Server is not deployed in the cluster
D.One or more nodes are in NotReady state
AnswerC

'kubectl top' requires Metrics Server to be installed; otherwise it returns this error.

Why this answer

Option D is correct. The 'metrics not available yet' error indicates that the Metrics Server is not installed or not functioning. Option A (node not ready) would show a different error.

Option B (kubelet not running) would cause node NotReady. Option C (API server down) would cause connection refused.

Practice this question →
102
MCQmedium

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?

A.Increase the pod's CPU request
B.Add a toleration to the pod spec
C.Remove the pod and recreate it
D.Delete the taint from the node
AnswerB

Tolerations allow the pod to schedule on tainted nodes.

Why this answer

The pod cannot tolerate the master taint. Remove the taint or add tolerations.

Practice this question →
103
MCQhard

A Pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient cpu.' Which of the following is the most likely combination of issues?

A.Three nodes have insufficient CPU for the pod's request, and one node has a taint not tolerated by the pod
B.The pod has a resource request that exceeds available CPU on all nodes
C.The pod does not tolerate any taints, and all nodes have taints
D.The cluster has only one node with sufficient CPU, but it is cordoned
AnswerA

The event message directly indicates both issues.

Why this answer

The event shows two distinct issues: one node has a taint that the pod doesn't tolerate, and three nodes have insufficient CPU. Option D correctly identifies both. Options A, B, C each miss one or both issues.

Practice this question →
104
MCQeasy

A pod named 'app' is not starting. You run 'kubectl describe pod app' and see the event: 'MountVolume.SetUp failed for volume "pvc-volume" : rpc error: code = NotFound desc = volume not found'. What is the most likely issue?

A.The container image is not found in the registry
B.The node running the pod is out of disk space
C.The pod has insufficient CPU resources
D.The PersistentVolumeClaim (PVC) referenced by the pod does not exist or is not bound
AnswerD

The error indicates the volume is not found, meaning the PVC is missing or not bound to a PV.

Why this answer

Option A is correct. The error 'volume not found' typically indicates the PVC does not exist or is not bound. Options B, C, and D cause different symptoms.

Practice this question →
105
MCQmedium

You run 'kubectl get pods' and see a pod named 'db' in CrashLoopBackOff. 'kubectl logs db' shows nothing. 'kubectl logs db --previous' shows 'Error: database connection failed'. What is the most likely cause?

A.The node is out of memory
B.The environment variable for database host is incorrect
C.The pod's liveness probe is misconfigured
D.The container image is missing
AnswerB

The error indicates the application cannot connect to the database, likely due to wrong host.

Why this answer

The previous logs indicate the container failed due to a database connection error, likely a misconfigured environment variable for the database host.

Practice this question →
106
MCQhard

A Service of type ClusterIP is not reachable from within the cluster. Pods backing the Service are running and healthy. What is the most likely cause?

A.DNS resolution failure
B.kube-proxy not running or misconfigured
C.Ingress controller not set up
D.Service type should be NodePort
AnswerB

Why this answer

When Pods are healthy but a ClusterIP Service is unreachable from within the cluster, the most common cause is that kube-proxy is not running or is misconfigured. kube-proxy is responsible for implementing the ClusterIP virtual IP by programming iptables (or IPVS) rules on each node to forward traffic to the selected Pods. Without these rules, packets destined for the ClusterIP are dropped or rejected, even though the Service and Endpoints objects exist.

Exam trap

The trap here is that candidates often assume a healthy Pod and Service object guarantee connectivity, overlooking that kube-proxy must actively program the underlying network rules to make the ClusterIP routable.

Why the other options are wrong

A

DNS resolves Service name to ClusterIP; connectivity fails after.

C

Ingress is for external; ClusterIP is internal.

D

ClusterIP works internally.

Practice this question →
107
Multi-Selecthard

Which TWO of the following could cause a Node to be in NotReady state?

Select 2 answers
A.The node has a taint that prevents scheduling
B.The kubelet process has stopped
C.The container runtime (containerd) is not responding
D.The node has insufficient disk space
E.The node's IP address has changed
AnswersB, C

If the kubelet stops, the node status becomes NotReady.

Why this answer

A Node is NotReady if the kubelet is not reporting healthy. Common causes include kubelet failure and network plugin issues.

Practice this question →
108
MCQmedium

You need to check the resource usage of nodes in your cluster. Which command should you run?

A.kubectl top nodes
B.kubectl get nodes -o wide
C.kubectl logs --all-containers
D.kubectl describe nodes
AnswerA

kubectl top nodes shows CPU and memory usage of nodes.

Why this answer

Option A is correct. kubectl top nodes uses the metrics server to display resource usage. Options B and C do not show resource usage. Option D is invalid.

Practice this question →
109
Multi-Selectmedium

Which of the following are valid methods to debug a failing CoreDNS pod? (Select TWO)

Select 2 answers
A.kubectl logs -n kube-system -l k8s-app=kube-dns
B.kubectl delete pod -n kube-system -l k8s-app=kube-dns
C.kubectl get endpoints -n kube-system kube-dns
D.kubectl scale deployment coredns --replicas=2
E.kubectl run -it --rm test --image=busybox -- nslookup kubernetes.default
AnswersA, C

Why this answer

Option A is correct because `kubectl logs -n kube-system -l k8s-app=kube-dns` retrieves the logs from all CoreDNS pods (which are labeled `k8s-app=kube-dns` in the `kube-system` namespace). This is a direct method to inspect errors, crashes, or misconfigurations in the DNS service. Option C is correct because `kubectl get endpoints -n kube-system kube-dns` shows the IP addresses of the pods backing the `kube-dns` service; if the endpoint list is empty, it indicates that no CoreDNS pods are ready to serve DNS requests, which is a common failure point.

Exam trap

The trap here is that candidates confuse debugging actions (like checking logs or endpoints) with recovery actions (like deleting or scaling pods), and they may also mistake client-side DNS tests (like `nslookup`) for pod-level debugging, which only confirms the symptom, not the cause.

Why the other options are wrong

B

Deleting a pod is a fix, not a debug method.

D

Scaling is a fix, not debugging.

E

This tests DNS resolution, not debugging CoreDNS pod itself.

Practice this question →
110
Multi-Selecthard

You have a Pod that is in CrashLoopBackOff. Which TWO of the following commands would be most helpful in diagnosing the issue?

Select 2 answers
A.kubectl get events --all-namespaces
B.kubectl logs <pod-name> --previous
C.kubectl describe pod <pod-name>
D.kubectl logs <pod-name>
E.kubectl top pod <pod-name>
AnswersB, C

Shows logs from the crashed container instance, which often contains the error.

Why this answer

Options A and B are correct. 'kubectl describe pod' shows events and container state, including termination reason. 'kubectl logs --previous' shows logs from the previous container instance. Option C shows current logs, which may be empty if the container crashes quickly. Option D shows resource usage, not crash reasons.

Option E shows general events, but describe already includes them for the specific Pod.

Practice this question →
111
MCQhard

A pod is stuck in Pending with event '0/4 nodes are available: 1 node(s) had taint "node.kubernetes.io/disk-pressure", and 3 node(s) had taint "node.kubernetes.io/memory-pressure", that the pod didn't tolerate'. What is the best approach to schedule the pod?

A.Use 'kubectl taint nodes --all node.kubernetes.io/disk-pressure- node.kubernetes.io/memory-pressure-' to remove the taints
B.Add tolerations for both taints to the pod spec
C.Free up disk space and reduce memory usage on the affected nodes
D.Delete the pod and recreate it with higher resource requests
AnswerC

This resolves the root cause by removing the taints, allowing the pod to schedule normally.

Why this answer

The cluster has nodes with disk-pressure and memory-pressure taints. These are typically added by the node controller when resources are low. The pod does not tolerate these taints.

The best approach is to free resources on the nodes or add tolerations; however, tolerating pressure taints is not recommended as it can cause further instability. Usually, you should resolve the underlying resource issues.

Practice this question →
112
MCQmedium

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

A.An init container in the pod is failing and restarting
B.The pod's init container ran successfully but the main container has not started yet
C.The pod is still initializing but will eventually run
D.The main container is crashing and the pod is restarting
AnswerA

The 'Init' prefix indicates the issue is with an init container.

Why this answer

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.

Practice this question →
113
MCQmedium

You run kubectl get nodes and see one node is NotReady. The kubelet is running on the node. What is the most likely cause?

A.The kubelet is not installed
B.Network connectivity issue between kubelet and API server
C.The node has been cordoned
D.The API server is down
AnswerB

Why this answer

When a node is NotReady but the kubelet is running, the most common cause is a network connectivity issue between the kubelet and the API server. The kubelet reports node status via periodic heartbeats (node-status-update-frequency, default 10s) and if the API server cannot receive these updates due to network problems (e.g., firewall rules, DNS resolution failure, or dropped packets), the node controller marks the node as NotReady after the node-monitor-grace-period (default 40s). The kubelet being running eliminates installation issues, and the API server being down would affect all nodes, not just one.

Exam trap

The trap here is that candidates confuse 'cordon' (which affects scheduling but not readiness) with 'NotReady' (which indicates a health or connectivity failure), leading them to pick Option C when the node is actually unreachable.

Why the other options are wrong

A

Question states kubelet is running.

C

Cordoning makes node Unschedulable, not NotReady.

D

If API server is down, kubectl get nodes would fail, not show NotReady.

Practice this question →
114
MCQmedium

A developer reports that a Pod named 'web-pod' in namespace 'frontend' is crashing repeatedly. You run 'kubectl logs web-pod -n frontend' but see no output. Which command should you run next to see the logs from the previous, crashed container instance?

A.kubectl get events -n frontend --sort-by=.metadata.creationTimestamp
B.kubectl logs web-pod -n frontend --previous
C.kubectl logs web-pod -n frontend -c web-pod
D.kubectl exec -it web-pod -n frontend -- sh
AnswerB

This retrieves logs from the previous crashed container.

Why this answer

'kubectl logs --previous' retrieves logs from the previous container instance, which is useful for debugging crash loops. Option A shows current logs (empty). Option C shows events.

Option D attempts to exec into a crashed container.

Practice this question →
115
MCQhard

A pod is in CrashLoopBackOff. The YAML for the initContainer is: apiVersion: v1 kind: Pod metadata: name: myapp spec: initContainers: - name: init image: busybox command: ['sh', '-c', 'sleep 5 && exit 1'] containers: - name: app image: nginx What is the most likely reason for the CrashLoopBackOff?

A.The main container image nginx is not pulled successfully
B.The init container command is misspelled
C.The init container exits with non-zero exit code
D.The pod has insufficient memory
AnswerC

Correct. Init container failure causes the pod to restart.

Why this answer

Init containers must complete successfully (exit 0) before the main container starts. An exit code 1 causes the pod to fail and restart.

Practice this question →
116
MCQmedium

A node in the cluster is showing status 'NotReady'. You run 'kubectl describe node worker1' and see that the kubelet has not posted node status for more than 1 minute. Which command should you run on the node to check the kubelet logs?

A.cat /var/log/kubelet/kubelet.log
B.kubectl logs kubelet -n kube-system
C.systemctl restart kubelet
D.journalctl -u kubelet
AnswerD

This command displays the logs of the kubelet service, which is essential for troubleshooting why the node is NotReady.

Why this answer

On systemd-based systems, 'journalctl -u kubelet' is the standard command to view kubelet logs. 'journalctl -f -u kubelet' follows the log, but the question asks for checking logs, not following.

Practice this question →
117
MCQmedium

You suspect the kubelet on a worker node has stopped. Which two commands should you run to confirm the kubelet status and check its logs?

A.systemctl status docker and tail -f /var/log/syslog
B.kubectl get nodes and kubectl describe node <node>
C.systemctl restart kubelet and journalctl -u containerd
D.systemctl status kubelet and journalctl -u kubelet
AnswerD

These are the standard commands to check kubelet status and logs.

Why this answer

To check if the kubelet is running, use 'systemctl status kubelet'. To view logs, use 'journalctl -u kubelet'. The other options target the wrong service or are not applicable.

Practice this question →
118
MCQeasy

You need to check the current resource usage of nodes in your cluster. Which command should you use?

A.kubectl top pods
B.kubectl get events
C.kubectl get nodes -o wide
D.kubectl top nodes
AnswerD

This shows CPU and memory usage of nodes.

Why this answer

Correct answer is B. 'kubectl top nodes' shows CPU and memory usage of nodes. Option A shows pods. Option C shows events.

Option D shows node status but not resource usage.

Practice this question →
119
MCQeasy

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

A.kubectl logs pod-name
B.kubectl get pod pod-name
C.kubectl get events
D.kubectl describe pod pod-name
AnswerD

Describe pod shows events related to that pod.

Why this answer

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.

Practice this question →
120
Multi-Selectmedium

You need to check the status of control plane components. Which TWO commands are appropriate?

Select 2 answers
A.kubectl get pods -n kube-system
B.systemctl status kube-apiserver
C.kubectl get componentstatuses
D.top -u kube
E.systemctl list-units --type=service
AnswersA, B

Shows pods for control plane components if running as static pods.

Why this answer

systemctl status kube-apiserver (B) and kubectl get pods -n kube-system (C) are standard methods. 'kubectl get componentstatuses' (A) is deprecated. 'systemctl list-units' (D) lists all units but is not targeted. 'top' (E) shows processes but not component health.

Practice this question →
121
MCQmedium

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?

A.Increase the memory limit in the pod's container resource specification
B.Increase the CPU request for the container
C.Delete and recreate the pod to clear the crash loop
D.Delete the namespace and redeploy all workloads
AnswerA

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

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.

Practice this question →
122
MCQmedium

A node shows status NotReady. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active (running). What is the next most likely step to diagnose the issue?

A.Restart the kubelet with systemctl restart kubelet
B.Check the container runtime status
C.Check kubelet logs with journalctl -u kubelet
D.Reboot the node
AnswerC

Logs can show why the kubelet reports NotReady, such as network issues or node pressure.

Why this answer

Even if the kubelet is running, it may be unhealthy. Checking the kubelet logs with 'journalctl -u kubelet' can reveal errors such as network plugin failures or node pressure.

Practice this question →
123
MCQmedium

You run 'kubectl get pods' and see a pod with status 'CrashLoopBackOff'. You check the logs with 'kubectl logs <pod> --previous' and see: 'Error: unable to connect to database at db-svc:5432 (connection refused)'. What is the most likely cause?

A.The pod's liveness probe is misconfigured
B.The pod's container image is missing
C.The database service is not running or is unreachable
D.The pod has a memory limit that is too low
AnswerC

Connection refused indicates the database service is not accepting connections on that port.

Why this answer

Option A is correct. Connection refused means the database service is not listening on port 5432, likely because it is not running or the service endpoint is incorrect. Options B, C, and D cause different errors.

Practice this question →
124
Multi-Selecthard

You have a pod that is 'CrashLoopBackOff'. 'kubectl logs --previous mypod' shows: 'Liveness probe failed: HTTP probe failed with statuscode: 503'. Which THREE actions could potentially fix the issue? (Choose three)

Select 4 answers
A.Change the liveness probe to a readiness probe.
B.Increase the initialDelaySeconds to give the app more time to start.
C.Change the liveness probe path to a valid endpoint that returns 200.
D.Increase the failureThreshold.
E.Remove the liveness probe entirely.
AnswersB, C, D, E

If the app takes longer to start, increasing initialDelaySeconds prevents premature failures.

Why this answer

The liveness probe is failing with 503, meaning the application is not ready or healthy. Fixes include correcting the probe endpoint, adjusting probe parameters, or fixing the application.

Practice this question →
125
MCQmedium

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?

A.The container is running out of memory
B.The image pull is failing
C.The container image does not contain the specified command
D.The container command is not in the PATH
AnswerC

If the command is not present in the image, the container fails to start.

Why this answer

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.

Practice this question →
126
MCQeasy

Which command shows events sorted by timestamp for troubleshooting recent issues?

A.kubectl logs --events
B.kubectl get events --sort-by=.lastTimestamp
C.kubectl describe events
D.kubectl get events
AnswerB

Sorts events by last timestamp, useful for chronological view.

Why this answer

kubectl get events with --watch or sorting by lastTimestamp. The simplest is 'kubectl get events --sort-by=.metadata.creationTimestamp'.

Practice this question →
127
MCQmedium

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

A.The liveness probe is misconfigured
B.The node has insufficient resources
C.The container image name or tag is incorrect
D.The container command fails on startup
AnswerC

An incorrect image name or tag prevents the image from being pulled, resulting in ImagePullBackOff.

Why this answer

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.

Practice this question →
128
MCQeasy

You have a pod that is in 'Pending' state because it requires a PersistentVolumeClaim that is not bound. Which event would you see in 'kubectl describe pod'?

A.0/1 nodes are available: 1 node(s) didn't match node selector
B.Failed to pull image "myimage:latest"
C.0/1 nodes are available: 1 Insufficient memory
D.0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims
AnswerD

This is the typical event when a PVC is not bound.

Why this answer

Option A is correct. When a pod is pending due to an unbound PVC, the event will mention 'persistentvolumeclaim' not found. Option B is for image pull issues.

Option C is for resource constraints. Option D is for node selector mismatch.

Practice this question →
129
MCQmedium

A pod is in Pending state. You see the event: '0/2 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. What should you do to schedule the pod on one of the control-plane nodes?

A.Increase the pod's resource requests
B.Remove the taint from the control-plane node
C.Use a different namespace
D.Add a toleration to the pod spec matching the taint
AnswerD

Correct. Tolerations allow scheduling on tainted nodes.

Why this answer

Tolerations allow pods to be scheduled on tainted nodes. Adding a toleration that matches the taint permits scheduling.

Practice this question →
130
MCQmedium

A pod named 'web-app' is crashing repeatedly. You run 'kubectl describe pod web-app' and see that the container exited with code 137. What does this indicate?

A.The container's entrypoint command failed
B.The container's readiness probe failed
C.The container image was not found
D.The container was killed because it exceeded its memory limit
AnswerD

Exit code 137 (128+9) indicates SIGKILL, commonly from OOM kill.

Why this answer

Exit code 137 means the container was killed by SIGKILL (128 + 9). This is often due to being OOM-killed when it exceeds its memory limit.

Practice this question →
131
MCQhard

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?

A.The ReplicaSet is not created
B.The Deployment's selector does not match the pod template labels
C.A PersistentVolumeClaim used by the pod is not bound
D.The node has a disk pressure condition
AnswerC

Correct. If a PVC is not bound, the pod stays Pending.

Why this answer

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

Practice this question →
132
MCQmedium

A pod is in ImagePullBackOff state. Which command can you run to get more details about the underlying error?

A.kubectl logs pod
B.kubectl get events --field-selector involvedObject.name=pod
C.kubectl describe pod
D.kubectl top pod
AnswerC

Events in the pod description include the reason for ImagePullBackOff.

Why this answer

kubectl describe pod shows events including the exact error message from the kubelet when pulling the image.

Practice this question →
133
Multi-Selectmedium

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

Select 2 answers
A.Node has insufficient CPU or memory resources
B.Container exited with non-zero exit code
C.PersistentVolumeClaim is not bound
D.Container was killed due to OOM
E.Image name is misspelled
AnswersA, C

If nodes lack resources, pods stay pending until resources become available.

Why this answer

Options A and D are correct. Insufficient CPU/memory resources and an unbound PVC are common reasons for a pod to remain pending. Option B (container exited) would cause CrashLoopBackOff or error state, not Pending.

Option C (image pull) would cause ImagePullBackOff. Option E (OOMKilled) would cause crash loop, not Pending.

Practice this question →
134
MCQmedium

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?

A.The pod's image is incorrect
B.The kubelet on each node is not running
C.The pod has resource requests that exceed node capacity
D.The nodes are all cordoned
AnswerB

When kubelet is down, nodes become NotReady and taint themselves, causing scheduling failures.

Why this answer

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.

Practice this question →
135
MCQhard

You want to test network connectivity from pod A to pod B in the same namespace. Which command would you run from within pod A?

A.kubectl logs pod-a | curl pod-b
B.kubectl port-forward pod-a 8080:8080 & curl localhost:8080
C.kubectl exec pod-a -- curl http://pod-b:8080
D.kubectl attach pod-a -- curl pod-b
AnswerC

Exec into pod A and use curl to reach pod B's IP or service.

Why this answer

kubectl exec allows running commands inside a container; curl is a common tool to test HTTP connectivity.

Practice this question →
136
Multi-Selectmedium

Which TWO of the following commands are useful for debugging network connectivity between pods?

Select 2 answers
A.kubectl top pod <pod-name>
B.kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port
C.kubectl edit deployment <deployment-name>
D.kubectl logs <pod-name>
E.kubectl exec <pod-name> -- ping <target-ip>
AnswersB, E

Run a temporary pod to test connectivity.

Why this answer

kubectl exec lets you run commands inside a pod (e.g., ping, curl). kubectl run creates a temporary pod for testing. kubectl logs and edit are not network debugging tools.

Practice this question →
137
MCQmedium

You suspect a DNS issue inside a pod. Which command can you run to test DNS resolution from within a pod?

A.kubectl logs coredns -n kube-system
B.kubectl describe svc kubernetes
C.kubectl run test --image=busybox -- nslookup kubernetes.default
D.kubectl exec <pod-name> -- nslookup kubernetes.default
AnswerD

nslookup from within a pod tests DNS resolution against the cluster's DNS service.

Why this answer

Option A is correct. Using kubectl exec to run nslookup inside an existing pod tests DNS resolution. Option B is for logs.

Option C shows service info. Option D creates a new pod, not using the existing one.

Practice this question →
138
MCQhard

A pod is running but cannot be accessed via its ClusterIP service from another pod in the same namespace. The service endpoints list shows the pod's IP. What is the most likely cause?

A.The kube-proxy is not running on the node
B.A NetworkPolicy is blocking the traffic
C.The service's targetPort is incorrect
D.The pod is running on a different node without proper routing
AnswerB

Why this answer

Option B is correct because a NetworkPolicy can explicitly deny ingress traffic to a pod even when the service endpoints are correctly populated. Since the endpoints list shows the pod's IP, the service and pod are communicating at the network layer, but a NetworkPolicy with an ingress rule that does not allow traffic from the source pod's labels or CIDR will cause the packet to be dropped by the node's iptables or eBPF rules, resulting in a connection timeout or reset from the client pod.

Exam trap

The trap here is that candidates assume a populated endpoints list guarantees connectivity, but they overlook that NetworkPolicies operate at a lower layer (L3/L4) and can block traffic even when the service and pod are correctly configured.

Why the other options are wrong

A

kube-proxy issues would affect all services cluster-wide, not just one service with correct endpoints.

C

If targetPort were wrong, endpoints might still show but traffic would not reach the container; but endpoints are based on the container port, so if endpoints exist, targetPort matches.

D

ClusterIP services work across nodes; no extra routing needed.

Practice this question →
139
Multi-Selecthard

You need to test network connectivity between two pods in different namespaces. Which TWO approaches are valid?

Select 2 answers
A.Run 'kubectl logs pod-a -n ns1' to see if it received packets
B.Run 'kubectl port-forward pod-a 8080:80' and test locally
C.Run 'kubectl run test-pod --image=busybox --rm -it --restart=Never -- nslookup pod-b'
D.Run 'kubectl exec pod-a -n ns1 -- curl <service-b-name.ns2.svc.cluster.local>'
E.Run 'kubectl exec pod-a -n ns1 -- curl <pod-b-IP>'
AnswersD, E

Tests connectivity to the service in another namespace.

Why this answer

Using kubectl exec to curl the other pod's IP (B) or service name (D) are direct methods. 'kubectl logs' (A) shows logs but does not test connectivity. 'kubectl port-forward' (C) is for local access. 'kubectl run' (E) can be used to create a temporary pod for testing, but the question asks for approaches to test connectivity between existing pods, so exec is more direct.

Practice this question →
140
MCQmedium

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?

A.Delete the namespace and redeploy all workloads
B.Increase the CPU request for the container
C.Delete and recreate the pod to clear the crash loop
D.Increase the memory limit in the pod's container resource specification
AnswerD

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

OOMKilled means the container exceeded its memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Practice this question →
141
MCQhard

A pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules'. What is the most likely cause?

A.The nodes have insufficient resources
B.The pod has a requiredDuringSchedulingIgnoredDuringExecution anti-affinity rule that is too restrictive
C.The pod has a taint tolerance issue
D.The nodes are all cordoned
AnswerB

Required anti-affinity must be satisfied for scheduling. If no node meets the constraint, the pod stays pending.

Why this answer

Pod anti-affinity rules prevent the pod from being scheduled on nodes that already have pods matching certain labels. The error indicates that all nodes are excluded due to anti-affinity constraints.

Practice this question →
142
MCQmedium

A pod is stuck in 'Pending' state. Which command would you run FIRST to diagnose the issue?

A.kubectl logs <pod-name>
B.kubectl describe pod <pod-name>
C.kubectl top pod <pod-name>
D.kubectl exec -it <pod-name> -- sh
AnswerB

Describes the pod with events and conditions.

Why this answer

A pod stuck in 'Pending' state means it has not been scheduled to a node yet. The `kubectl describe pod` command provides detailed event logs, scheduler decisions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims not bound, node selector mismatches) that reveal why scheduling failed. This is the first diagnostic step because it surfaces the root cause without requiring the pod to be running.

Exam trap

The trap here is that candidates often jump to `kubectl logs` or `kubectl exec` out of habit, forgetting that these commands only work for running pods, while 'Pending' indicates a pre-scheduling failure that requires inspecting events and conditions via `kubectl describe`.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` retrieves container logs, but a pod in 'Pending' has no running containers yet, so there are no logs to fetch. Option C is wrong because `kubectl top pod` shows real-time resource usage metrics, which require the pod to be running on a node; a pending pod has no metrics. Option D is wrong because `kubectl exec` requires a running container to execute commands, which is impossible when the pod is still pending.

Practice this question →
143
MCQmedium

You deploy a pod with image 'nginx:1.21'. It stays in ImagePullBackOff. You run 'kubectl describe pod nginx-pod' and see the event: 'Failed to pull image "nginx:1.21": rpc error: code = Unknown desc = Error response from daemon: manifest for nginx:1.21 not found'. What is the most likely fix?

A.Use a different container runtime
B.Add imagePullSecrets to the pod
C.Restart the kubelet on the node
D.Change the image tag to a valid one, e.g., nginx:1.21.6
AnswerD

The tag does not exist; using a valid tag resolves the issue.

Why this answer

The tag '1.21' does not exist in the registry. Use a valid tag like '1.21.6' or 'latest'.

Practice this question →
144
MCQmedium

A Node is in NotReady state. Which action should be taken first to diagnose the issue?

A.kubectl describe node <node>
B.Check kubelet logs on the node
C.Restart kubelet
D.Check API server logs
AnswerA

Why this answer

When a node is in NotReady state, the first diagnostic step is to gather information about the node's current status, conditions, and recent events using `kubectl describe node <node>`. This command reveals the node's conditions (e.g., Ready, DiskPressure, MemoryPressure), the last heartbeat timestamp, and any relevant events that may indicate the root cause, such as network issues or kubelet failures. It provides a high-level overview without requiring direct node access, making it the most efficient initial action.

Exam trap

The trap here is that candidates often jump to checking kubelet logs or restarting the kubelet, forgetting that `kubectl describe node` provides immediate visibility into node conditions and events from the control plane, which is the standard first step in the Kubernetes troubleshooting workflow.

Why the other options are wrong

B

Useful but not the first step; describe node gives overview.

C

Recovery action, not diagnosis.

D

Unlikely to show node conditions.

Practice this question →
145
Multi-Selectmedium

Which THREE of the following are valid steps to troubleshoot DNS issues in a Kubernetes cluster?

Select 3 answers
A.Run 'kubectl exec <pod> -- nslookup kubernetes.default'
B.Check the /etc/resolv.conf on the host
C.Restart all nodes in the cluster
D.Verify the kube-dns Service has endpoints
E.Check the logs of the CoreDNS pods
AnswersA, D, E

This tests DNS resolution from within a pod.

Why this answer

To troubleshoot DNS, you can check the DNS pod logs, test resolution from a pod, and verify the DNS service endpoints.

Practice this question →
146
MCQmedium

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?

A.kubectl exec pod-a -- nslookup service-b
B.curl http://<node-ip>:<nodeport>
C.ssh node-ip 'curl http://<pod-b-ip>:80'
D.kubectl exec pod-a -- curl http://service-b:80
AnswerD

This runs curl inside Pod A to the service name of Pod B, testing both DNS resolution and network connectivity from the pod's perspective.

Why this answer

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.

Practice this question →
147
MCQmedium

You are debugging a DNS issue from within a pod. The pod is running 'busybox'. Which command would you use to test DNS resolution for 'kubernetes.default.svc.cluster.local'?

A.kubectl describe svc kubernetes -n default
B.kubectl exec -it my-pod -- curl kubernetes.default.svc.cluster.local
C.kubectl run test --image=busybox -- nslookup kubernetes.default.svc.cluster.local
D.kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local
AnswerD

This runs nslookup inside the pod to test DNS resolution of the service name.

Why this answer

nslookup is a standard DNS troubleshooting tool available in many images.

Practice this question →
148
MCQmedium

Based on the exhibit, the pod is in CrashLoopBackOff. Which command should you run NEXT to identify the root cause?

A.kubectl describe node node-1
B.kubectl top pod api-6f4d7b9d4c-abcde -n production
C.kubectl get deployment api -n production -o yaml
D.kubectl logs api-6f4d7b9d4c-abcde -n production --previous
AnswerD

Shows logs from the crashed container instance.

Why this answer

The pod is in CrashLoopBackOff, which means the container starts, crashes, and restarts repeatedly. The `kubectl logs --previous` command retrieves the logs from the previous (crashed) container instance, which is the fastest way to see the error that caused the crash. This directly reveals the root cause, such as a missing dependency, configuration error, or application panic.

Exam trap

The trap here is that candidates may think `kubectl describe pod` or `kubectl get deployment` is needed to check the pod's status or configuration, but the fastest way to see the crash reason is the previous container's logs, not the current (restarted) container's logs which may be empty.

How to eliminate wrong answers

Option A is wrong because `kubectl describe node` shows node-level conditions and resource usage, not the application error causing the container to crash. Option B is wrong because `kubectl top pod` shows current CPU/memory metrics, which are irrelevant to a crash loop caused by an application error. Option C is wrong because `kubectl get deployment -o yaml` shows the desired state and pod template, but not the runtime logs or crash reason from the container.

Practice this question →
149
Multi-Selecthard

You are troubleshooting a pod that is in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 Insufficient memory, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. Which TWO actions can resolve the issue?

Select 2 answers
A.Reduce the memory request in the container spec to fit available memory
B.Add a node selector to the pod spec to target a specific node
C.Increase the memory request to prioritize scheduling
D.Add resource limits without changing requests
E.Add a toleration for the control-plane taint to the pod spec
AnswersA, E

Reducing memory request may allow the pod to fit on a node.

Why this answer

Adding a toleration (B) and reducing memory request (C) address the two issues: taint and insufficient memory. Adding a node selector (A) would not help if taint is not tolerated. Increasing memory request (D) worsens the problem.

Adding resource limits (E) does not resolve scheduling constraints.

Practice this question →
150
Multi-Selecteasy

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

Select 2 answers
A.Container is killed due to OOM
B.Container image pull fails because of authentication error
C.Not enough CPU or memory available on any node
D.Node is rebooted
E.Node has a taint that the pod does not tolerate
AnswersC, E

Resource constraints prevent scheduling, causing Pending.

Why this answer

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.

Practice this question →
← PreviousPage 2 of 4 · 290 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Cka Troubleshooting questions.

Start 20-question session