CKA Troubleshooting Practice Test 8 — 15 Questions

Question 1

You have a Deployment with 3 replicas. Two pods are Running, one is CrashLoopBackOff. You run 'kubectl logs pod-crash -c app' and see: 'Error: failed to connect to database at 10.0.0.5:5432'. The database is a separate Pod with a ClusterIP service. How should you verify network connectivity from the crashing pod to the database service?

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

Accepted Answer

kubectl exec -it running-pod -- sh -c 'curl http://db-service:5432'. Since the crashing pod is in CrashLoopBackOff, you cannot reliably run `kubectl exec` inside it. To verify if the database service is reachable from the application's network environment, you should run the connectivity test from one of the healthy, running peer pods in the same Deployment. This isolates whether the issue is a general network/routing problem or specific to the crashing pod's internal configuration.

Answer

kubectl port-forward svc/db-service 5432:5432

Answer

kubectl exec -it pod-crash -- sh -c 'curl http://db-service:5432'

Answer

kubectl logs db-pod

Question 2

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

Accepted Answer

kubectl top pod --namespace=production. `kubectl top pod --namespace=production` directly queries the metrics-server to retrieve real-time CPU and memory usage for each pod in the specified namespace. This command leverages the Kubernetes Metrics API to display resource consumption, making it the precise tool for checking memory usage of pods.

Answer

kubectl get pod --namespace=production -o wide

Answer

kubectl describe pod --namespace=production

Answer

kubectl top node

Question 3

A node is NotReady. You ssh into the node and run 'systemctl status kubelet'. It shows 'Active: inactive (dead)'. What is the most appropriate next step?

Accepted Answer

systemctl start kubelet. Starting the kubelet service with systemctl start kubelet is the correct action. Investigating logs may be needed if it fails to start.

Answer

journalctl -u kubelet

Answer

kubectl delete node <node-name>

Answer

systemctl restart docker

Question 4

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?

Accepted Answer

The pod's /etc/resolv.conf points to an incorrect DNS server IP. The NXDOMAIN error from nslookup indicates the DNS server itself is reachable but does not have a record for the queried name. The most likely cause is that the pod's /etc/resolv.conf points to an incorrect DNS server IP, so the query goes to a server that is not the cluster's DNS (kube-dns/CoreDNS) and thus cannot resolve internal service names. This is a common misconfiguration when the pod's DNS settings are not properly inherited from the cluster's DNS policy.

Answer

The kubernetes service does not exist

Answer

The pod does not have network connectivity

Answer

The kube-dns service is not exposed

Question 5

You want to see events sorted by timestamp in the 'kube-system' namespace. Which command should you use?

Accepted Answer

kubectl get events -n kube-system --sort-by='.metadata.creationTimestamp'. kubectl get events --sort-by='.metadata.creationTimestamp' -n kube-system shows events sorted by creation time.

Answer

kubectl describe events -n kube-system

Answer

kubectl get events -n kube-system --sort-by='.lastTimestamp'

Answer

kubectl logs -n kube-system events

Question 6

You run 'kubectl top nodes' and get an error: 'error: metrics not available yet'. What is the most likely cause?

Accepted Answer

The metrics-server is not installed or not running. The metrics server is not deployed or not ready; kubectl top requires the metrics server to collect resource usage data.

Answer

The nodes do not have enough resources to run the metrics collection

Answer

You do not have permission to view node metrics

Answer

The kubelet is not running on the nodes

Question 7

Which three are possible reasons for a pod being in Pending state? (Choose three.)

Accepted Answer

PersistentVolumeClaim not bound. Pending means the pod hasn't been scheduled. Reasons include insufficient resources, persistent volume claim not bound, and taints/tolerations mismatch. Image pull issues cause ImagePullBackOff, not Pending.

Answer

Liveness probe failing

Answer

Container image does not exist

Question 8

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in CrashLoopBackOff with an OOMKilled message, which means the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to use more memory without being killed. Simply increasing CPU requests (Option A) does not address memory exhaustion, and deleting/recreating the pod or namespace (Options C and D) will not fix the underlying resource constraint.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 9

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

Accepted Answer

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

Answer

The node is unreachable

Answer

The pod has a memory request that cannot be fulfilled

Answer

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

Question 10

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?

Accepted Answer

The image tag 'latest' does not exist in the registry. The error message 'manifest unknown' indicates that the registry successfully reached but the specific image tag 'latest' does not exist in the repository. This is a registry-side error, not a network or authentication issue. The container runtime can communicate with the registry but cannot find the manifest for the requested tag.

Answer

The registry is unreachable from the nodes

Answer

The registry requires authentication and the pod does not have an imagePullSecret

Answer

The container runtime is out of disk space

Question 11

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

Accepted Answer

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

Answer

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

Answer

The storage class does not exist

Answer

The cluster does not have a default storage class

Question 12

You deploy a pod with the following YAML:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

The pod starts, but after a few minutes it is killed with OOMKilled. What is the MOST likely reason?

Accepted Answer

The container's memory usage exceeds the configured limit. OOMKilled occurs when a container exceeds its memory limit. In this YAML, the memory limit is set to 128Mi. If the nginx container's memory usage surpasses 128Mi, the Linux kernel's Out-Of-Memory (OOM) killer terminates the container process, resulting in an OOMKilled status. This is a direct enforcement of the resource limit configured in the pod spec.

Answer

The memory limit is lower than the memory request

Answer

The node has swap enabled

Answer

The container is using too much CPU

Question 13

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

Accepted Answer

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

Answer

The pod is requesting more CPU than any node can provide

Answer

The pod's persistent volume claim is not bound

Answer

The container image does not exist in the registry

Question 14

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

Accepted Answer

kubectl logs pod-name. The `kubectl logs pod-name` command (option B) directly retrieves the current logs from the specified pod's default container. This is the standard and most straightforward way to view container logs in Kubernetes, as it streams the stdout/stderr output from the container runtime (e.g., containerd or CRI-O) via the kubelet API.

Answer

kubectl describe pod pod-name

Answer

kubectl exec pod-name -- logs

Answer

kubectl get pod pod-name -o yaml

Question 15

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?

Accepted Answer

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

Answer

Increase the CPU request for the container

Answer

Delete the namespace and redeploy

Answer

Delete and recreate the pod