CKA Practice Test 5 — 10 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