CKA — Certified Kubernetes Administrator practice questions and exam guide

What is the difference between cordon and drain?

1. Both mark the node unschedulable and evict every running pod from it
2. drain only marks the node unschedulable; cordon evicts the running pods
3. cordon marks unschedulable only; drain also evicts the existing pods
4. cordon deletes the node object; drain only stops new pods landing there

Answer: C — cordon marks unschedulable only; drain also evicts the existing pods

C is right: cordon sets spec.unschedulable so no new pods land there while existing workloads keep running, and drain performs the cordon and then evicts. A overstates cordon, which never touches running pods. B is the direction-reversal trap - the two verbs are swapped. D confuses cordon with 'kubectl delete node'; cordon leaves the node object registered and its pods running.

A ClusterRole is created with `aggregationRule` selecting the label `rbac.example.com/aggregate: "true"`, and its `rules` list is left empty. What happens?

1. The controller fills its rules by unioning rules from matching labelled ClusterRoles
2. The API server rejects it because a ClusterRole must declare at least one rule
3. It denies every request that other roles allow, acting as a deny overlay
4. It grants nothing permanently, since rule aggregation only ever applies to namespaced Roles

Answer: A — The controller fills its rules by unioning rules from matching labelled ClusterRoles

A) Correct — the aggregation controller continuously recomputes the rules field as the union of every ClusterRole carrying the selected label. B) invents a validation rule; an empty rules list is expected for aggregated roles. C) misreads RBAC entirely, which is purely additive and has no deny semantics. D) reverses the scope: aggregation is a ClusterRole feature only.

A cluster runs control plane v1.34 and the team wants to move to v1.36 in one maintenance window. What is the MOST appropriate plan?

1. Upgrade straight to v1.36, since kubeadm validates and repairs any skipped API changes
2. Upgrade to v1.35 first, verify the cluster, then upgrade to v1.36 in a second pass
3. Downgrade the kubelets to v1.33 first so the control plane can jump two versions safely
4. Upgrade the workers to v1.36 first so the control plane never runs ahead of them

Answer: B — Upgrade to v1.35 first, verify the cluster, then upgrade to v1.36 in a second pass

B) Correct — kubeadm supports upgrading one minor version at a time, so reaching v1.36 from v1.34 requires passing through v1.35. A) is the common misconception that the tool will bridge skipped minors; it refuses. C) inverts the skew rule and would make things worse, since kubelets may trail the control plane but must not lead it in this way. D) reverses the required order: the control plane is always upgraded before the nodes.

Which command opens a live object's manifest for in-place modification?

1. kubectl create -f <file>, which fails if the object already exists rather than changing it
2. kubectl edit <resource> <name>, which opens the live object and applies it once saved
3. kubectl delete then recreate, which loses the object's UID, status and event history
4. kubectl scale, which changes only the replica count field on scalable workload objects
5. kubectl logs, which reads container output and cannot modify an object's specification

Answer: B — kubectl edit <resource> <name>, which opens the live object and applies it once saved

B is the answer: kubectl edit fetches the live object, opens it in $EDITOR and submits the result, validating before it applies. A fails on an existing object because create is not idempotent — apply is. C reaches the same end state but destroys the object's identity and any dependent state. D changes one field only. E is read-only. For anything durable, prefer editing the manifest in version control and applying it.

What is the default Deployment update strategy and which fields tune it?

1. Recreate, tuned with maxUnavailable to stagger the terminating pods
2. A built-in Canary strategy driven by a stepWeight percentage field
3. A built-in BlueGreen strategy that flips the Service selector label
4. RollingUpdate, tuned with the maxSurge and maxUnavailable fields

Answer: D — RollingUpdate, tuned with the maxSurge and maxUnavailable fields

D is right: RollingUpdate is the default, with maxSurge and maxUnavailable both defaulting to 25%, so the Deployment can run slightly over the replica count while replacing pods. A names the other real strategy but attaches the wrong field - Recreate terminates every old pod before creating new ones and takes no rollout tuning. B and C name deployment patterns Kubernetes has no built-in primitive for; they are implemented with extra Services, or by add-ons such as Argo Rollouts or a service mesh.

