CKA Practice Test 23 — 15 Questions

Question 1

A StatefulSet named 'db' manages 3 pods. The pods are named db-0, db-1, db-2. What is the expected behavior when the StatefulSet's pod management policy is set to OrderedReady and you scale down from 3 to 1 replica?

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

Accepted Answer

Pod db-2 is deleted, then db-1, and db-0 remains.. With the OrderedReady pod management policy, scaling down a StatefulSet deletes pods in reverse ordinal order, starting from the highest index. When scaling from 3 to 1 replica, pods db-2 (index 2) is deleted first, then db-1 (index 1), leaving db-0 (index 0) running. This ensures that each pod is fully terminated before the next one is deleted, maintaining the ordered startup and shutdown guarantees.

Answer

All pods are deleted simultaneously.

Answer

Only pod db-2 is deleted; db-1 and db-0 remain.

Answer

Pod db-0 is deleted first, then db-1, and db-2 remains.

Question 2

You are a cluster administrator managing a multi-node Kubernetes cluster version 1.22. The cluster runs critical applications in the 'production' namespace. You have been asked to upgrade the control plane node to version 1.23 while minimizing downtime. The cluster uses a single control plane node (not HA). You have already backed up etcd and verified the backup is valid. You have also reviewed the upgrade notes and there are no breaking changes that affect your workloads.

You have drained the control plane node and ensured all pods are evicted. The node is now in 'Ready,SchedulingDisabled' state. You then run 'kubeadm upgrade plan' and see that upgrade to v1.23.0 is available. Next, you run 'kubeadm upgrade apply v1.23.0'. The command completes successfully. However, when you try to uncordon the node with 'kubectl uncordon <node>', you get an error: 'error: unable to update node: the object has been modified; please apply your changes to the latest version and try again'. What is the most likely cause and the correct next step?

Accepted Answer

Re-run the 'kubectl uncordon' command; the conflict is transient due to concurrent updates.. The error 'the object has been modified' indicates a resource conflict due to concurrent updates to the node object, typically from the kubelet or controller manager updating the node status simultaneously. This is a transient optimistic locking conflict in Kubernetes, and simply retrying the 'kubectl uncordon' command will resolve it because the conflict is temporary and the node is already upgraded and ready to be scheduled.

Answer

Re-drain the node to reset its state, then uncordon again.

Answer

Restart the kubelet on the control plane node to refresh the node object.

Answer

Generate a new bootstrap token and rejoin the node to the cluster.

Question 3

You need to implement a PriorityClass named 'high-priority' with value 1000 and mark it as non-preempting. Which YAML field should you set to true?

Accepted Answer

spec.preemptionPolicy: Never. Setting `spec.preemptionPolicy: Never` in a PriorityClass definition marks it as non-preempting, meaning pods with this priority will not preempt lower-priority pods even if they have a higher priority value. This field is the only one that controls preemption behavior for a PriorityClass.

Answer

spec.description: "non-preempting"

Answer

spec.globalDefault: true

Answer

spec.value: 1000

Question 4

Which kube-proxy mode supports connection-based load balancing using Linux IPVS?

Accepted Answer

ipvs. The IPVS (IP Virtual Server) mode in kube-proxy uses the Linux kernel's IPVS module to implement Layer 4 (transport layer) load balancing. IPVS supports multiple scheduling algorithms (e.g., round-robin, least connections) and provides connection-based load balancing by maintaining a connection tracking table, which allows it to forward packets belonging to the same TCP/UDP session to the same backend pod. This is more efficient than iptables for large-scale clusters due to its use of hash tables (O(1) lookup) rather than linear rule chains.

Answer

iptables

Answer

kernelspace

Answer

userspace

Question 5

A pod cannot resolve a Service name 'my-svc' in the same namespace. The DNS pod is running. What is a likely cause?

Accepted Answer

The Service 'my-svc' does not exist. If the Service 'my-svc' does not exist, the CoreDNS pod will not have an A/AAAA record for it, and DNS resolution will fail with NXDOMAIN. The pod's DNS resolver queries the cluster's DNS service (typically CoreDNS) for the Service name; if no matching Service object is defined, no DNS record is created, and the name cannot be resolved regardless of other components being healthy.

Answer

The kube-proxy is not running

Answer

The Service type is ExternalName

Answer

The pod is in a different namespace

Question 6

A node has been cordoned. Which statement about the node is true?

Accepted Answer

The node is marked as unschedulable, but existing pods continue to run. When a node is cordoned using `kubectl cordon <node>`, it is marked as unschedulable by setting the `spec.unschedulable` field to `true`. This prevents new pods from being scheduled onto the node, but existing pods continue to run normally. The kubelet remains active, and the node stays in the cluster.

Answer

All pods on the node are immediately terminated

Answer

The kubelet on the node is stopped

Answer

The node is removed from the cluster

Question 7

What is the purpose of the 'kubeadm reset' command?

Accepted Answer

To undo the effects of kubeadm init or kubeadm join on a node. The 'kubeadm reset' command is designed to revert a node back to its pre-'kubeadm init' or pre-'kubeadm join' state. It cleans up all cluster-related configuration, certificates, and etcd data (if running on the control plane), effectively removing the node from the cluster and allowing it to be re-initialized or re-joined cleanly.

Answer

To restart the kubelet service

Answer

To upgrade the cluster to a newer version

Answer

To add a new node to the cluster

Question 8

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see: '0/4 nodes are available: 4 node(s) didn't match pod anti-affinity constraints'. What does this mean?

Accepted Answer

