Courseiva

CCNA Cka Troubleshooting Questions

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

Practice these questionsExam hubAll questions
151
MCQeasy

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?

A.The pod's container image is not found
B.The pod has a resource request that cannot be met by any node
C.The nodes are unreachable or have network issues
D.The PersistentVolumeClaim is not bound
AnswerC

The taint node.kubernetes.io/unreachable is automatically added by the node controller when a node becomes unreachable. The pod does not tolerate this taint, so it cannot be scheduled.

Why this answer

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

Practice this question →
152
MCQeasy

Which command shows resource usage (CPU and memory) for nodes in a cluster?

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

Shows CPU and memory usage of nodes.

Why this answer

kubectl top nodes displays resource usage if metrics-server is installed.

Practice this question →
153
MCQeasy

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

A.kubectl exec pod-name -- cat /var/log/app.log
B.kubectl describe pod pod-name
C.kubectl logs pod-name --previous
D.kubectl logs pod-name
AnswerD

Shows current container logs.

Why this answer

kubectl logs pod-name shows logs of the currently running container.

Practice this question →
154
Multi-Selectmedium

Which TWO actions can help troubleshoot a service that is not reachable from within a pod?

Select 2 answers
A.Use kubectl delete svc and recreate
B.Use kubectl exec to curl the service IP from a pod
C.Use kubectl logs on the service pod to see application logs
D.Use kubectl top nodes to check resource usage
E.Use kubectl describe svc to check endpoints
AnswersB, E

Correct. This tests connectivity directly.

Why this answer

Checking endpoints and using curl from a pod are direct troubleshooting steps.

Practice this question →
155
MCQmedium

A pod is in 'ImagePullBackOff' state. Which of the following is NOT a common cause?

A.The image registry requires authentication and no imagePullSecrets are configured
B.The image tag does not exist
C.The image name is misspelled
D.The container requires more memory than the limit allows
AnswerD

Memory issues cause OOMKilled, not ImagePullBackOff.

Why this answer

Option B is correct. Insufficient memory would cause OOMKilled, not ImagePullBackOff. ImagePullBackOff is caused by issues pulling the container image: wrong image name, authentication failure, registry unreachable, or image not found.

Option A, C, and D are all common causes.

Practice this question →
156
MCQeasy

A pod is in ImagePullBackOff state. Which command would give you the most information about why the image pull failed?

A.kubectl get pod
B.kubectl logs <pod-name>
C.kubectl edit pod <pod-name>
D.kubectl describe pod <pod-name>
AnswerD

Shows events with error details.

Why this answer

kubectl describe pod shows events including the exact error message from the kubelet when trying to pull the image.

Practice this question →
157
MCQhard

Based on the exhibit, what is the most likely cause of the pod not running?

A.The volume driver is not installed on node-1.
B.The pod has exceeded its resource limits.
C.The node 'node-1' is experiencing disk pressure.
D.The Secret 'my-secret' does not exist in the namespace.
AnswerD

The event explicitly says secrets "my-secret" not found.

Why this answer

The correct answer is D because the pod's status indicates it is waiting for a secret to be mounted, and the error message 'secret "my-secret" not found' directly points to the missing Secret resource. Without the Secret existing in the same namespace as the pod, the volume mount fails, preventing the pod from starting.

Exam trap

The trap here is that candidates may assume the issue is node-level (disk pressure or driver) or resource-related, overlooking the specific error message about the missing Secret, which is a common misdirection in CKA troubleshooting questions.

How to eliminate wrong answers

Option A is wrong because a missing volume driver would typically result in a different error, such as 'failed to mount volume' or 'driver not supported', not a secret not found error. Option B is wrong because exceeding resource limits would cause the pod to be in a CrashLoopBackOff or OOMKilled state, not a waiting state for a secret. Option C is wrong because disk pressure on node-1 would manifest as pod eviction or scheduling failures, not a secret mount error.

Practice this question →
158
Multi-Selectmedium

You run 'kubectl logs pod-name' and get no output. Which TWO steps should you take to troubleshoot further?

Select 2 answers
A.Run 'kubectl get events --all-namespaces'
B.Run 'kubectl top pod pod-name' to check resource usage
C.Run 'kubectl describe pod pod-name' to check container state and events
D.Run 'kubectl logs --previous pod-name'
E.Run 'kubectl exec pod-name -- cat /var/log/container.log'
AnswersC, D

Describes the pod and may reveal why logs are missing.

Why this answer

kubectl logs --previous (A) retrieves logs from the previous container instance, useful if the pod restarted. kubectl describe pod (B) shows container state and events. 'kubectl exec' (C) runs commands but does not show logs. 'kubectl top pod' (D) shows resource usage. 'kubectl get events' (E) shows cluster events; though useful, the two most direct steps for missing logs are --previous and describe.

Practice this question →
159
Multi-Selecthard

You are troubleshooting a scenario where a pod cannot communicate with another pod in the same namespace via service name. Which THREE steps would you take to diagnose the issue? (Select 3)

Select 3 answers
A.Run 'kubectl get nodes' to check node status
B.Run 'kubectl get endpoints' to verify the service has healthy endpoints
C.Exec into the pod and use curl to test connectivity to the service's cluster IP
D.Run 'kubectl logs' on the target pod to check application logs
E.Exec into the pod and run nslookup to verify DNS resolution of the service name
AnswersB, C, E

If endpoints are missing, the service cannot route traffic to pods.

Why this answer

Options A, B, and C are correct. Testing DNS resolution with nslookup, checking connectivity with curl, and examining the service's endpoints are standard troubleshooting steps. Option D checks node status, which is less direct.

Option E checks pod logs, which may not reveal network issues.

Practice this question →
160
MCQeasy

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event '0/1 nodes are available: 1 Insufficient cpu'. What is the most likely cause?

A.The pod's memory limit is too low
B.The pod is trying to use a GPU that is not available
C.The pod's CPU request exceeds available node CPU
D.The kubelet on the node is not running
AnswerC

Correct. The event explicitly states insufficient CPU.

Why this answer

The event indicates that no node has enough free CPU to satisfy the pod's CPU request.

Practice this question →
161
MCQmedium

A pod is in ImagePullBackOff. Which command would help determine the exact reason?

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

Why this answer

