CKA Practice Test 3 — 30 Questions

Question 1

You have a PriorityClass 'high-priority' with value 1000 and 'low-priority' with value 100. A pod A with 'high-priority' is pending because the node has no resources. A pod B with 'low-priority' is running on that node. What will happen if preemption is enabled?

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

Accepted Answer

Pod B will be preempted (evicted) to allow pod A to be scheduled on the node. When preemption is enabled, the Kubernetes scheduler can evict lower-priority pods to free resources for pending higher-priority pods. In this scenario, Pod A (priority 1000) is pending due to insufficient resources, while Pod B (priority 100) is running on the node. The scheduler will preempt (evict) Pod B to allow Pod A to be scheduled, as the priority difference is significant and preemption is enabled by default in Kubernetes (via the 'PrioritySort' and 'Preemption' plugins).

Answer

Pod A will be scheduled only after pod B completes its work

Answer

Pod A will remain pending because preemption is not enabled by default

Answer

The cluster administrator must manually delete pod B to allow pod A to schedule

Question 2

Which DNS record type does Kubernetes use to resolve a Service's ClusterIP?

Accepted Answer

A record. Kubernetes uses A records to resolve a Service's ClusterIP. When a DNS query is made for a Service name (e.g., `my-svc.my-namespace.svc.cluster.local`), the cluster's DNS server (typically CoreDNS) returns an A record containing the Service's ClusterIP address. This allows pods to reach the Service via its stable virtual IP.

Answer

PTR record

Answer

SRV record

Answer

CNAME record

Question 3

A pod is failing with 'CrashLoopBackOff'. You run 'kubectl logs mypod' and see no output. What is the first troubleshooting step?

Accepted Answer

kubectl logs mypod --previous. The correct first step is to use `kubectl logs mypod --previous` because the pod is in `CrashLoopBackOff`, meaning the current container has crashed and restarted. Since `kubectl logs mypod` shows no output, the current container may have exited before writing logs, or logs were written to stderr. The `--previous` flag retrieves logs from the last terminated container instance, which often contains the crash error message.

Answer

kubectl exec -it mypod -- sh

Answer

kubectl delete pod mypod && kubectl create -f mypod.yaml

Answer

kubectl describe pod mypod

Question 4

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

Accepted Answer

kubectl top pods. To check resource usage, use `kubectl top pods` (B) for pods and `kubectl top nodes` (C) for nodes. The incorrect options use invalid flags: `kubectl top pod --nodes` and `kubectl top node --containers` are not supported, making them syntactically invalid.

Answer

kubectl top pod --nodes

Answer

kubectl resource usage

Answer

kubectl top node --containers

Question 5

A node in your cluster is reporting 'NotReady' status. You log into the node and run 'systemctl status kubelet'. The kubelet service is not running. Which command should you use to start the kubelet and enable it to start on boot?

Accepted Answer

systemctl enable --now kubelet. `systemctl enable --now kubelet` both starts the kubelet service immediately and creates the necessary symlinks to enable it to start automatically on boot. This is the most efficient way to handle a stopped service that needs to be persistent across reboots, which is critical for a Kubernetes node to rejoin the cluster after a reboot.

Answer

systemctl start --enable kubelet

Answer

systemctl enable kubelet

Answer

systemctl start kubelet

Question 6

You need to check the resource usage of nodes in your cluster. Which command should you run?

Accepted Answer

kubectl top nodes. `kubectl top nodes` retrieves and displays real-time CPU and memory usage metrics for all nodes in the cluster. This command relies on the metrics server being deployed and functioning, which aggregates resource usage data from kubelet’s cAdvisor endpoint. It is the standard Kubernetes command for checking node-level resource consumption.

Answer

kubectl get nodes -o wide

Answer

kubectl logs --all-containers

Answer

kubectl describe nodes

Question 7

A node in the cluster has been cordoned. Which of the following is true about the node?

Accepted Answer

The node is marked as unschedulable, but existing pods continue to run.. When a node is cordoned using `kubectl cordon`, it is marked as unschedulable by setting the `node.Spec.Unschedulable` field to true. This prevents new pods from being scheduled onto the node, but existing pods continue to run normally. The node remains part of the cluster and is not removed or drained automatically.

Answer

The node is removed from the cluster.

Answer

kubectl drain is automatically performed on the node.

Answer

Existing pods on the node are immediately evicted.

Question 8

You are trying to debug a network connectivity issue between two pods. Pod A can reach the internet but cannot reach Pod B's IP address. Which command should you use to test connectivity from within Pod A to Pod B's service?

Accepted Answer