Which object is BEST for running a logging or monitoring agent on every node?

1. A Deployment with replicas set to the node count and pod anti-affinity per hostname
2. A StatefulSet, which gives ordinal names and a dedicated volume claim to each replica
3. A DaemonSet, which runs one pod per matching node and follows nodes joining or leaving
4. A Job with parallelism equal to the node count, which runs the agent once and completes
5. A CronJob that recreates the agent pods on a schedule so new nodes eventually get one

Answer: C — A DaemonSet, which runs one pod per matching node and follows nodes joining or leaving

C is the answer: a DaemonSet keeps exactly one pod on every node that matches its selector and reacts automatically when nodes join or are removed; tolerations let it run on tainted control-plane nodes. A tempts because it can approximate the layout, but the replica count is static and breaks the moment the cluster scales. B gives identity, not per-node coverage. D and E have completion semantics and leave gaps between runs.

Secret stored 'as-is' in etcd is:

1. AES-256 encrypted by default using a key held by the apiserver
2. Stored as a salted hash that the kubelet verifies at mount time
3. Held only in kubelet memory and never written to etcd at all
4. base64-encoded only, unless encryption at rest is configured

Answer: D — base64-encoded only, unless encryption at rest is configured

D is right: by default a Secret is merely base64-encoded in etcd, and encryption at rest requires an EncryptionConfiguration passed to the apiserver. A assumes that configuration is on by default. B confuses secrets with password storage; the value must be recoverable. C describes projected volumes on the node, not the stored object.

A topology spread constraint uses maxSkew 1, whenUnsatisfiable `DoNotSchedule`, across zones. One zone's nodes are full. What happens to the next pod?

1. It schedules into the emptiest zone that still has capacity, keeping skew within 1
2. It stays Pending, because the constraint is evaluated before any zone is considered
3. It schedules anywhere, since DoNotSchedule downgrades to a preference under pressure
4. It evicts a lower-priority pod from the full zone to preserve perfect balance

Answer: A — It schedules into the emptiest zone that still has capacity, keeping skew within 1

A) Correct — the constraint filters out placements that would push skew past the limit, and a zone with capacity and fewer matching pods satisfies it. B) assumes deadlock where a valid placement exists. C) describes ScheduleAnyway, the other value of whenUnsatisfiable, not DoNotSchedule. D) borrows preemption, which is driven by PriorityClass and is not how spread constraints are enforced.

An application stores session state in memory and needs repeat requests from a client routed to the same pod, without introducing a proxy. What is the MOST appropriate Service setting?

1. Set sessionAffinity to ClientIP with a timeout under sessionAffinityConfig
2. Set externalTrafficPolicy to Local so each node only serves its own local pods
3. Make the Service headless so clients pick and reuse one endpoint themselves
4. Set internalTrafficPolicy to Local so in-cluster callers keep node-local affinity

Answer: A — Set sessionAffinity to ClientIP with a timeout under sessionAffinityConfig

A) Correct — ClientIP affinity is the built-in stickiness mechanism, pinning a source address to one backend for the configured timeout. B) preserves source IP and avoids a second hop but gives no per-client pinning. C) shifts the whole selection burden to the client and offers no guarantee of stickiness. D) constrains routing to same-node endpoints, which is a topology optimisation rather than client affinity.

A pod in namespace `web` must reach a Service named `cache` in namespace `data`. Which name is the correct fully qualified form?

1. cache.svc.data.cluster.local
2. data.cache.svc.cluster.local
3. cache.data.pod.cluster.local
4. cache.data.svc.cluster.local

Answer: D — cache.data.svc.cluster.local

D) Correct — the pattern is service.namespace.svc.cluster.local, so the Service name comes first and the namespace second. A) and B) swap the namespace and svc labels or reverse service and namespace order, a classic ordering trap. C) uses the `pod` subdomain, which belongs to the pod-IP-based A record form (dashed-IP.namespace.pod.cluster.local), not to Services.