The `kubectl describe pod <pod>` command provides detailed information about the pod, including the container state, the exact error message from the image pull (e.g., 'ImagePullBackOff'), and the underlying reason (e.g., 'Back-off pulling image', 'manifest for image not found', or 'unauthorized: authentication required'). This is the most direct way to see the specific error without needing to access the container or parse raw events.

Exam trap

CNCF often tests the misconception that `kubectl logs` can diagnose startup failures, but logs are only available after the container has started, making `kubectl describe pod` the correct tool for pre-start errors like ImagePullBackOff.

Why the other options are wrong

A

Container hasn't started; no logs.

C

Shows all events, not specific to pod.

D

Pod not running.

Practice this question →
162
Multi-Selecteasy

Which TWO commands show cluster events that can help in troubleshooting?

Select 2 answers
A.kubectl cluster-info
B.kubectl logs <pod-name>
C.kubectl top pods
D.kubectl describe pod <pod-name>
E.kubectl get events
AnswersD, E

Includes events related to the pod.

Why this answer

Option D is correct because `kubectl describe pod <pod-name>` provides a detailed summary of a pod's lifecycle, including events such as failed pulls, backoff restarts, and scheduling failures. These events are embedded in the pod's status and are essential for troubleshooting pod-level issues. Option E is correct because `kubectl get events` lists all cluster-wide events sorted by timestamp, allowing you to see node failures, volume mount errors, and other cluster-level anomalies.

Exam trap

The trap here is that candidates often confuse `kubectl logs` (which shows container output) with event viewing, or assume `kubectl cluster-info` provides troubleshooting events, when in fact only `kubectl describe` and `kubectl get events` surface the cluster's event history.

Practice this question →
163
MCQhard

A pod is in CrashLoopBackOff. 'kubectl logs my-pod --previous' shows: 'Error: failed to start: exec: "/app/start.sh": stat /app/start.sh: no such file or directory'. What is the most likely cause?

A.The pod's service account lacks permissions.
B.The container image is missing the startup script.
C.The pod's liveness probe is misconfigured.
D.The pod has run out of memory.
AnswerB

The error 'no such file or directory' for /app/start.sh means the script is not present in the image.

Why this answer

The error indicates the specified entrypoint script is missing. This is often due to the container image not containing the script at the expected path, or the command/args in the pod spec referencing a non-existent file.

Practice this question →
164
Multi-Selectmedium

You run 'kubectl get pods' and see a pod with status 'CrashLoopBackOff'. Which TWO commands can help you investigate the cause?

Select 2 answers
A.kubectl exec pod-name -- /bin/sh
B.kubectl logs pod-name
C.kubectl get events
D.kubectl top pod pod-name
E.kubectl describe pod pod-name
AnswersB, E

Shows container logs that may reveal crash reasons.

Why this answer

'kubectl logs pod-name' (C) shows the container logs, and 'kubectl describe pod pod-name' (D) shows events and state. 'kubectl get events' (A) can help but is less direct. 'kubectl top pod' (B) shows resource usage but not crash details. 'kubectl exec' (E) might not work if the pod is crashing.

Practice this question →
165
MCQeasy

You suspect the kubelet on a worker node is not functioning correctly. Which command should you use to check the kubelet service status?

A.kubectl get nodes
B.systemctl status kubelet
C.kubectl describe node <node-name>
D.journalctl -u kubelet
AnswerB

Directly checks the kubelet service status on the node.

Why this answer

systemctl status kubelet shows the current status, recent logs, and whether the service is active. kubectl get nodes shows node status but not kubelet service details.

Practice this question →
166
Multi-Selecthard

You have a pod that is in CrashLoopBackOff. Which two troubleshooting steps should you take first? (Choose two.)

Select 2 answers
A.kubectl describe pod pod-name
B.kubectl delete pod pod-name
C.kubectl logs pod-name --previous
D.kubectl exec -it pod-name -- sh
E.kubectl rollout restart deployment
AnswersA, C

Shows events and recent state changes.

Why this answer

Check the logs with kubectl logs --previous to see the crash reason, and describe the pod to see events and state.

Practice this question →
167
MCQmedium

A Deployment named 'web' is failing to schedule pods. You run 'kubectl describe pod web-xyz' and see the event: '0/3 nodes are available: 3 Insufficient cpu.' What is the most likely cause?

A.The CPU request in the pod spec is too high
B.The network plugin is misconfigured
C.The nodes have insufficient memory
D.The kubelet is not running on the nodes
AnswerA

The cluster lacks enough allocatable CPU on any node.

Why this answer

The error indicates that CPU requests are too high for the available node resources. Reducing CPU requests or adding more nodes can fix it.

Practice this question →
168
Multi-Selectmedium

Which TWO of the following are common causes for a pod to be in the 'Pending' state?

Select 2 answers
A.The container image is not found
B.Insufficient cluster resources (CPU/memory) to schedule the pod
C.The pod's liveness probe is failing
D.A PersistentVolumeClaim (PVC) referenced by the pod is not bound
E.The node is unreachable due to network issues
AnswersB, D

If nodes lack resources, the pod stays pending.

Why this answer

Options A and C are correct. Insufficient resources and unbound PVCs are common causes for Pending pods. Option B causes ImagePullBackOff.

Option D causes CrashLoopBackOff. Option E may cause Unknown state.

Practice this question →
169
MCQmedium

You see a pod in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 1 node(s) had taint(s) that the pod didn't tolerate, 3 Insufficient cpu'. What should you do?

A.Delete the taint from the node
B.Scale down other deployments to free CPU
C.Increase the CPU limits only
D.Add the required toleration to the pod spec and increase CPU requests
AnswerD

Addresses both issues: toleration for the taint and CPU resource adjustment.

Why this answer

The pod cannot tolerate node taints and there is insufficient CPU. Either add tolerations or increase resources.

Practice this question →
170
Multi-Selecthard

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

Select 3 answers
A.Node taints that the pod does not tolerate
B.Image pull backoff
C.Container OOMKilled
D.Insufficient CPU or memory resources on any node
E.PersistentVolumeClaim is not bound
AnswersA, D, E

Taints prevent scheduling unless tolerated.

Why this answer