The pod's anti-affinity rule conflicts with all existing pods on every node.. The error message '4 node(s) didn't match pod anti-affinity constraints' directly indicates that the pod's anti-affinity rule (defined in the pod spec under `affinity.podAntiAffinity`) prevents it from being scheduled on any node because the rule conflicts with the labels of existing pods on all nodes. Anti-affinity ensures the pod is not co-located with certain pods, and if every node already hosts a pod matching the anti-affinity selector, no node is eligible. This is distinct from taints, node selectors, or resource shortages.

Answer

The pod has a taint that no node tolerates.

Answer

The pod has a node selector that doesn't match any node.

Answer

The cluster is out of resources.

Question 9

Which command is used to check the expiration of certificates managed by kubeadm?

Accepted Answer

kubeadm certs check-expiration. The correct command to check the expiration of certificates managed by kubeadm is `kubeadm certs check-expiration`. This command reads the certificate files located in `/etc/kubernetes/pki/` and displays their remaining validity period, allowing administrators to proactively renew certificates before they expire.

Answer

kubeadm certs status

Answer

kubeadm certs list

Answer

kubeadm certs renew

Question 10

What is the purpose of the kube-proxy component in a Kubernetes cluster?

Accepted Answer

It provides network proxy and load balancing for services. Kube-proxy is the component responsible for implementing the Kubernetes Service concept by maintaining network rules on each node. It performs connection forwarding and load balancing for Service endpoints using either iptables, IPVS, or userspace mode, ensuring that traffic destined for a Service's ClusterIP is correctly routed to healthy Pods.

Answer

It schedules pods to nodes

Answer

It manages the lifecycle of pods

Answer

It stores cluster configuration data

Question 11

You need to expose a Service externally using an Ingress. The Ingress controller requires a specific IngressClass. How do you specify the IngressClass in the Ingress resource?

Accepted Answer

Set spec.ingressClassName: nginx. The `spec.ingressClassName` field is the standard way to specify the IngressClass for an Ingress resource in Kubernetes v1.18+ (GA in v1.22). This field references the name of an IngressClass resource, which defines the controller (e.g., nginx, haproxy) and its configuration. Using this field ensures the Ingress controller selects the correct implementation.

Answer

Set spec.class: nginx

Answer

Add an annotation: kubernetes.io/ingress.class: nginx

Answer

Create an IngressClass resource and reference it via spec.ingressClassRef

Question 12

You need to check the CPU and memory usage of all pods in the 'production' namespace. Which command should you use?

Accepted Answer

kubectl top pods -n production. The `kubectl top pods` command retrieves real-time CPU and memory metrics for pods from the metrics server, which is required for the CKA exam. The `-n production` flag restricts the output to the 'production' namespace, making option A the correct choice for checking resource usage of all pods in that namespace.

Answer

kubectl get pods -n production --show-labels

Answer

kubectl get resourceusage pods -n production

Answer

kubectl top nodes -n production

Question 13

A pod cannot resolve a service DNS name. The cluster uses CoreDNS. Which of the following is the most likely cause if the pod's /etc/resolv.conf contains 'nameserver 10.96.0.10' and the CoreDNS pod is running?

Accepted Answer

The CoreDNS ConfigMap does not have the correct cluster domain.. If the CoreDNS ConfigMap does not specify the correct cluster domain (e.g., `cluster.local`), CoreDNS will not respond to queries for service DNS names within that domain. The pod's `resolv.conf` shows the correct ClusterIP of the CoreDNS service (10.96.0.10), and the CoreDNS pod is running, so the issue is likely a misconfiguration in the CoreDNS plugin settings, specifically the `kubernetes` plugin's `clusterDomain` parameter.

Answer

The pod's DNS policy is set to 'Default'.

Answer

The CoreDNS pod is in CrashLoopBackOff.

Answer

The service's DNS name is misspelled.

Question 14

You are a CKA managing a production cluster with 5 worker nodes. A developer reports that a new deployment 'payment-service' is not accessible from other pods via its Service 'payment-svc' in the 'default' namespace. The Service is of type ClusterIP with selector 'app: payment'. The deployment has 3 replicas, all showing 'Running' status. From a test pod, you run 'curl http://payment-svc:8080' and get 'Connection refused'. You verify that the pods are listening on port 8080 and the container's readiness probe passes. 'kubectl get endpoints payment-svc' shows no endpoints. 'kubectl describe svc payment-svc' shows the selector 'app=payment'. What is the most likely cause?

Accepted Answer

The pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.. The most likely cause is that the pods' labels do not match the Service's selector. The Service 'payment-svc' uses selector 'app: payment', but the pods have label 'app: payment-service'. Since the selector does not match any pods, the Service's endpoints list is empty, causing 'Connection refused' when trying to reach the ClusterIP. The pods are running and listening on port 8080, but the Service has no backends to forward traffic to.

Answer

A NetworkPolicy is blocking traffic from the test pod to the service IP.

Answer

The service type should be NodePort to allow in-cluster access.

Answer

The readiness probe is failing on all pods, causing them to be removed from service endpoints.

Question 15

A pod is unable to resolve DNS names. You exec into the pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command hangs. What is the MOST likely cause?

Accepted Answer

The CoreDNS service is not running or is misconfigured. The CoreDNS service is responsible for DNS resolution within the cluster. If it is not running or misconfigured, DNS queries from pods will hang or fail. The `nslookup` command hanging indicates that the DNS request is not being answered, which is a classic symptom of a non-functional or unreachable DNS service.

Answer

The pod's /etc/resolv.conf is missing

Answer

The kubelet is not running on the node

Answer

The pod's network policy blocks DNS traffic