What is the default Service type and how is it reachable?

1. ClusterIP, reachable only from inside the cluster network
2. LoadBalancer, which provisions an external cloud address
3. NodePort, reachable on every node's IP at a high port
4. ExternalName, returning a CNAME to an outside hostname

Answer: A — ClusterIP, reachable only from inside the cluster network

A is right: a Service with no type gets a ClusterIP, a virtual address routable only within the cluster and programmed by kube-proxy on each node. B is the top of the stack: LoadBalancer builds on NodePort, which builds on ClusterIP, and it needs a cloud controller or MetalLB to allocate an address. C is a real type but not the default. D is the odd one out - ExternalName allocates no address at all and only returns a DNS CNAME.

Which Service type is best for an internal cluster DB accessed by name only, with no proxying?

1. ClusterIP, which proxies traffic to pods via a virtual cluster IP
2. NodePort, which opens a static port on every node for the Service
3. LoadBalancer, which asks the cloud provider for an external IP
4. ExternalName, which returns a CNAME record and does no proxying

Answer: D — ExternalName, which returns a CNAME record and does no proxying

D is right: ExternalName makes CoreDNS answer with a CNAME to the configured external name, so there is no proxy and no Endpoints object. A, B and C all allocate a virtual IP and program kube-proxy, which is exactly the proxying the stem rules out; B and C additionally expose the Service outside the cluster.

A PersistentVolumeClaim sits in Pending with an event saying no persistent volumes are available for it. Which condition would MOST plausibly explain this?

1. The claim requests a storageClassName that matches no existing class or provisioner
2. The claim was created before the pod that mounts it, so binding is deferred to pod creation
3. The claim uses ReadWriteOnce, which cannot bind while any other claim exists on the node
4. The claim omits a volumeName, which the binder requires in order to select a volume

Answer: A — The claim requests a storageClassName that matches no existing class or provisioner

A) Correct — with no matching class and no suitable pre-provisioned PV, there is nothing for the binder or a provisioner to satisfy the claim with. B) confuses ordering with WaitForFirstConsumer, which is a binding mode, not a universal rule, and would report a different event. C) misstates RWO, which limits concurrent mounts of one volume, not the existence of other claims. D) is wrong, volumeName is an optional field used for manual pre-binding.

A StatefulSet with volumeClaimTemplates is scaled from 3 replicas down to 1. What happens to the claims created for the removed pods, by default?

1. They are deleted along with their pods so that storage is reclaimed automatically
2. They are retained, and scaling back up reattaches the same volumes to the same ordinals
3. They are marked Released and their reclaim policy is switched to Retain by the controller
4. They are merged into the surviving replica's claim to consolidate the freed capacity

Answer: B — They are retained, and scaling back up reattaches the same volumes to the same ordinals

B) Correct — the StatefulSet controller deliberately leaves per-ordinal claims in place, so data is preserved and a later scale-up rebinds each pod to its original volume. A) describes what the optional persistentVolumeClaimRetentionPolicy can be configured to do, but it is not the default. C) confuses PVC lifecycle with the PV phase and misstates who sets reclaim policy. D) invents capacity consolidation that no controller performs.

Which access mode means a volume can be mounted read-write by exactly one POD (not just one node)?

1. ReadWriteOnce (RWO)
2. ReadWriteMany (RWX)
3. ReadWriteOncePod (RWOP)
4. ReadOnlyMany (ROX)

Answer: C — ReadWriteOncePod (RWOP)

RWO = one node. RWOP = one pod (stronger, prevents two pods on the same node from mounting). ROX/RWX allow multiple. Subtle direction-of-scope trick.

Expanding a PVC's storage (resize). Requirements?

1. allowVolumeExpansion on the StorageClass and CSI driver support
2. Editing the capacity field on the PV object directly as an admin
3. Deleting the claim and recreating it with a larger storage request
4. A pod restart in every case, since resize is offline only

