CKA sample questions with answers

CKA sample questions

Certified Kubernetes Administrator (CKA), CNCF / The Linux Foundation.

1. Question 1

   Domain: Storage

   How do you mark an existing StorageClass as the cluster's default class?

   1. Set a top-level field default: true in the StorageClass manifest
   2. Set the annotation storageclass.kubernetes.io/is-default-class to "true" on it
   3. Add the label kubernetes.io/default-storage-class=true to it
   4. Rename the StorageClass to default
   Show the answer

   Answer: B. Set the annotation storageclass.kubernetes.io/is-default-class to "true" on it

   The default class is chosen by the storageclass.kubernetes.io/is-default-class annotation, for example with kubectl patch storageclass. StorageClass has no default field, and neither a label nor the name default has any special meaning to the DefaultStorageClass admission logic.

   Checked against: https://kubernetes.io/docs/tasks/administer-cluster/change-default-storage-class/

2. Question 2

   Domain: Workloads & Scheduling

   A StatefulSet db has 3 replicas, a volumeClaimTemplates entry named data, and default settings for persistentVolumeClaimRetentionPolicy and podManagementPolicy. You scale it to 2 replicas.

   What happens to the Pods and their claims?

   1. Pod db-0 is terminated first because it is the oldest
   2. Pod db-2 is terminated and data-db-2 is deleted with it
   3. Pod db-2 is terminated and its claim data-db-2 is kept
   4. All three Pods are restarted to renumber the remaining replicas
   Show the answer

   Answer: C. Pod db-2 is terminated and its claim data-db-2 is kept

   StatefulSets scale down in reverse ordinal order, so the highest ordinal goes first, and the default retention policy (whenScaled: Retain) keeps its PVC so the data returns if you scale up again. Deleting claims on scale-down only happens when whenScaled is set to Delete.

   Checked against: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

3. Question 3

   Domain: Workloads & Scheduling

   A log-collection agent must run exactly one copy on every node, and new nodes must receive a copy automatically when they join.

   Which workload resource should you use?

   1. Deployment with replicas equal to the node count and Pod anti-affinity
   2. StatefulSet with one replica per node
   3. DaemonSet
   4. Job with parallelism equal to the node count
   Show the answer

   Answer: C. DaemonSet

   A DaemonSet controller ensures one Pod per eligible node and adds Pods as nodes join. A Deployment with anti-affinity can spread Pods, but its replica count does not follow the node count, so a newly added node would not get an agent.

   Checked against: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

4. Question 4

   Domain: Services & Networking

   Pods must resolve names under corp.internal using the corporate DNS server 10.10.0.53, while all other lookups keep working as before.

   What is the correct change?

   1. Add nameserver 10.10.0.53 to /etc/resolv.conf on every node so that CoreDNS and all Pods pick up the corporate server
   2. Add a corp.internal:53 server block that forwards to 10.10.0.53 in the coredns ConfigMap's Corefile
   3. Set dnsPolicy: ClusterFirstWithHostNet on every Pod
   4. Create an ExternalName Service named corp.internal pointing at 10.10.0.53
   Show the answer

   Answer: B. Add a corp.internal:53 server block that forwards to 10.10.0.53 in the coredns ConfigMap's Corefile

   CoreDNS supports stub domains through extra server blocks, so queries for corp.internal go to the corporate server while everything else uses the existing configuration; the reload plugin picks up the change. Editing node resolv.conf only affects Pods that inherit node DNS, not the ClusterFirst Pods that query CoreDNS.

   Checked against: https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/

5. Question 5

   Domain: Services & Networking

   Two NetworkPolicies select the Pods app=api. One allows ingress from app=web, the other allows ingress from app=batch.

   What traffic reaches the api Pods?

   1. Only traffic from the policy created most recently
   2. Only traffic allowed by both policies, which is none
   3. The API server rejects the second policy as conflicting
   4. Traffic from both app=web and app=batch, because policies are additive
   Show the answer

   Answer: D. Traffic from both app=web and app=batch, because policies are additive

   NetworkPolicies never conflict: once a Pod is selected, the allowed traffic is the union of all rules from every policy that applies to it. There is no ordering or intersection, so adding a policy can only widen what is allowed for already isolated Pods.

   Checked against: https://kubernetes.io/docs/concepts/services-networking/network-policies/

