CKA Practice Exam 3 — 20 Questions

Question 1

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

Accepted Answer

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

Answer

Restart all containers on the node

Answer

Check the kube-apiserver logs on the control plane

Answer

Check kube-proxy configuration

Question 2

A pod with a resource request of 500m CPU and a limit of 1 CPU is scheduled. The node has a CPU capacity of 2 cores. What does the '500m' represent?

Accepted Answer

500 millicores (0.5 CPU core). In Kubernetes, CPU resources are measured in millicores, where 1000m equals 1 full CPU core (vCPU or hyperthread). The '500m' in a resource request means the pod is guaranteed at least 500 millicores, or 0.5 CPU core, from the node's 2-core capacity. This is a standard unit used by the kubelet for CPU scheduling and the Completely Fair Scheduler (CFS) quota enforcement.

Answer

500 megabytes of memory

Answer

50% of the node's CPU capacity

Answer

A limit of 500,000 CPU seconds per day

Question 3

A cluster has a PersistentVolumeClaim (PVC) named 'data-claim' bound to a PersistentVolume (PV) with reclaim policy 'Retain'. The PVC is deleted. The PV now shows status 'Released'. What must be done so that the PV can be reused by a new PVC?

Accepted Answer

Delete and recreate the PersistentVolume.. When a PVC is deleted and the PV has a reclaim policy of 'Retain', the PV enters a 'Released' state, meaning it still contains the data but is no longer bound to the original PVC. The PV cannot be directly reused by a new PVC because its claim reference is still set to the deleted PVC's UID. To make the PV available again, you must manually delete and recreate the PV (or at least delete it and re-create it with a clean claimRef), which resets its status to 'Available'.

Answer

Nothing; the PV will automatically become Available after some time.

Answer

Create a new PVC with the same name.

Answer

Change the reclaim policy to Delete.

Question 4

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

Accepted Answer

The kubelet cannot contact the API server. The kubelet is the primary node agent that communicates with the API server to report node status, heartbeats, and pod lifecycle events. If the kubelet cannot reach the API server (e.g., due to network partition, TLS certificate issues, or API server downtime), it cannot send the periodic NodeStatus updates, and the control plane marks the node as 'NotReady' after the `node-monitor-grace-period` (default 40 seconds) expires.

Answer

The node has disk pressure

Answer

A pod on the node is consuming excessive memory

Question 5

A NetworkPolicy with podSelector: {} and policyTypes: [Ingress] is applied to a namespace. What is the effect on pods in that namespace?

Accepted Answer

All ingress traffic is denied unless explicitly allowed by another policy.. A NetworkPolicy with `podSelector: {}` selects all pods in the namespace. When `policyTypes: [Ingress]` is set without any ingress rules, it defaults to denying all ingress traffic that is not explicitly allowed by another policy. This is because Kubernetes NetworkPolicy implements an implicit deny for the specified traffic direction when no rules are provided, effectively isolating the pods from inbound connections.

Answer

The policy has no effect because no rules are defined.

Answer

All ingress traffic is allowed.

Answer

All egress traffic is denied.

Question 6

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

Accepted Answer

kubectl describe pod pod-name. `kubectl describe pod pod-name` provides detailed information about the pod's current state, including recent events, container restart counts, and the reason for the CrashLoopBackOff (e.g., exit code 137 from OOMKill or 1 from application error). This is the first step to understand the root cause of the crash loop.

Answer

kubectl delete pod pod-name

Answer

kubectl exec -it pod-name -- sh

Answer

kubectl rollout restart deployment

Question 7

A node is in 'NotReady' state. Which TWO of the following are common causes? (Select 2)

Accepted Answer

The kubelet service has stopped on the node. Options C and E are correct. A node becomes 'NotReady' when the kubelet stops reporting its status (C) or when the network plugin (e.g., Calico, Flannel) fails, preventing pod networking (E). Option A (ImagePullBackOff) is a pod-level issue and does not affect node status. Option B (insufficient memory) leads to pod eviction but the node remains Ready if kubelet is healthy. Option D (API server down) affects the entire cluster, but nodes may still show Ready if kubelet is functioning.

Answer

A pod on the node is in ImagePullBackOff

Answer

The node has insufficient memory

Answer

The Kubernetes API server is down

Question 8

You want to check the status of the kube-apiserver on a control plane node. Which commands should you use? (Select the best option)

Accepted Answer