kubectl exec pod-a -- curl http://service-b:80. It uses `kubectl exec` to run a command inside Pod A, then uses `curl` to reach Pod B's service by its DNS name (`service-b`) and port 80. This tests connectivity from Pod A's network namespace to the ClusterIP service, which is the correct way to verify pod-to-service communication within the cluster. Using the service name leverages Kubernetes internal DNS (CoreDNS) to resolve to the service's virtual IP, and `curl` sends an HTTP request to confirm reachability.

Answer

kubectl exec pod-a -- nslookup service-b

Answer

curl http://:

Answer

ssh node-ip 'curl http://<pod-b-ip>:80'

Question 9

A pod is stuck in 'Pending' state. Which THREE are common causes for this?

Accepted Answer

Insufficient CPU or memory resources on any node. A pod stuck in 'Pending' state means it has not been scheduled to a node yet, or it cannot start due to missing dependencies. The three most common causes are: insufficient CPU/memory resources on any node (C) because the scheduler cannot find a node that satisfies the pod's resource requests; node taints that the pod does not tolerate (D) which prevent scheduling; and an unbound PersistentVolumeClaim (E) that the pod requires before it can start. Option A is incorrect because a node not registered would not normally lead to a pod being pending—it would simply not be considered for scheduling. Option B is incorrect because an incorrect container image name results in an ImagePullBackOff error, not a pending state.

Answer

Node not registered with the cluster

Answer

Container image name is incorrect

Question 10

Which command should you use to view the logs of a container that has previously crashed in a Pod?

Accepted Answer

kubectl logs --previous. `kubectl logs --previous` retrieves the logs from the previous instance of a container in a Pod, which is exactly what you need when a container has crashed and restarted. The `--previous` flag accesses the logs of the terminated (crashed) container, not the current running one, allowing you to see the error that caused the crash.

Answer

kubectl logs <pod-name>

Answer

kubectl describe pod <pod-name>

Answer

kubectl logs -c

Question 11

You are troubleshooting DNS resolution from within a pod. You exec into the pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command fails with 'connection timed out; no servers could be reached'. However, 'kubectl get svc -n kube-system' shows the kube-dns service with a ClusterIP. What is the MOST likely cause?

Accepted Answer

The CoreDNS pods are not running or are crashing. The error 'connection timed out; no servers could be reached' from nslookup indicates that the pod cannot reach any DNS server at all. Since the kube-dns service exists (as shown by kubectl), the most likely cause is that the backend CoreDNS pods are not running or are crashing, so there are no endpoints to forward traffic to. Without running CoreDNS pods, the service's ClusterIP has no backing pods, causing all DNS queries to time out.

Answer

The pod's /etc/resolv.conf has incorrect search domains

Answer

A network policy is blocking traffic to the kube-dns service

Answer

The DNS name does not exist

Question 12

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 'OOMKilled' status indicates the container was terminated 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 by the Out-of-Memory (OOM) killer. This directly addresses the root cause of the CrashLoopBackOff state.

Answer

Delete the namespace and redeploy all workloads

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Question 13

A cluster administrator creates a StorageClass with the following YAML:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Delete
volumeBindingMode: Immediate

A developer creates a PVC using this StorageClass. The PVC is created and remains in Pending state. What is the most likely cause?

Accepted Answer

The cluster is not running on AWS or the AWS cloud provider is not configured.. The StorageClass uses the provisioner `kubernetes.io/aws-ebs`, which is specific to the AWS cloud provider. If the cluster is not running on AWS or the AWS cloud provider is not properly configured (e.g., missing IAM roles, cloud-controller-manager not running), the provisioner cannot create the underlying EBS volume, leaving the PVC in a Pending state indefinitely.

Answer

The volumeBindingMode is Immediate, which requires a different access mode.

Answer

The PVC does not specify an access mode.

Answer

The reclaim policy is Delete, which prevents binding.

Question 14

Which component on a worker node is responsible for maintaining network rules and forwarding traffic to the correct pod?

Accepted Answer

kube-proxy. kube-proxy is the correct component because it runs on each worker node and is responsible for implementing Kubernetes Service concepts by maintaining network rules (iptables or IPVS) that allow network communication to Pods from inside or outside the cluster. It forwards traffic to the correct Pod by load-balancing across the endpoints of a Service, using the cluster IP and port.

Answer

Container runtime

Answer

kubelet

Answer

kube-scheduler

Question 15

You have a DaemonSet that runs a logging agent. You want to ensure it only runs on nodes with GPU. Which field should you set in the DaemonSet's pod template spec?

Accepted Answer

spec.template.spec.nodeSelector. `spec.template.spec.nodeSelector` is a simple, direct field in the Pod template spec that constrains which nodes the DaemonSet's pods can be scheduled on. By setting a key-value pair like `gpu: true`, you ensure the logging agent only runs on nodes that have that label, which is the standard Kubernetes mechanism for node-level selection without complex expressions.