Pending means the pod is not scheduled. Common reasons include resource constraints, taint/toleration mismatch, and unbound PVCs. Image pull errors and OOMKilled occur after scheduling.

Practice this question →
171
MCQmedium

A pod is in CrashLoopBackOff. You run 'kubectl logs mypod --previous' and see 'Error: unable to connect to database'. What is the MOST likely cause?

A.The database service endpoint is unreachable
B.The pod's readiness probe is failing
C.The pod's liveness probe is misconfigured
D.The pod is out of memory
AnswerA

Why this answer

The previous logs show a connection error to the database, indicating the application cannot reach the database service.

Practice this question →
172
MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see: '0/4 nodes are available: 4 node(s) didn't match pod anti-affinity constraints'. What does this mean?

A.The pod has a taint that no node tolerates.
B.The pod has a node selector that doesn't match any node.
C.The pod's anti-affinity rule conflicts with all existing pods on every node.
D.The cluster is out of resources.
AnswerC

Anti-affinity rules ensure the pod does not co-locate with certain pods; if all nodes have those pods, the pod cannot be scheduled.

Why this answer

Pod anti-affinity rules prevent the pod from being scheduled on nodes where certain other pods are running. In this case, all nodes have pods that violate the anti-affinity rules.

Practice this question →
173
MCQmedium

You want to check the logs of a container that previously crashed. Which command should you use?

A.kubectl logs --previous <pod-name>
B.kubectl logs <pod-name>
C.kubectl exec <pod-name> -- cat /var/log/app.log
D.kubectl describe pod <pod-name>
AnswerA

The --previous flag shows logs from the last terminated container.

Why this answer

kubectl logs --previous retrieves logs from the previous instance of the container.

Practice this question →
174
MCQhard

You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff'. 'kubectl logs pod' shows no output, but 'kubectl logs --previous pod' shows an error. Why might the current logs be empty?

A.The pod is using a sidecar log shipper
B.The kubelet log level is too low
C.The log file was rotated and deleted
D.The container exited before writing any logs to stdout
AnswerD

Why this answer

If the container fails very quickly (e.g., init error), it may not output any logs; only the previous instance's logs exist.

Practice this question →
175
Multi-Selectmedium

Which TWO of the following are common causes for a pod to be stuck in Pending state?

Select 2 answers
A.Node taints that the pod does not tolerate
B.Insufficient CPU or memory resources in the cluster
C.Image pull failure (ImagePullBackOff)
D.PersistentVolumeClaim is in Pending state
E.Container exited with OOMKilled
AnswersA, B

If all nodes have taints that the pod doesn't tolerate, it cannot be scheduled.

Why this answer

Pending state means the pod has not been scheduled. Insufficient cluster resources and taint/toleration mismatch are common causes. ImagePullBackOff and OOMKilled are pod startup issues that occur after scheduling.

Practice this question →
176
Multi-Selecthard

A node is NotReady. Which THREE conditions could cause this?

Select 3 answers
A.Network plugin (e.g., Calico) is not functioning
B.A pod is in CrashLoopBackOff
C.kubelet service is stopped
D.Disk pressure on the node
E.The API server is overloaded
AnswersA, C, D

Correct. Networking issues can cause node readiness to fail.

Why this answer

Kubelet stopped, network plugin issues, and disk pressure can all cause a node to become NotReady.

Practice this question →
177
Multi-Selecthard

Which THREE of the following are valid steps to troubleshoot a node that is in 'NotReady' state?

Select 3 answers
A.Check the kubelet status using 'systemctl status kubelet' on the node
B.View kubelet logs using 'journalctl -u kubelet'
C.Check node conditions with 'kubectl describe node <node-name>'
D.Restart the kubelet using 'systemctl restart kubelet'
E.Delete the node object and rejoin it to the cluster
AnswersA, B, C

Checking the kubelet status is a fundamental step.

Why this answer

Options A, C, and D are valid troubleshooting steps. Option B is a remediation action, not troubleshooting. Option E is a recovery step.

Practice this question →
178
Multi-Selecthard

A ClusterIP Service is not reachable from within the cluster. You verify that the Service has endpoints. Which of the following could be the cause? (Select three.)

Select 3 answers
A.kube-proxy is not running on the node.
B.The container is listening on a different port than the Service targetPort.
C.The pod's readiness probe is failing.
D.The Service name is too long.
AnswersA, B, C

Why this answer

Option A is correct because kube-proxy is the component responsible for implementing the ClusterIP Service networking rules (e.g., iptables or IPVS) on each node. If kube-proxy is not running, traffic destined for the Service's ClusterIP will not be forwarded to the endpoints, even if the Service has valid endpoints. This is a common cause of unreachable Services.

Exam trap

The trap here is that candidates might think a failing readiness probe only affects traffic from Services, but in fact, a failing readiness probe removes the pod from the Service's endpoints, so the Service would have no endpoints—contradicting the premise that endpoints exist.

Why the other options are wrong

D

Service name length does not affect connectivity.

Practice this question →
179
MCQmedium

You run 'kubectl get events --sort-by=.lastTimestamp' and see the following events for a pod: 'Warning FailedScheduling 0/3 nodes are available: 3 Insufficient cpu'. What is the most likely solution?

A.Reduce the CPU request for the pod or remove other workloads to free CPU
B.Change the scheduler to a different one
C.Increase the CPU limit for the pod
D.Add more nodes to the cluster
AnswerA

Reducing the CPU request allows the pod to fit on a node with available CPU. Alternatively, removing other workloads frees up CPU. Both address the root cause.

Why this answer

Option D is correct. The event indicates that all nodes lack sufficient CPU to schedule the pod. The pod's CPU request is too high given the available resources.

Option A might help but is not guaranteed if the pod's request is still too high. Option B (increasing resource limits) would make the problem worse. Option C (changing scheduler) would not fix the resource shortage.

Practice this question →
180
MCQmedium

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?

A.The application is crashing at startup due to a missing dependency
B.The container is being OOMKilled because memory limit is too low
C.The readiness probe is failing
D.The container has insufficient CPU resources
AnswerA

This is the most likely cause. The container exits with an error, leading to CrashLoopBackOff.

Why this answer

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.

Practice this question →
181
MCQhard

A pod has status 'Init:Error'. What does this indicate?