systemctl status kube-apiserver or crictl ps | grep kube-apiserver. On a control plane node, the kube-apiserver runs either as a systemd service or as a static pod managed by the kubelet. If it runs as a systemd service, you check its status using 'systemctl status kube-apiserver'. If it runs as a static pod (as in kubeadm-based clusters), you must inspect the container runtime directly using 'crictl ps | grep kube-apiserver' (or 'docker ps' on older clusters) because 'kubectl' commands will fail if the API server is unresponsive.

Answer

journalctl -u kubelet

Answer

ps aux | grep kube-apiserver

Answer

docker ps | grep kube-apiserver

Question 9

Which access mode allows multiple pods to read and write to a PersistentVolume simultaneously when all pods are on the same node?

Accepted Answer

ReadWriteOnce. ReadWriteOnce (RWO) allows a PersistentVolume to be mounted as read-write by a single node, but multiple pods on that same node can all access the volume simultaneously. This is because the access mode restriction is per node, not per pod, so all pods scheduled on the same node share the same mount and can read and write concurrently.

Answer

ReadOnlyMany

Answer

ReadWriteMany

Answer

ReadWriteOncePod

Question 10

You are asked to backup the etcd database on a control plane node. The etcd is running as a static pod. Which command sequence will create a consistent snapshot?