Answer: A — allowVolumeExpansion on the StorageClass and CSI driver support

A is right: expansion needs allowVolumeExpansion set true on the class and a driver that implements it, after which you raise spec.resources.requests.storage on the claim. B edits a field the controller overwrites. C loses the data the claim protects. D overstates it, since many drivers expand online and only some need a restart to grow the filesystem.

A kubelet fails to start after a configuration change. Which file is the MOST relevant to inspect on a kubeadm-provisioned node?

1. /var/lib/kubelet/config.yaml, the kubelet's component configuration file
2. /etc/kubernetes/admin.conf, which supplies the kubelet's node identity
3. /etc/containerd/config.toml, which the kubelet parses at startup for runtime options
4. /etc/kubernetes/manifests/kubelet.yaml, the kubelet's own static pod definition

Answer: A — /var/lib/kubelet/config.yaml, the kubelet's component configuration file

A) Correct — kubeadm writes the kubelet's KubeletConfiguration there and the systemd drop-in passes it with --config, so a malformed field here stops the service from starting. D) is self-contradictory in a tempting way: the kubelet runs the static pods, so it cannot itself be one. B) is the cluster-admin kubeconfig; the kubelet authenticates with kubelet.conf instead. C) is containerd's own file, parsed by containerd, not by the kubelet.

You need to confirm which containers the runtime is actually running on a node, independent of what the API server believes. Which command is MOST appropriate?

1. `crictl ps`, which queries the CRI endpoint directly on that node
2. `kubectl get pods -o wide --field-selector spec.nodeName=<node>`
3. `crictl images`, listing what the runtime has pulled and can start
4. `kubectl describe node <node>` and reading the allocated-resources table

Answer: A — `crictl ps`, which queries the CRI endpoint directly on that node

A) Correct — `crictl ps` talks to the CRI socket on the host and shows the runtime's own view, which is exactly the independent evidence you want when API state is suspect. B) and D) are both useful but derive entirely from the API server, so they cannot corroborate or contradict it. C) lists images rather than running containers, answering a neighbouring question about pull state.

A kubeadm cluster's control-plane components run as static pods. Which statement about how those pods are managed is MOST accurate?

1. They are ordinary Deployments that kubeadm flags as cluster-critical
2. The scheduler places them first at boot, then hands ownership to the local kubelet
3. The kubelet watches a manifest directory on disk and starts them locally
4. A DaemonSet in kube-system reconciles them, which is why they tolerate all taints

Answer: C — The kubelet watches a manifest directory on disk and starts them locally

C) Correct — static pods are read straight from the kubelet's staticPodPath (on kubeadm, /etc/kubernetes/manifests) and started locally; the API server only ever sees read-only mirror pods. This is precisely what lets the API server bootstrap itself. B) inverts the bootstrap problem: the scheduler cannot place the API server that the scheduler needs. D) and A) both assume API-driven controllers, which cannot work before the API server exists; the mirror pods they see in kube-system make this misconception tempting.

During `kubeadm upgrade`, which sequence describes the correct order of operations on the FIRST control-plane node?

1. Drain the node, run `kubeadm upgrade apply`, upgrade the kubeadm binary, uncordon
2. Upgrade the kubeadm binary, run `kubeadm upgrade plan`, then `kubeadm upgrade apply`
3. Upgrade kubelet and kubectl first, then run `kubeadm upgrade apply` for the components
4. Run `kubeadm upgrade node`, then upgrade the kubeadm binary and restart the kubelet

Answer: B — Upgrade the kubeadm binary, run `kubeadm upgrade plan`, then `kubeadm upgrade apply`

B) Correct — kubeadm itself must be at the target version before it can plan and apply the upgrade of the control-plane components; kubelet and kubectl packages are upgraded afterwards. A) is direction-reversed: applying with the old kubeadm binary cannot produce the new version. C) upgrades the node agent ahead of the control plane, violating the version-skew ordering. D) uses `kubeadm upgrade node`, which is the subcommand for additional control-plane and worker nodes, not the first one.

