CKA Practice Test 48 — 15 Questions

Question 1

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

Accepted Answer

kubectl logs --previous. Option B, `kubectl logs --previous`, is correct because CrashLoopBackOff means the container has already restarted, so the `--previous` flag retrieves the logs from the last terminated container instance, which typically contains the actual crash/error output that caused the failure. Option C, `kubectl describe pod `, is correct because it shows the Pod's status conditions, container states (Waiting/Terminated with reason and exit code), restart count, and recent events such as image pull errors, OOMKilled, or failed probes, which are essential for pinpointing why the container keeps crashing. Option A, `kubectl get events --all-namespaces`, is not the best choice because it returns a broad cluster-wide event stream that is noisy and not scoped to the specific Pod, making it less efficient than describing the Pod itself. Option D, `kubectl logs `, is not the most helpful here because without `--previous` it targets the current container instance, which may not have produced logs yet or may not exist if the container is stuck restarting. Option E, `kubectl top pod `, is incorrect because it only reports CPU and memory usage metrics and provides no diagnostic information about the crash cause.

Answer

kubectl get events --all-namespaces

Answer

kubectl logs <pod-name>

Answer

kubectl top pod <pod-name>

Question 2

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

Accepted Answer

kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port. Option B is correct because running an ephemeral busybox pod with `kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port` lets you test DNS resolution and HTTP connectivity from a separate pod to a target service, which is a standard way to isolate whether a connectivity problem is pod-specific or service-wide. Option E is correct because `kubectl exec -- ping ` executes a network utility inside an existing pod, directly verifying ICMP reachability and basic IP-level connectivity between that pod and the target. Option A is not useful here because `kubectl top pod` only reports CPU and memory usage metrics, not network reachability. Option C is not useful because `kubectl edit deployment` modifies the deployment manifest and does not test connectivity. Option D is not useful because `kubectl logs` only retrieves container stdout/stderr output and does not actively probe network paths.

Answer

kubectl top pod <pod-name>

Answer

kubectl edit deployment <deployment-name>

Answer

kubectl logs <pod-name>

Question 3

Which TWO of the following are valid commands to check resource usage of pods?

Accepted Answer

kubectl top pod . Option C, `kubectl top pod `, is correct because the `kubectl top` command retrieves live CPU and memory usage metrics for a specific pod from the Metrics Server, which is exactly what checking resource usage of a pod requires. Option E, `kubectl top pods`, is also correct because it lists current CPU and memory consumption for all pods in the namespace, directly satisfying the resource-usage check. Option A, `kubectl top nodes`, is not correct here because it reports resource usage of cluster nodes, not pods. Option B, `kubectl describe pods`, shows configuration, events, and status details but not live CPU/memory usage metrics. Option D, `kubectl get pods --watch`, only streams pod status changes and does not report resource consumption.

Answer

kubectl top nodes

Answer

kubectl describe pods

Answer

kubectl get pods --watch

Question 4

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

Accepted Answer

Run 'kubectl logs pod-name --previous' to view logs from the previous crash. Option B is correct because when a pod is in CrashLoopBackOff the current container is usually not running, so 'kubectl logs pod-name --previous' retrieves the logs from the last terminated container instance, which is essential for diagnosing why it crashed. Option C is correct because 'kubectl describe pod pod-name' shows the pod's status, container states, restart counts, and the event stream (e.g., Back-off restarting failed container, image pull errors, OOMKilled), giving the key context for the crash loop. Option A is not a valid troubleshooting step here because 'kubectl exec' requires a running container, and a pod in CrashLoopBackOff has no live container to attach to. Option D is not a diagnostic step; 'kubectl rollout restart' merely triggers a new rollout and does not reveal the cause of the crash. Option E is also not troubleshooting; deleting the pod just causes the controller to recreate it, and the new pod will likely crash again for the same underlying reason.

Answer

Run 'kubectl exec -it pod-name -- /bin/bash' to inspect the container

Answer

Run 'kubectl rollout restart deployment/pod-name'

Answer

Run 'kubectl delete pod pod-name' to force restart

Question 5

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

Accepted Answer

Insufficient cluster resources (CPU/memory) to schedule the pod. Option B is correct because the Kubernetes scheduler places a pod into the Pending state when no node has enough allocatable CPU or memory to satisfy the pod's resource requests, so the pod remains unscheduled until resources free up or the cluster scales. Option D is correct because if a pod references a PersistentVolumeClaim that is not yet Bound (for example, waiting on a dynamic provisioner or a matching PersistentVolume), the scheduler cannot satisfy the volume's node affinity/topology constraints and the pod stays Pending. Option A is not a cause of Pending; an image that cannot be pulled produces an ImagePullBackOff/ErrImagePull status while the pod is already scheduled and typically Running or Waiting on a node. Option C is not a cause of Pending; a failing liveness probe causes kubelet to restart the container, resulting in CrashLoopBackOff or repeated restarts, not a scheduling failure. Option E is not a cause of Pending; an unreachable node affects existing pods (marking them Unknown/NotReady) rather than preventing scheduling, since the scheduler simply avoids nodes it considers unhealthy.

Answer

The container image is not found

Answer

The pod's liveness probe is failing

Answer

The node is unreachable due to network issues

Question 6

You are using kubeadm to initialize a cluster. After running 'kubeadm init', you follow the instructions to set up the kubeconfig for the regular user. Which of the following commands should you run to allow kubectl to communicate with the cluster?

Accepted Answer

sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config. After running 'kubeadm init', the admin.conf file is generated in /etc/kubernetes/ and contains the cluster CA certificate, client certificate, and API server endpoint. This is the only kubeconfig file that grants full administrative access to the cluster, making it the correct file to copy to the user's $HOME/.kube/config for kubectl to communicate with the cluster.