Answer

spec.selector

Answer

spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution

Answer

spec.template.spec.nodeName

Question 16

An administrator runs 'kubectl run test-pod --image=nginx' and the pod is created but stays in 'Pending' state. Which command would BEST help diagnose why the pod is not running?

Accepted Answer

kubectl describe pod test-pod. `kubectl describe pod test-pod` provides a detailed summary of the pod's current state, including events, conditions, and status messages that reveal why the pod is stuck in 'Pending'. The 'Pending' state typically indicates that the pod has not been scheduled to a node, often due to resource constraints (CPU/memory), persistent volume claims not being bound, or node selector mismatches. The 'Conditions' and 'Events' sections in the output directly expose these issues, making it the most effective diagnostic command.

Answer

kubectl logs test-pod

Answer

kubectl exec -it test-pod -- /bin/bash

Answer

kubectl get events

Question 17

A DevOps team needs to deploy a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes. Which Kubernetes resource should they use to provision the storage?

Accepted Answer

A PersistentVolume with access mode ReadWriteMany. ReadWriteMany (RWX) is the only access mode that allows multiple pods across different nodes to simultaneously read and write to the same persistent storage volume. A PersistentVolume with access mode ReadWriteMany meets the requirement for a stateful application needing concurrent access from pods running on different nodes, typically backed by network filesystems like NFS, GlusterFS, or CephFS.

Answer

A hostPath volume

Answer

A PersistentVolume with access mode ReadWriteOnce

Answer

An emptyDir volume

Question 18

You are a platform engineer managing a Kubernetes cluster with 5 worker nodes (node1-node5). The cluster runs a mix of stateless web services and stateful databases. Users report that a critical database Pod (part of a StatefulSet) is frequently evicted during node maintenance. The StatefulSet has a single replica. You need to improve the availability of this database Pod. The current configuration: the Pod has resource requests (2 CPU, 4Gi memory) and limits (4 CPU, 8Gi memory). The cluster uses the default scheduler with no custom policies. Nodes have varying capacities: node1 and node2 have 8 CPU/32Gi memory, node3-node5 have 4 CPU/16Gi memory. During rolling node reboots, the database Pod gets evicted and takes a long time to reschedule because no node has enough resources. What should you do to minimize downtime and ensure the Pod is rescheduled promptly after eviction?

Accepted Answer

Assign a high priority class to the database Pod.. Assigning a high priority class (Option C) ensures that when the database Pod is evicted during node maintenance, the scheduler treats it as a higher-priority workload than other Pods. This allows it to preempt lower-priority Pods on nodes with sufficient capacity (e.g., node1 or node2), even if those nodes appear fully allocated, thereby minimizing downtime and ensuring prompt rescheduling.

Answer

Add nodeAffinity to prefer node1 and node2.

Answer

Create a PodDisruptionBudget with minAvailable: 1.

Answer

Increase the resource requests to match the limits.

Question 19

You have a ResourceQuota in a namespace that sets limits: pods: 10, requests.cpu: 4, requests.memory: 8Gi. You try to create a Pod with requests.cpu: 1, requests.memory: 2Gi, and no limits. The namespace currently has 8 pods using 3 CPUs and 5Gi memory in total requests. What happens?

Accepted Answer

The pod is created successfully.. The ResourceQuota only enforces the total sum of requests across all pods in the namespace. Currently, the namespace has 8 pods using 3 CPUs and 5Gi memory. Adding a pod with requests.cpu: 1 and requests.memory: 2Gi would bring totals to 4 CPUs (3+1) and 7Gi memory (5+2), both within the quota limits of 4 CPUs and 8Gi. The pod does not specify limits, but ResourceQuota does not require limits unless a LimitRange enforces default limits; here, no LimitRange is mentioned, so the pod is allowed.

Answer

The pod is rejected because it exceeds the memory request quota.

Answer

The pod is rejected because it exceeds the CPU request quota.

Answer

The pod is rejected because it does not specify CPU and memory limits.

Question 20

You run 'kubectl get nodes' and see that a node is 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'Active: inactive (dead)'. What is the most likely cause?

Accepted Answer

The kubelet service is stopped. The kubelet is the primary node agent that runs on every node and is responsible for maintaining pod lifecycles. When 'systemctl status kubelet' shows 'Active: inactive (dead)', it means the kubelet systemd service is not running. Since the kubelet must be active for the node to report its status to the control plane, a stopped kubelet directly causes the node to be 'NotReady'.

Answer

The network plugin is misconfigured

Answer

The node has been cordoned

Answer

The container runtime is not installed