A Service has no endpoints and clients get connection refused, although the backing pods are Running and Ready. What is the MOST likely cause?

1. The Service's selector does not match the labels on the pods
2. kube-proxy is running in iptables mode, which hides endpoints from the API
3. The Service lacks an externalTrafficPolicy, so endpoints are not populated
4. CoreDNS has not yet created the Service's A record, delaying registration

Answer: A — The Service's selector does not match the labels on the pods

A) Correct — the endpoints controller populates EndpointSlices purely from a label-selector match, so healthy Ready pods with an empty endpoint list points at a selector or label typo; `kubectl get endpoints <svc>` confirms it. D) is a distinct failure: a missing DNS record produces name-resolution errors, not an empty endpoint set. B) misstates kube-proxy, which consumes endpoints rather than concealing them. C) misapplies externalTrafficPolicy, which only shapes traffic for externally exposed Service types.

Pod stuck Terminating for many minutes. Common cause?

1. A finalizer is still set, a preStop hangs, or detach is stuck
2. The image pull for the replacement pod is still running
3. The kubelet on that node was itself OOMKilled at boot
4. The scheduler has not yet placed the replacement pod

Answer: A — A finalizer is still set, a preStop hangs, or detach is stuck

A is right: once deletionTimestamp is set the object waits on finalizers, on the preStop hook completing and on volumes detaching, so inspect those before reaching for --force --grace-period=0. B and D describe the replacement pod, which does not hold the old one open. C would stall far more than one deletion.

kubectl port-forward sends traffic to:

1. Any node IP in the cluster, chosen by kube-proxy at connection time
2. A local port on your machine, tunnelled via the apiserver to a pod
3. The Ingress controller, which then routes to the backing Service
4. Any Service ClusterIP, load-balanced across its ready endpoints

Answer: B — A local port on your machine, tunnelled via the apiserver to a pod

B is right: port-forward opens an apiserver-mediated stream to a named pod's container port, bypassing Services entirely, which is why it works for debugging something never exposed. A and D describe kube-proxy's Service data path, which port-forward does not use. C describes external ingress traffic, an unrelated path.

Container shows OOMKilled but limits.memory is unset. Why was it killed?

1. The cgroup default limit applies even when none is set
2. The node itself ran out of memory, so the kernel stepped in
3. OOMKilled cannot occur unless a memory limit is defined
4. The liveness probe killed it and reported the wrong reason

Answer: B — The node itself ran out of memory, so the kernel stepped in

B is right: without a limit the container may grow to the node's capacity, and when the node exhausts memory the system OOM killer or kubelet eviction terminates it anyway, which is why BestEffort pods are the first victims. A invents a default limit. C denies the observed state. D would be reported as a probe failure.

What is the difference between volumeBindingMode Immediate and WaitForFirstConsumer?

Immediate provisions and binds the volume as soon as the PVC is created, which can place it in a zone where the pod cannot be scheduled. WaitForFirstConsumer delays provisioning until a pod using the claim is scheduled, so the volume is created with the pod's node and zone constraints in mind.

Endpoints?

List of pod IPs backing a service. Updated automatically.

What happens to a pod as soon as any NetworkPolicy selects it?

It switches from allow-all to deny-by-default for the direction(s) named in that policy's policyTypes. Only traffic matched by some policy is then permitted; pods that no policy selects are unaffected and stay fully open.

CKA exam structure?

Entirely performance-based tasks solved from a command line against live clusters, 2 hours, pass mark 66%, remotely proctored. The task count is not published. Purchase includes two attempts and the certification is valid 2 years.

A container has restarted — which flags of kubectl logs do you need?

'kubectl logs <pod> --previous' shows the output of the last terminated instance, which is where a crash reason actually appears, and '-c <container>' selects one container in a multi-container or init-container pod. Add --since or --tail to narrow the window.

Generate YAML quickly?

kubectl create deployment <name> --image=<image> --dry-run=client -o yaml > file.yaml