Answer

sudo cp /etc/kubernetes/controller-manager.conf $HOME/.kube/config

Answer

sudo cp /etc/kubernetes/scheduler.conf $HOME/.kube/config

Answer

sudo cp /etc/kubernetes/kubelet.conf $HOME/.kube/config

Question 7

Which of the following volume types provides ephemeral storage that shares the pod's lifecycle and is initially empty?

Accepted Answer

emptyDir. B is correct because an `emptyDir` volume is created empty when a Pod is assigned to a node and exists as long as that Pod is running. It provides ephemeral storage that shares the Pod's lifecycle, meaning it is deleted when the Pod is removed, and it is initially empty, making it ideal for scratch space, caching, or temporary data.

Answer

secret

Answer

configMap

Answer

hostPath

Question 8

Which of the following is NOT a control plane component in Kubernetes?

Accepted Answer

kube-proxy. kube-proxy is not a control plane component; it is a node-level (worker) component responsible for implementing network rules and handling service-to-pod traffic via iptables or IPVS. The control plane consists of kube-apiserver, etcd, kube-scheduler, and kube-controller-manager.

Answer

kube-scheduler

Answer

etcd

Answer

kube-apiserver

Question 9

To back up etcd, which command should be used with etcdctl?

Accepted Answer

etcdctl snapshot save. The correct command to back up etcd is `etcdctl snapshot save`, which creates a point-in-time snapshot of the etcd key-value store. This is the officially recommended method for backing up etcd data in Kubernetes clusters, as it captures the entire database state consistently.

Answer

etcdctl export

Answer

etcdctl backup

Answer

etcdctl dump

Question 10

You want to upgrade the control plane from v1.28.0 to v1.29.0 using kubeadm. After upgrading kubeadm on the control plane node, which command should you run first?

Accepted Answer

kubeadm upgrade plan. After upgrading kubeadm on the control plane node, the first command to run is `kubeadm upgrade plan`. This command checks the current cluster version, validates that the upgrade path is supported (e.g., from v1.28.0 to v1.29.0), and displays the available versions to upgrade to, along with any manual steps required. It is a prerequisite to ensure the upgrade is safe before proceeding with `kubeadm upgrade apply`.

Answer

kubeadm upgrade apply v1.29.0

Answer

kubeadm upgrade node

Answer

kubeadm upgrade diff

Question 11

You need to back up the etcd database for a kubeadm-created cluster. Which directory contains the etcd data?

Accepted Answer

/var/lib/etcd. For a kubeadm-created cluster, etcd runs as a static Pod, and its data directory is mounted from the host path `/var/lib/etcd`. This is the default data directory used by etcd when started via kubeadm, and it stores all cluster state and configuration data. The CKA exam expects you to know this path for backup and restore operations.

Answer

/etc/kubernetes/pki/etcd

Answer

/var/lib/kubelet

Answer

/etc/etcd

Question 12

An admin runs 'kubectl get pods' and sees a pod in 'Pending' state for a long time. 'kubectl describe pod' shows '0/1 nodes are available: 1 node has memory pressure'. Which is the most likely cause?

Accepted Answer

The node is under memory pressure and cannot admit the pod.. The '0/1 nodes are available: 1 node has memory pressure' message in `kubectl describe pod` indicates that the kubelet on the node has set a memory pressure condition, which triggers eviction thresholds. When a node is under memory pressure, the kubelet refuses to admit new pods (except those with QoS class Guaranteed) to prevent further resource exhaustion, leaving the pod stuck in Pending state. This matches option C exactly.

Answer

The node's disk is full.

Answer

The pod's image pull secret is missing.

Answer

The pod requires more CPU than any node can provide.

Question 13

You are upgrading a Kubernetes cluster from version 1.28 to 1.29. What is the correct order of steps?

Accepted Answer

Upgrade control plane nodes first, then drain each worker node before upgrading it.. The Kubernetes upgrade process requires upgrading the control plane nodes first to ensure the cluster's management layer is running the new version before worker nodes are upgraded. Draining each worker node before upgrading it is essential to safely evict pods and maintain application availability, as the kubelet on the node must be stopped during the upgrade and the node must be cordoned to prevent new pods from being scheduled.

Answer

Upgrade all worker nodes first, then upgrade control plane nodes.

Answer

Upgrade control plane nodes first, then upgrade worker nodes without draining them.

Answer

Upgrade all nodes simultaneously.

Question 14

You are preparing to upgrade a Kubernetes cluster from v1.27 to v1.28 using kubeadm. What is the correct order of operations for upgrading the control plane nodes?

Accepted Answer

Upgrade the first control plane node, then upgrade the remaining control plane nodes, then upgrade worker nodes.. The recommended upgrade order for a kubeadm-managed cluster is to upgrade the first control plane node (using `kubeadm upgrade apply`), then the remaining control plane nodes (using `kubeadm upgrade node`), and finally the worker nodes. This ensures the cluster's control plane components (etcd, kube-apiserver, kube-controller-manager, kube-scheduler) are updated first, maintaining cluster stability and API server availability during the process.

Answer

Upgrade all worker nodes first, then upgrade the control plane nodes.

Answer

Upgrade all nodes simultaneously by running kubeadm upgrade apply on all nodes at once.

Answer

Upgrade worker nodes, then upgrade the control plane nodes, then drain the worker nodes.

Question 15

Which control plane component stores the entire cluster state?

Accepted Answer

etcd. Etcd because it is the distributed key-value store that serves as the single source of truth for the entire cluster state, including all objects, configurations, and secrets. The kube-apiserver is the only component that directly interacts with etcd, but it does not store the state itself—it reads from and writes to etcd on behalf of other components.

Answer

kube-controller-manager

Answer

kube-scheduler

Answer

kube-apiserver