A.The main container has crashed
B.An init container failed
C.The pod is being initialized
D.There is a network error during initialization
AnswerB

Why this answer

The 'Init:Error' status indicates that a pod's init container has failed to complete successfully. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, the pod enters this error state. This is distinct from a main container crash, which would show as 'CrashLoopBackOff' or 'Error' after the pod has started.

Exam trap

The trap here is that candidates confuse 'Init:Error' with a pod initialization phase or a main container error, when in fact it specifically indicates a failed init container that prevents the pod from reaching the running state.

Why the other options are wrong

A

Main container status would be CrashLoopBackOff or Error.

C

That would be Init:0/1 etc.

D

Network error would show as Init:NetworkNotReady or similar.

Practice this question →
182
MCQeasy

You run 'kubectl get pods' and one pod shows 'ImagePullBackOff'. Which command would help you diagnose the issue?

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

Correct. Events show the pull error.

Why this answer

kubectl describe pod shows events, including the exact error from the image pull.

Practice this question →
183
MCQhard

A pod is stuck in ContainerCreating. Which condition is most likely if `kubectl describe pod` shows 'Failed to create pod sandbox'?

A.Image pull failure
B.CNI plugin issue
C.Node disk pressure
D.Incorrect security context
AnswerB

Why this answer

The error 'Failed to create pod sandbox' indicates that the container runtime (e.g., containerd or CRI-O) was unable to set up the necessary Linux namespaces and cgroups for the pod. This is almost always caused by a CNI plugin issue, such as a misconfigured or missing network plugin (e.g., Calico, Flannel, Weave), which prevents the sandbox from being initialized. Image pull failures produce 'ErrImagePull' or 'ImagePullBackOff', not sandbox creation errors.

Exam trap

The trap here is that candidates confuse 'Failed to create pod sandbox' with image-related errors, assuming a missing image is the root cause, when the error specifically points to the container runtime's inability to initialize the pod's network environment.

Why the other options are wrong

A

Would show ImagePullBackOff, not sandbox error.

C

Would show node condition, not this error.

D

Might prevent container start but not sandbox creation.

Practice this question →
184
Multi-Selecthard

Which THREE of the following are valid steps to troubleshoot a DNS issue within a Kubernetes cluster?

Select 3 answers
A.Verify that the kube-dns service has endpoints using 'kubectl get endpoints -n kube-system kube-dns'
B.Check the logs of the CoreDNS pods using 'kubectl logs -n kube-system -l k8s-app=kube-dns'
C.Check the /etc/resolv.conf on the node
D.Restart all nodes to reset DNS settings
E.Run 'kubectl exec -it busybox -- nslookup kubernetes.default'
AnswersA, B, E

If no endpoints, DNS service is not routing to pods.

Why this answer

Option A is correct because the `kubectl get endpoints -n kube-system kube-dns` command verifies that the kube-dns service has at least one endpoint (i.e., a ready CoreDNS pod). If the service has no endpoints, DNS queries will fail because there is no backend to handle them. This is a fundamental step in troubleshooting DNS in Kubernetes, as it confirms the service is properly connected to running pods.

Exam trap

CNCF often tests the misconception that node-level configuration files like `/etc/resolv.conf` are relevant for cluster-internal DNS troubleshooting, when in fact the issue is almost always within the CoreDNS pods or service endpoints.

Practice this question →
185
MCQeasy

You have a pod that is in 'Pending' state. Which command would you run to get more information about why the pod cannot be scheduled?

A.kubectl logs <pod-name>
B.kubectl get events
C.kubectl get pod <pod-name> -o wide
D.kubectl describe pod <pod-name>
AnswerD

Describe pod shows detailed information including events related to scheduling failures.

Why this answer

Correct answer is B. 'kubectl describe pod' shows detailed information including events that explain scheduling issues. Option A shows current logs but not scheduling details. Option C shows events cluster-wide, not specific to the pod.

Option D shows pod status briefly.

Practice this question →
186
MCQhard

You have a pod that is stuck in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match pod anti-affinity rules.' What is the MOST likely solution?

A.Cordon the master node to remove it from scheduling
B.Remove or modify the pod anti-affinity rules
C.Add a toleration for the master taint to the pod spec
D.Delete and recreate the pod
AnswerB

Removing or adjusting the anti-affinity rules will allow the pod to be scheduled on the available nodes.

Why this answer

Correct answer is C. The pod has anti-affinity rules that prevent it from being scheduled on the two nodes, and the third node has a taint. The solution is to remove the anti-affinity rules or adjust them.

Option A is not correct because tolerating the master taint would still leave the anti-affinity issue. Option B is not specific enough. Option D is incorrect because the node is not unschedulable.

Practice this question →
187
MCQmedium

You run 'kubectl logs my-pod -c my-container' and get no output, but you know the container produces logs. What should you do next to see previous container logs?

A.kubectl logs my-pod -c my-container -f
B.kubectl logs my-pod -c my-container --previous
C.kubectl logs my-pod -c my-container --tail=50
D.kubectl logs my-pod -c my-container --all-containers
AnswerB

Correct flag to see logs from a terminated container.

Why this answer

The --previous flag retrieves logs from the previous instance of a crashed container.

Practice this question →
188
MCQeasy

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?

A.kubectl logs <pod-name>
B.kubectl describe pod <pod-name>
C.kubectl exec <pod-name> -- /bin/sh
D.kubectl get pod <pod-name>
AnswerB

kubectl describe provides detailed status, conditions, and events for a Pod, which helps identify why it is Pending.

Why this answer

Option A is correct. 'kubectl describe pod <pod-name>' 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.

Practice this question →
189
MCQmedium

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?

A.The kubernetes service does not exist
B.The pod's /etc/resolv.conf points to an incorrect DNS server IP
C.The pod does not have network connectivity
D.The kube-dns service is not exposed
AnswerB

The pod's DNS configuration could be wrong, or CoreDNS is not resolving correctly.

Why this answer

The DNS server IP might be wrong or CoreDNS might not be running. The resolver file in the pod typically points to the cluster DNS service IP.

Practice this question →
190
MCQhard

A Service of type LoadBalancer is created but the EXTERNAL-IP remains <pending>. The cluster is running on-premises without a cloud load balancer integration. Which of the following is the most likely reason?

