These questions cover cluster architecture and node management — topics that appear in the CKA's Cluster Architecture domain and require hands-on command knowledge under exam pressure.
Question 1
A node has the taint gpu=true:NoSchedule applied. A pod was already running on that node before the taint was added. What happens to that running pod?
- A) It is immediately evicted from the node
- B) It continues running —
NoScheduleonly affects new scheduling decisions - C) It is drained gracefully and rescheduled on another node
- D) It enters a
Pendingstate until the taint is removed
Answer: B — It continues running
NoSchedule taints prevent new pods without a matching toleration from being scheduled onto the node. They have no effect on pods already running there. To evict existing pods, you need the NoExecute effect.
The three taint effects:
| Effect | New pods without toleration | Existing pods without toleration |
|---|---|---|
NoSchedule | Not scheduled | Not affected |
PreferNoSchedule | Avoided if possible | Not affected |
NoExecute | Not scheduled | Evicted (after optional tolerationSeconds) |
On the CKA, always check the taint effect before assuming a pod will be evicted.
</details>Question 2
You need to run a monitoring agent on the control-plane node that must start even if the API server is down. Which mechanism is most appropriate?
- A) A DaemonSet with a node selector targeting the control-plane node
- B) A static pod defined in the kubelet's
staticPodPathdirectory - C) A pod with
priorityClassName: system-cluster-critical - D) A Deployment with
hostNetwork: trueand a node affinity rule
Answer: B — A static pod
Static pods are managed directly by the kubelet on each node — they don't require the API server or scheduler. The kubelet watches a directory (by default /etc/kubernetes/manifests) and starts any pod manifests it finds there at boot, including the control-plane components themselves (kube-apiserver, kube-controller-manager, kube-scheduler, etcd).
Why the others fail when the API server is down:
- DaemonSet: Requires the API server to be scheduled and maintained
- Priority class: Affects scheduling order, not kubelet-level startup
- Deployment: Requires the API server and scheduler
The CKA exam frequently asks you to create or modify static pods — know the manifest directory path and that you edit files directly (no kubectl apply needed).
Question 3
You need to back up the etcd cluster state. Which command is correct?
- A)
kubectl get etcd --all-namespaces -o yaml > etcd-backup.yaml - B)
etcdctl snapshot save /backup/etcd-snapshot.dbwith the correct CA and cert flags - C)
cp -r /var/lib/etcd /backup/etcd-backup - D)
kubectl create backup etcd --destination=/backup
Answer: B — etcdctl snapshot save with cert flags
etcdctl is the CLI for etcd. To take a snapshot you need to authenticate with the etcd TLS certificates, then specify a destination path:
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
To verify the snapshot:
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot.db
To restore:
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db \
--data-dir=/var/lib/etcd-restore
Copying /var/lib/etcd directly while etcd is running risks an inconsistent backup. kubectl has no etcd backup command.
Key Takeaways
NoScheduledoesn't evict running pods;NoExecutedoes — know all three taint effects- Static pods are managed by the kubelet directly from
/etc/kubernetes/manifestsand survive API server outages - etcd backup uses
etcdctl snapshot savewith--cacert,--cert,--key— these flags appear on every CKA backup task