6. Question 6

   Domain: Troubleshooting

   A newly joined node stays NotReady. Its Ready condition reports: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized.

   Where should you look?

   1. The kube-proxy ConfigMap in kube-system, which must list the node's Pod CIDR before the node becomes Ready
   2. The CNI configuration in /etc/cni/net.d and the network add-on Pod on that node
   3. At the CoreDNS Corefile
   4. At the etcd member list on the control plane
   Show the answer

   Answer: B. The CNI configuration in /etc/cni/net.d and the network add-on Pod on that node

   The runtime reports NetworkReady=false when no valid CNI configuration or plugin is available, which usually means the add-on's DaemonSet Pod has not started on the node or failed to write its config. kube-proxy and CoreDNS depend on Pod networking rather than providing it.

   Checked against: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/

7. Question 7

   Domain: Troubleshooting

   Node worker-3 reports DiskPressure=True. Some Pods on it have been evicted, and new Pods are no longer scheduled there.

   Which statement correctly describes what is happening?

   1. The scheduler evicts Pods from the node, one at a time, until the free disk space satisfies every PodDisruptionBudget involved
   2. The API server evicts Pods whose PersistentVolumes are larger than the free space
   3. The kubelet hit an eviction threshold: it reclaims images and dead containers, evicts Pods, and taints the node
   4. kube-controller-manager deletes the node's images and then marks it Ready
   Show the answer

   Answer: C. The kubelet hit an eviction threshold: it reclaims images and dead containers, evicts Pods, and taints the node

   Node-pressure eviction is performed by the kubelet: it first reclaims node-level resources and then evicts Pods, while the node.kubernetes.io/disk-pressure taint keeps new Pods away. Node-pressure eviction does not honour PodDisruptionBudgets, and the scheduler never evicts Pods for disk pressure.

   Checked against: https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/

8. Question 8

   Domain: Troubleshooting

   Pods of Deployment cart are Running, but the cart Service's EndpointSlice lists their addresses with ready: false, and clients receive no responses.

   What is the most likely cause?

   1. The Pods' readiness probe is failing
   2. The Service selector does not match the Pods
   3. kube-proxy is not running on the nodes
   4. The Pods' liveness probe is disabled
   Show the answer

   Answer: A. The Pods' readiness probe is failing

   Addresses appear in the EndpointSlice with ready: false when the Pods match the selector but are not Ready, typically because readiness checks fail, and traffic is not sent to them. A selector mismatch would leave the Pods out of the slice entirely.

   Checked against: https://kubernetes.io/docs/tasks/debug/debug-application/debug-service/

9. Question 9

   Domain: Cluster Architecture, Installation & Configuration

   You are upgrading the first control-plane node of a kubeadm cluster from v1.34 to v1.35, with the package repository already switched to v1.35.

   Which order is correct?

   1. Upgrade kubelet and kubectl, restart the kubelet, upgrade the kubeadm package, then run kubeadm upgrade plan and kubeadm upgrade apply v1.35.x, and finally uncordon
   2. Run kubeadm upgrade apply with the old kubeadm binary, then upgrade all packages together
   3. Drain every node in the cluster first, then run kubeadm upgrade node on each one
   4. Upgrade the kubeadm package, run kubeadm upgrade plan and kubeadm upgrade apply v1.35.x, drain, upgrade kubelet and kubectl, restart the kubelet, uncordon
   Show the answer

   Answer: D. Upgrade the kubeadm package, run kubeadm upgrade plan and kubeadm upgrade apply v1.35.x, drain, upgrade kubelet and kubectl, restart the kubelet, uncordon

   kubeadm must be upgraded first because upgrade apply uses the new binary to upgrade the control-plane components; the kubelet follows, since it must never be newer than the API server. Upgrading the kubelet before the control plane is the classic ordering mistake.

   Checked against: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

10. Question 10

    Domain: Cluster Architecture, Installation & Configuration

    After installing an operator, you want to see which resource types it added under the API group monitoring.example.com and whether they are namespaced.

    Which command shows this?

    1. kubectl api-resources --api-group=monitoring.example.com
    2. kubectl get crd --api-group=monitoring.example.com --namespaced
    3. kubectl api-versions monitoring.example.com
    4. kubectl explain monitoring.example.com
    Show the answer

    Answer: A. kubectl api-resources --api-group=monitoring.example.com

    kubectl api-resources lists resource names, short names, API versions, kinds and whether each is namespaced, and can filter by group. api-versions only prints group/version strings, and kubectl explain describes the fields of a specific resource rather than listing a group.

    Checked against: https://kubernetes.io/docs/reference/kubectl/generated/kubectl_api-resources/