A.The cluster has no default storage class.
B.The nodes are not reachable from the internet.
C.No load balancer controller (e.g., MetalLB) is installed.
D.The Service selector does not match any pods.
AnswerC

Why this answer

A Service of type LoadBalancer in Kubernetes requires an external load balancer controller to provision an external IP address. In on-premises clusters without cloud integration, no such controller exists by default, so the EXTERNAL-IP remains <pending> until a bare-metal load balancer like MetalLB is installed and configured. Option C is correct because without a load balancer controller, Kubernetes cannot assign an external IP.

Exam trap

The trap here is that candidates may confuse the EXTERNAL-IP <pending> state with networking issues (Option B) or pod connectivity (Option D), when the root cause is the absence of a load balancer controller, a concept specific to on-premises Kubernetes deployments.

Why the other options are wrong

A

Storage class is unrelated to LoadBalancer IP assignment.

B

Even if nodes are unreachable, a cloud LB would still assign an IP; on-premises, the LB controller would assign an IP from a pool.

D

A mismatched selector would result in no endpoints, but the external IP could still be assigned (pending also occurs if there's no controller).

Practice this question →
191
MCQmedium

You attempt to schedule a pod but it remains 'Pending'. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) didn't match node selector.' What is the MOST likely cause?

A.A PersistentVolumeClaim is not bound
B.All nodes have insufficient memory or CPU
C.The nodes have taints that the pod does not tolerate
D.The pod's nodeSelector does not match any node labels
AnswerD

Node selector mismatch prevents the pod from being scheduled on any node.

Why this answer

Option A is correct. The error 'didn't match node selector' indicates that the pod has a nodeSelector that does not match any node's labels. Option B would show a different event (resource pressure).

Option C would show an event about taints. Option D (PVC not bound) would show a different event.

Practice this question →
192
Multi-Selectmedium

A Pod is in ImagePullBackOff state. Which of the following are valid troubleshooting steps? (Select two.)

Select 2 answers
A.Run `kubectl describe pod <pod-name>` to view events.
B.Run `kubeadm reset` on the node.
C.Check if the image tag exists in the container registry.
D.Increase the pod's resource limits.
AnswersA, C

Why this answer

A is correct because `kubectl describe pod <pod-name>` shows recent events, including the exact error message from the kubelet when it failed to pull the image (e.g., 'ImagePullBackOff', 'ErrImagePull', or 'Back-off pulling image'). This provides the first diagnostic clue, such as a typo in the image name or a registry authentication failure.

Exam trap

CNCF often tests the misconception that resource limits affect image pulling, but ImagePullBackOff is strictly a container image retrieval issue, not a resource scheduling or limit problem.

Why the other options are wrong

B

kubeadm reset reinitializes the node, unrelated to image pulls.

D

Resource limits don't affect image pulling.

Practice this question →
193
MCQhard

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?

A.The service selector does not match pod labels
B.The backend pods are not ready
C.The service is not in the same namespace
D.The application inside the pod is not listening on the targetPort
AnswerD

Connection refused means the port is reached but no process is listening.

Why this answer

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

Practice this question →
194
MCQhard

You are troubleshooting a connectivity issue between two pods in the same cluster. Pod A cannot reach Pod B's IP. Which command would you run from Pod A to test connectivity?

A.kubectl exec pod-a -- curl <pod-b-ip>
B.kubectl top pod pod-b
C.kubectl logs pod-b
D.kubectl describe pod-b
AnswerA

This executes curl inside pod-a to test connectivity to pod-b.

Why this answer

kubectl exec allows you to run commands inside a container. From there, you can use curl to test connectivity to another pod's IP.

Practice this question →
195
MCQhard

You are troubleshooting a DNS issue. From within a pod, you run 'nslookup kubernetes.default.svc.cluster.local' and get 'connection timed out; no servers could be reached'. What is the most likely cause?

A.The pod's /etc/resolv.conf has incorrect nameservers
B.The node's network plugin is misconfigured
C.The pod's DNS policy is set to 'None'
D.The kube-dns service is not running or is misconfigured
AnswerD

If the DNS service pod is down, no DNS resolution works.

Why this answer

DNS timeout indicates the pod cannot reach the DNS service (kube-dns or CoreDNS).

Practice this question →
196
Multi-Selecteasy

Which TWO commands can be used to view logs for a pod?

Select 2 answers
A.kubectl exec my-pod -- cat /var/log/app.log
B.kubectl top pod my-pod
C.kubectl describe pod my-pod
D.kubectl logs my-pod
E.kubectl get pod my-pod -o yaml
AnswersC, D

Correct. Shows events and container status including last termination log.

Why this answer

kubectl logs and kubectl describe pod (which shows events and last state) are both useful for viewing log-related information.

Practice this question →
197
MCQmedium

A pod is in the 'Pending' state for a long time. You run 'kubectl describe pod pending-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 solution?

A.Remove the taint from the control-plane nodes
B.Delete the pod and recreate it
C.Increase the pod's resource requests
D.Add tolerations to the pod for the control-plane taint
AnswerD

The pod cannot be scheduled on control-plane nodes due to the taint. Adding a toleration allows the pod to be scheduled on those nodes.

Why this answer

Option A is correct. The pod lacks tolerations for the control-plane taint. Adding appropriate tolerations allows scheduling on those nodes.

Option B is irrelevant. Option C is not recommended. Option D does not address the root cause.

Practice this question →
198
MCQhard

A pod is in Pending state. You run 'kubectl describe pod pending-pod' and see an event: '0/3 nodes are available: 3 Insufficient memory'. However, you believe there is enough memory across the cluster. What could be the issue?

A.The pod's memory request is higher than any node's allocatable memory
B.The cluster is using a resource quota that is exhausted
C.The pod's memory limit is set too low
D.The nodes have taints that the pod does not tolerate
AnswerA

The scheduler cannot place the pod if no node can meet the request.

Why this answer

Even if total memory is sufficient, individual nodes may not have enough memory to satisfy the pod's request. The pod's memory request might be higher than any single node's available memory.

Practice this question →
199
MCQmedium

You suspect that the kube-scheduler is not running. Which command checks the scheduler's health?