Accepted Answer

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /backup/etcd-snapshot.db. It uses the etcdctl v3 API with the required authentication flags (--cacert, --cert, --key) and the correct endpoint (https://127.0.0.1:2379) to connect to the etcd server running as a static pod. This ensures a consistent snapshot is taken over the secure gRPC connection, which is mandatory when etcd is configured with TLS.

Answer

kubectl exec -n kube-system etcd-controlplane -- etcdctl snapshot save /backup/etcd-snapshot.db

Answer

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db

Answer

etcdctl --endpoints=http://localhost:2379 snapshot save /backup/etcd-snapshot.db

Question 11

You are a cluster administrator managing a production Kubernetes cluster that hosts a stateful application using StatefulSets with PersistentVolumeClaims (PVCs) backed by a cloud provider's persistent disk. A developer reports that a new pod in the StatefulSet is stuck in 'Pending' state. You describe the StatefulSet and see that it has 3 replicas. Two pods are Running, but the third pod (pod-2) is Pending. You check the PVC for pod-2 and see it is 'Pending'. The StorageClass uses 'WaitForFirstConsumer' volume binding mode. The node where pod-2 should run has sufficient resources. Other PVCs in the same namespace bound successfully. What is the most likely cause of the pending PVC and pod?

Accepted Answer

The PV that should bind to the PVC has a nodeAffinity that does not match any available node.. With 'WaitForFirstConsumer' volume binding mode, the PVC binding is deferred until a pod using it is scheduled. The PV that should bind to the PVC has a nodeAffinity that does not match any available node, preventing the scheduler from binding the PVC and scheduling the pod. This results in both the PVC and pod remaining in 'Pending' state, even though the node has sufficient resources.

Answer

The CSI driver is not installed on the node where pod-2 is scheduled.

Answer

The PVC's requested storage size exceeds the available capacity in the cloud provider's quota.

Answer

The PVC's access mode is ReadWriteOnce, but the pod requires ReadWriteMany.

Question 12

You are managing a Kubernetes cluster that hosts a microservices application. One of the services, 'payment-processor', is critical and must always be available. It has a Deployment with 3 replicas, each requesting 1 CPU and 2Gi memory. Recently, the team added a new service 'data-analyzer' that runs as a DaemonSet on all nodes, consuming significant CPU and memory. After the addition, you notice that 'payment-processor' pods are occasionally being evicted, and new pods are slow to be scheduled. You check node resource usage and find that some nodes are overcommitted. You want to ensure that 'payment-processor' pods are never evicted and are scheduled before less critical workloads. Which action should you take?

Accepted Answer

Create a PriorityClass with a high value and assign it to the 'payment-processor' Deployment. PriorityClass with a high value ensures that 'payment-processor' pods are considered higher priority than other pods during scheduling and eviction. When nodes are overcommitted, the Kubernetes scheduler will preempt lower-priority pods to make room for higher-priority pods, and the kubelet will evict lower-priority pods first when resources are scarce. This directly addresses the requirement that 'payment-processor' pods are never evicted and are scheduled before less critical workloads.

Answer

Add a taint to nodes that have low resources and add tolerations only to 'payment-processor' pods

Answer

Increase the resource requests for 'payment-processor' pods to guarantee resources

Answer

Use node affinity to ensure 'payment-processor' pods run on dedicated nodes

Question 13

A pod is in 'Pending' state. 'kubectl describe pod' shows: '0/3 nodes are available: 1 Insufficient memory, 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' Which THREE actions would resolve the issue? (Choose three)

Accepted Answer

Remove the taint from the control-plane nodes.. The pod cannot be scheduled because one node lacks memory and two nodes have a control-plane taint. Any single action that resolves either the memory issue (decreasing memory request) or the taint issue (removing taint or adding toleration) will make a node available. Since the question asks for three actions, A, B, and D are the correct choices as each independently resolves the scheduling block. Options C and E do not address the reported problems.

Answer

Increase the CPU request of the pod.

Answer

Add a node selector to the pod that matches the control-plane nodes.

Question 14

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

Accepted Answer

kubectl get events. Options A and B are correct. 'kubectl get events' shows events sorted by last timestamp by default, which satisfies the requirement. 'kubectl get events --sort-by=.metadata.creationTimestamp' explicitly sorts by creation timestamp, also valid. Option C uses -w to watch, not sort. Option D sorts by name, not timestamp. Option E shows events from all namespaces but does not sort by timestamp.

Answer

kubectl get events -w

Answer

kubectl get events --sort-by=.metadata.name

Answer

kubectl get events --all-namespaces

Question 15

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. Which command would help you determine the exact reason for the image pull failure?

Accepted Answer

kubectl describe pod . A is correct because 'kubectl describe pod ' provides detailed information about the pod, including the container status, events, and the exact error message from the image pull attempt. This output includes the reason for the ImagePullBackOff, such as a missing image, incorrect tag, authentication failure, or network issue, which is essential for troubleshooting.

Answer

kubectl top pod <pod-name>

Answer

kubectl logs <pod-name>

Answer

kubectl get events

Question 16

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

Accepted Answer

Run 'kubectl describe pod pod-name' to check container state and events. Run 'kubectl describe pod pod-name' (option C) to check container state and events, and 'kubectl logs --previous pod-name' (option D) to retrieve logs from the previous container instance if the pod restarted. These are the two most direct steps to troubleshoot missing logs.

Answer

Run 'kubectl get events --all-namespaces'

Answer

Run 'kubectl top pod pod-name' to check resource usage

Answer

Run 'kubectl exec pod-name -- cat /var/log/container.log'

Question 17

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

Accepted Answer

The container requires more memory than the limit allows. Insufficient memory would cause OOMKilled, not ImagePullBackOff. ImagePullBackOff is caused by issues pulling the container image: wrong image name (C), nonexistent tag (B), authentication failure (A), or registry unreachable. Options A, B, and C are all common causes of ImagePullBackOff.

Answer

The image registry requires authentication and no imagePullSecrets are configured

Answer

The image tag does not exist

Answer

The image name is misspelled

Question 18

You have a multi-node cluster. One node shows 'NotReady'. You run 'journalctl -u kubelet' on that node and see 'network plugin is not ready'. What is the most likely cause?

Accepted Answer

The CNI plugin pod (e.g., Calico) is not running on that node. The 'network plugin is not ready' error from kubelet indicates that the kubelet is waiting for a CNI (Container Network Interface) plugin to configure the pod network. If the CNI plugin pod (e.g., Calico, Flannel, Weave) is not running on that specific node, the kubelet cannot set up the network for pods, causing the node to remain in 'NotReady' state. This is the most direct cause because the kubelet relies on the CNI plugin to report readiness before marking the node as Ready.

Answer

The container runtime (e.g., containerd) is down

Answer

The kubelet service is not running

Answer

The node's IP address has changed

Question 19

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 a CrashLoopBackOff state with an 'OOMKilled' message, which indicates that the container's memory usage exceeded its configured memory limit, causing the kernel's Out-Of-Memory (OOM) killer to terminate the process. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause of the crash loop.

Answer

Delete the namespace and redeploy all workloads

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container

Question 20

You are troubleshooting a node that shows 'NotReady' status. Which TWO commands can help you investigate the kubelet state?

Accepted Answer

journalctl -u kubelet. journalctl -u kubelet (C) retrieves kubelet logs from the systemd journal, showing errors and warnings. systemctl status kubelet (D) displays the current status of the kubelet service, including whether it is running, enabled, and recent log entries. The other options: 'kubectl get nodes' (A) shows node status but not kubelet details; 'journalctl -u docker' (B) shows container runtime logs, not kubelet; 'kubectl describe pod' (E) is for pod details, not node-level kubelet troubleshooting.

Answer

kubectl get nodes

Answer

journalctl -u docker

Answer

kubectl describe pod