A.systemctl status kube-scheduler
B.kubectl get pods -n kube-system | grep scheduler
C.kubectl get componentstatuses
D.kubectl describe node
AnswerC

Why this answer

Option C is correct because `kubectl get componentstatuses` (or `cs`) queries the Kubernetes API server for the health of core control plane components, including the scheduler. The API server periodically performs a health check against each component and reports its status as Healthy or Unhealthy. This command directly shows whether the scheduler is reachable and responding, making it the appropriate diagnostic tool when you suspect the scheduler is down.

Exam trap

The trap here is that candidates confuse checking the scheduler's pod status (Option B) with checking its health endpoint, or they assume systemd commands (Option A) work in containerized environments, leading them to overlook the dedicated `componentstatuses` command that directly queries the scheduler's health via the API server.

How to eliminate wrong answers

Option A is wrong because `systemctl status kube-scheduler` is a systemd command that only works if the scheduler is running as a systemd service on the same node; in a typical CKA cluster (often kubeadm-deployed), the scheduler runs as a static pod or container, not a systemd service, so this command would fail or show no relevant output. Option B is wrong because `kubectl get pods -n kube-system | grep scheduler` checks for the scheduler pod's existence and running state, but if the scheduler is not running, the pod might still be listed as 'Pending' or 'CrashLoopBackOff', or the command might return nothing; more importantly, the question asks for a health check, not a pod listing, and componentstatuses provides a direct health endpoint check. Option D is wrong because `kubectl describe node` shows node-level conditions (e.g., memory pressure, disk pressure) and resource usage, but it does not report the health of the scheduler or any control plane component; it is used for node troubleshooting, not scheduler health.

Practice this question →
200
Multi-Selectmedium

Which TWO of the following are correct methods to check the health of the kube-apiserver?

Select 2 answers
A.Run 'kubectl top nodes'
B.Run 'systemctl status kube-apiserver'
C.Run 'kubectl get pods -n kube-system -l component=kube-apiserver'
D.Run 'journalctl -u kubelet'
E.Run 'curl -k https://localhost:6443/healthz'
AnswersB, C

If the apiserver is run as a systemd service, systemctl shows its status.

Why this answer

The kube-apiserver exposes a health endpoint on the secure port (usually 6443). You can check its process status with systemctl or check the endpoint directly. kubectl get pods is for checking if the apiserver pod is running in a kubeadm cluster.

Practice this question →
201
Multi-Selectmedium

You want to check resource usage of pods and nodes. Which TWO commands should you use?

Select 2 answers
A.kubectl top pod
B.kubectl top pods
C.kubectl top nodes
D.kubectl resource usage
E.kubectl top node
AnswersB, C

Shows CPU/memory usage of pods.

Why this answer

kubectl top pods (B) and kubectl top nodes (E) are the correct commands. The other options are incorrect command syntax.

Practice this question →
202
MCQeasy

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?

A.kubectl top pod <pod>
B.kubectl describe pod <pod>
C.kubectl top node
D.kubectl logs <pod>
AnswerB

Shows both limits/requests and recent events like OOMKilled.

Why this answer

'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.

Practice this question →
203
MCQmedium

A pod named 'web-frontend' is in CrashLoopBackOff. You run 'kubectl logs web-frontend' and see: 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause and how should you fix it?

A.The NodePort is conflicting; change the service type to ClusterIP.
B.The container is missing an environment variable required for startup; add it via ConfigMap.
C.The container process is not terminating gracefully; add a preStop hook or use a proper init system to release the port.
D.The pod has insufficient memory; increase memory limits in the deployment.
AnswerC

The error shows port already in use, indicating the old process didn't release it.

Why this answer

The error 'address already in use' indicates the container process is trying to bind to port 8080, but that port is still held by a previous instance of the process that did not release it. This typically happens when the container process does not handle SIGTERM gracefully (e.g., it ignores the signal or takes too long to shut down), so Kubernetes kills it with SIGKILL, leaving the socket in a TIME_WAIT or lingering state. Adding a preStop hook or using a proper init system (like tini or a signal-aware wrapper) ensures the process releases the port before the container stops, preventing the crash loop.

Exam trap

The trap here is that candidates often confuse a port conflict error with a service misconfiguration (NodePort) or resource issue, when the real cause is a process lifecycle problem related to signal handling and socket cleanup.

How to eliminate wrong answers

Option A is wrong because a NodePort conflict would manifest as a service-level error (e.g., port allocation failure), not as a bind error inside the container's own process on 8080. Option B is wrong because a missing environment variable would cause a startup failure with a different error (e.g., 'unexpected EOF' or 'config not found'), not a TCP bind error. Option D is wrong because insufficient memory would produce an OOMKill event (visible in `kubectl describe pod` as 'OOMKilled'), not a bind error on a specific port.

Practice this question →
204
Multi-Selectmedium

Which TWO of the following are valid commands to view cluster events sorted by timestamp?

Select 2 answers
A.kubectl get events
B.kubectl get events --sort-by=.metadata.creationTimestamp
C.kubectl get events -w
D.kubectl get events --sort-by=.metadata.name
E.kubectl get events --all-namespaces
AnswersA, B

By default, events are sorted by last timestamp.

Why this answer

Options A and D are correct. 'kubectl get events' shows events sorted by last timestamp by default. 'kubectl get events --sort-by=.metadata.creationTimestamp' explicitly sorts by creation time. Option B is a valid command but not sorted. Option C sorts by name.

Option E is a valid command but not sorted.

Practice this question →
205
MCQmedium

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows the following event: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 3 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate.' Which action would resolve the issue?

A.Run 'kubectl describe node node-name' on each node to check conditions
B.Run 'kubectl taint nodes node-name node-role.kubernetes.io/master:NoSchedule-' to remove the taint
C.Run 'kubectl cordon node-name' on the node with the master taint
D.Add tolerations to the pod spec matching the taints on the nodes
AnswerD

Adding tolerations allows the pod to be scheduled on nodes with those taints.

Why this answer

Option D is correct. The pod is not tolerating the taints on any node. To schedule the pod, you must add the corresponding tolerations to the pod spec.

Option A would remove all pods from the node, not solve the taint issue. Option B tolerates only one taint. Option C describes the node, but does not change the pod's tolerations.

Practice this question →
206
MCQmedium

A node in your cluster is in the 'NotReady' state. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active but not functioning correctly. Which command should you use to get detailed logs to troubleshoot the kubelet?

A.kubectl describe node <node-name>
B.journalctl -u kubelet
C.kubectl logs kubelet -n kube-system
D.systemctl restart kubelet
AnswerB

journalctl -u kubelet shows the kubelet's systemd journal logs, which is the standard way to view kubelet logs.

Why this answer

Option B is correct. journalctl -u kubelet retrieves the kubelet's systemd journal logs, which is the standard method for troubleshooting kubelet issues. Option A is incorrect because kubectl logs is for pod containers. Option C provides node status but not detailed logs.

Option D restarts the service without showing logs.

Practice this question →
207
Multi-Selectmedium

Which TWO of the following are valid causes for a pod to be in CrashLoopBackOff?

Select 2 answers
A.The livenessProbe fails causing a restart
B.The container exits with a non-zero exit code
C.The node is out of memory
D.The image pull secret is missing
E.The container is using too much CPU
AnswersA, B

If the liveness probe fails repeatedly, the container is restarted and may enter CrashLoopBackOff.

Why this answer

CrashLoopBackOff occurs when a container exits repeatedly. Common causes include application errors and misconfigured probes.

Practice this question →
208
MCQmedium

A node in your cluster shows status 'NotReady'. You have SSH access to the node. What is the first command you should run to check the kubelet status?

A.systemctl status docker (or containerd)
B.cat /var/log/kubelet.log
C.systemctl status kubelet
D.journalctl -u kubelet
AnswerC

This directly checks the kubelet service status.

Why this answer

Correct answer is B. 'systemctl status kubelet' checks the kubelet service status. Option A checks the container runtime. Option C is for system logs, not service status.

Option D checks the kubelet log, but checking service status first is more direct.

Practice this question →
209
MCQeasy

You have a pod named 'web-pod' that is in a CrashLoopBackOff state. To examine the logs from the previous instance of the container, which command should you use?

A.kubectl logs web-pod --previous
B.kubectl exec web-pod -- cat /var/log/app.log
C.kubectl describe pod web-pod
D.kubectl logs web-pod
AnswerA

The --previous flag retrieves logs from the previous terminated container instance.

Why this answer

Option B is correct. kubectl logs --previous retrieves logs from the previous container instance, which is crucial for debugging CrashLoopBackOff. Option A shows current logs but the container may have restarted. Options C and D do not retrieve previous logs.

Practice this question →
210
MCQeasy

A user reports that a pod is stuck in 'ContainerCreating' state. Which command would you run first to diagnose the issue?

A.kubectl logs <pod-name>
B.kubectl describe pod <pod-name>
C.kubectl get events --watch
D.kubectl exec -it <pod-name> -- /bin/sh
AnswerB

Why this answer

The 'ContainerCreating' state indicates the pod has been scheduled but the container runtime is failing to start the container. `kubectl describe pod` provides detailed events, status conditions, and error messages from the kubelet, such as image pull failures, volume mount errors, or CNI plugin issues, which are the most direct source of diagnostic information for this state.

Exam trap

The trap here is that candidates often jump to `kubectl logs` thinking it shows startup errors, but logs are only available after the container's entrypoint has executed, not during container creation failures.

Why the other options are wrong

A

Logs require a running container; the pod is still ContainerCreating, so no logs exist.

C

This shows all cluster events, not specifically the pod's issue; it's less direct than describe pod.

D

Exec requires a running container; pod is not running.

Practice this question →
211
MCQeasy

You want to check the memory usage of nodes in your cluster. Which command should you use?

A.kubectl top nodes
B.kubectl describe nodes
C.kubectl get nodes -o wide
D.kubectl get --raw /api/v1/nodes
AnswerA

Why this answer

kubectl top nodes displays resource usage (CPU/memory) of nodes, provided Metrics Server is installed.

Practice this question →
212
Multi-Selecteasy

Which TWO of the following are valid commands to check the status of control plane components?

Select 2 answers
A.systemctl status kube-apiserver
B.kubectl get nodes
C.kubectl get pods -n kube-system
D.kubectl get events --all-namespaces
E.kubectl top nodes
AnswersA, C

On some clusters, control plane components run as systemd services, so this command checks their status.

Why this answer

Control plane components can be checked via kubectl (if running as pods) or systemctl (if running as services).

Practice this question →
213
Multi-Selectmedium

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

Select 2 answers
A.The pod's PersistentVolumeClaim is not bound
B.Insufficient CPU or memory resources on any node
C.The pod's image name is incorrect
D.The pod's liveness probe is failing
E.The container command fails immediately
AnswersA, B

Why this answer

Pending means the pod has not been scheduled. Resource constraints and unbound PVCs prevent scheduling. Image errors cause ImagePullBackOff, not Pending.

Command failure and liveness probe failures cause CrashLoopBackOff or Running but not Ready.

Practice this question →
214
MCQmedium

You deploy a pod with resource limits but no requests. The pod gets OOMKilled. What is the most likely reason?

A.The pod's liveness probe is failing
B.The container's entrypoint command is invalid
C.The container tried to use more memory than the limit
D.The node does not have enough memory for the limit
AnswerC

OOMKilled occurs when memory usage exceeds the limit.

Why this answer

When a pod has a memory limit set but no memory request, the Linux kernel enforces the limit via cgroups. If the container's processes attempt to allocate more memory than the limit, the kernel's Out-Of-Memory (OOM) killer terminates the container, resulting in an OOMKilled status. This is the most direct cause of the OOMKilled event.

Exam trap

The trap here is that candidates often confuse OOMKilled with resource scheduling issues (Option D) or probe failures (Option A), but OOMKilled specifically indicates the container was terminated by the kernel for exceeding its memory limit, not for node-level insufficiency or health check failures.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe would cause the pod to be restarted due to probe failure, not an OOMKill; the pod status would show 'CrashLoopBackOff' or 'Error', not OOMKilled. Option B is wrong because an invalid entrypoint command would prevent the container from starting at all, resulting in a 'CrashLoopBackOff' or 'Init:Error' status, not an OOMKilled termination after the container had been running. Option D is wrong because if the node lacks enough memory for the limit, the pod would remain in 'Pending' state with an 'Insufficient memory' scheduling failure, not be OOMKilled after running.

Practice this question →
215
MCQhard

A Deployment's pod is stuck in Pending state. 'kubectl describe pod' shows Events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient memory'. What is the likely fix?

A.Increase the memory limit of the pod or add more worker nodes
B.Remove the taint from the control-plane node
C.Add a toleration for the control-plane taint to the pod spec
D.Set nodeSelector to schedule on control-plane nodes
AnswerA

Why this answer

The error indicates insufficient memory on worker nodes, not the taint issue. Adding memory or nodes resolves the scheduling failure.

Practice this question →
216
MCQmedium

You run 'kubectl get pods' and see that a pod is in 'CrashLoopBackOff'. You want to examine the container's previous exit code. Which command provides this information?

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

'kubectl describe pod' shows container status including last state's exit code.

Why this answer

Option B is correct. 'kubectl describe pod' shows the container state, including the last state's exit code. Option A shows current logs. Option C shows previous logs but not the exit code.

Option D shows events but not exit codes.

Practice this question →
217
Multi-Selectmedium

Which TWO of the following are valid steps to troubleshoot a pod that is in 'CrashLoopBackOff'?

Select 2 answers
A.Run 'kubectl exec -it pod-name -- /bin/bash' to inspect the container
B.Run 'kubectl logs pod-name --previous' to view logs from the previous crash
C.Run 'kubectl describe pod pod-name' to see events and state
D.Run 'kubectl rollout restart deployment/pod-name'
E.Run 'kubectl delete pod pod-name' to force restart
AnswersB, C

This retrieves logs from the crashed instance.

Why this answer

Correct answers are A and C. Checking logs and describing the pod are standard troubleshooting steps. B is not directly helpful.

D is not a troubleshooting step. E is not a command.

Practice this question →
218
MCQmedium

The controller-manager logs show repeated errors: 'Failed to list *v1.Pod: connection refused'. What is the most likely cause?

A.The API server is down or not reachable
B.The kube-controller-manager is not running
C.The kubelet on the controller node is down
D.The scheduler is overloading the API server
AnswerA

The controller-manager cannot connect to the API server.

Why this answer

The controller-manager communicates with the API server. 'connection refused' indicates the API server is not reachable or not running.

Practice this question →
219
Multi-Selectmedium

A pod is stuck in Pending state. Which TWO of the following could be causes? (Select 2)

Select 2 answers
A.The pod's container image is invalid
B.The kube-apiserver is down
C.The pod has a taint that no node tolerates
D.The pod requires a PersistentVolumeClaim that is not bound
E.The cluster has no nodes with enough CPU or memory to schedule the pod
AnswersD, E

If a PVC is not bound, the pod cannot start.

Why this answer

Pending pods often lack resources or have unscheduled taints. PVC binding is also a common cause.

Practice this question →
220
MCQeasy

You run 'kubectl get events --sort-by='.lastTimestamp'' and see repeated events: 'Failed to pull image "myimage:v2": rpc error: code = Unknown desc = Error response from daemon: manifest for myimage:v2 not found'. What is the issue?

A.The pod has insufficient privileges to pull the image.
B.The image registry is down.
C.The container runtime is not running.
D.The image tag 'myimage:v2' does not exist in the registry.
AnswerD

The error clearly states the manifest is not found for that tag.

Why this answer

The error 'manifest not found' means the image tag does not exist in the registry. The pod is in ImagePullBackOff because the image is missing.

Practice this question →
221
MCQeasy

Which command shows resource usage for pods and nodes in the cluster?

A.kubectl top pods and kubectl top nodes
B.kubectl cluster-info
C.kubectl get --sort-by=.status.capacity
D.kubectl describe pods and kubectl describe nodes
AnswerA

These are the correct commands for resource usage.

Why this answer

The metrics server must be installed. 'kubectl top pods' shows pod CPU/memory usage, and 'kubectl top nodes' shows node usage.

Practice this question →
222
Drag & Dropmedium

Drag and drop the steps to back up and restore etcd data for a Kubernetes cluster into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

First snapshot, verify, stop etcd, restore, then start and check health.

Practice this question →
223
MCQmedium

You have a Deployment with 3 replicas. After updating the container image, the new pods are in 'ImagePullBackOff' state. You run 'kubectl describe pod <pod-name>' and see the event: 'Failed to pull image "myregistry/myapp:latest": rpc error: code = Unknown desc = Error response from daemon: manifest for myregistry/myapp:latest not found: manifest unknown: manifest unknown'. What is the MOST likely cause?

A.The registry is unreachable from the nodes
B.The image tag 'latest' does not exist in the registry
C.The registry requires authentication and the pod does not have an imagePullSecret
D.The container runtime is out of disk space
AnswerB

The error message 'manifest for myregistry/myapp:latest not found' indicates that the tag does not exist. The image may not have been pushed with that tag.

Why this answer

Option A is correct. The error message explicitly states the manifest for the tag ':latest' is not found. This typically happens when the tag does not exist in the registry.

Option B would result in a different error (authentication failure). Option C would show a different error (connection timeout or refused). Option D would result in a different error (network timeout).

Practice this question →
224
MCQeasy

Which command can be used to view resource usage of nodes in a cluster?

A.kubectl describe nodes
B.kubectl top pods
C.kubectl get pods --show-resources
D.kubectl top nodes
AnswerD

This command displays resource usage (CPU and memory) for all nodes in the cluster.

Why this answer

Option A is correct. 'kubectl top nodes' shows CPU and memory usage of nodes, provided the metrics server is installed. Option B shows pod resource usage. Option C is a non-existent command.

Option D shows only pods, not nodes.

Practice this question →
225
MCQmedium

You run 'kubectl get pods -n default' and see a pod named 'backend' in ImagePullBackOff state. What is the most likely cause?

A.The image name or tag is incorrect
B.The node is out of disk space
C.The container's memory limit is too low
D.The pod's service account lacks permissions
AnswerA

A typo in the image name or an invalid tag causes pull failure.

Why this answer

ImagePullBackOff indicates Kubernetes cannot pull the container image, often due to a tag typo or non-existent image.

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

Ready to test yourself?

Try a timed practice session using only Cka Troubleshooting questions.

Start 20-question session