Certified Kubernetes Administrator (CKA) #27 Full-Length Practice Exam — 17 Tasks with Solutions

Connect to the control plane node, switch to root, and save the snapshot.

ssh cluster1-controlplane
sudo -i

ETCDCTL_API=3 etcdctl snapshot save /opt/etcd-backup.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

Once it finishes, check the snapshot status.

ETCDCTL_API=3 etcdctl --write-out=table snapshot status /opt/etcd-backup.db

Explanation: snapshot save connects to etcd with a client certificate, so all three of --cacert, --cert, and --key are required, and you can find the paths in the --cert-file, --key-file, and --trusted-ca-file values of the etcd static Pod manifest (/etc/kubernetes/manifests/etcd.yaml). The most common trap is dropping ETCDCTL_API=3, which makes the command run against the v2 API and fail.

Restore the snapshot into the new directory.

ETCDCTL_API=3 etcdctl snapshot restore /opt/etcd-backup.db \
  --data-dir=/var/lib/etcd-restore

In the etcd static Pod manifest, change the host path to the new directory.

vim /etc/kubernetes/manifests/etcd.yaml

  volumes:
    - name: etcd-data
      hostPath:
        path: /var/lib/etcd-restore
        type: DirectoryOrCreate

Wait for kubelet to detect the manifest change and bring the etcd Pod back up, then verify.

crictl ps | grep etcd
k get nodes

Explanation: snapshot restore only creates a new data directory — it does not restart etcd. The actual switch happens at the step where you change hostPath.path in the static Pod manifest to the new directory, making kubelet recreate the etcd Pod against the new data. Watch out for the permissions on the parent path of --data-dir and for the brief moment the existing etcd container goes down.

On the control plane node, bump kubeadm, then check and apply the upgrade plan.

ssh cluster1-controlplane
sudo -i

apt-get update && apt-get install -y kubeadm=1.31.1-1.1
kubeadm upgrade plan
kubeadm upgrade apply v1.31.1

Bump the control plane’s kubelet and kubectl, then restart it with drain,uncordon.

kubectl drain cluster1-controlplane --ignore-daemonsets
apt-get install -y kubelet=1.31.1-1.1 kubectl=1.31.1-1.1
systemctl daemon-reload && systemctl restart kubelet
kubectl uncordon cluster1-controlplane

Drain the worker from the control plane, then upgrade it on the node itself.

kubectl drain node01 --ignore-daemonsets

ssh node01
sudo -i
apt-get update && apt-get install -y kubeadm=1.31.1-1.1
kubeadm upgrade node
apt-get install -y kubelet=1.31.1-1.1
systemctl daemon-reload && systemctl restart kubelet
exit

kubectl uncordon node01

Explanation: The key difference is using kubeadm upgrade apply for the control plane and kubeadm upgrade node for the worker. The upgrade order is install kubeadm → upgrade → install kubelet/kubectl → restart kubelet, and draining without --ignore-daemonsets gets blocked by DaemonSet Pods. Version jumps of only one minor at a time are allowed.

Create the ServiceAccount, Role, and RoleBinding.

k -n dev create serviceaccount deployer
k -n dev create role deploy-manager \
  --verb=create,get,list,update,delete \
  --resource=deployments.apps
k -n dev create rolebinding deployer-binding \
  --role=deploy-manager \
  --serviceaccount=dev:deployer

Verify the permissions.

k -n dev auth can-i create deployments --as=system:serviceaccount:dev:deployer
k -n dev auth can-i delete deployments --as=system:serviceaccount:dev:deployer

Explanation: A Role is a namespace-scoped set of permissions, and a RoleBinding connects that Role to a subject (here, the ServiceAccount). If you don’t spell out the API group as in --resource=deployments.apps, it gets captured under the core group and can end up an empty rule. When verifying, the subject must be written in the form system:serviceaccount:<ns>:<name>, and both commands should return yes.

On the control plane node, check the certificate expiry status.

ssh cluster1-controlplane
sudo -i

kubeadm certs check-expiration

To see a specific certificate’s expiry date directly, check it with openssl.

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -enddate

Renew all certificates, then restart the control plane static Pods.

kubeadm certs renew all
systemctl restart kubelet

Explanation: kubeadm certs check-expiration shows the expiry dates of each certificate and kubeconfig in a table. certs renew all only reissues the certificate files, so you must restart the components — apiserver and the other static Pods — to make them read the new certificates and actually take effect. kubeadm auto-renews certificates during a control plane upgrade, so a regular upgrade can double as a renewal.

Since this is a kind whose skeleton you can’t build with dry-run, write the manifest by hand.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
  namespace: apps
spec:
  selector:
    matchLabels:
      app: log-agent
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      containers:
        - name: fluentd
          image: fluent/fluentd:v1.16

k apply -f log-agent.yaml
k -n apps get ds log-agent

Explanation: A DaemonSet places one Pod on each worker node and has no replicas field. The control plane node usually has a node-role.kubernetes.io/control-plane:NoSchedule taint, so without a separate toleration nothing schedules there — which means the requirement that it “does not need to run there” is satisfied by simply not adding a toleration. Unlike a Deployment, the selector and template labels must match.

Add the taint to the node and check that the label is present.

k taint node node01 gpu=true:NoSchedule
k label node node01 disktype=ssd

Create a Pod with a toleration and nodeAffinity.

apiVersion: v1
kind: Pod
metadata:
  name: ml-job
  namespace: apps
spec:
  tolerations:
    - key: gpu
      operator: Equal
      value: "true"
      effect: NoSchedule
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: In
                values:
                  - ssd
  containers:
    - name: ml-job
      image: nginx

k apply -f ml-job.yaml
k -n apps get pod ml-job -o wide

Explanation: A taint is the mechanism by which a node repels Pods, and a toleration is a Pod’s declaration that it will tolerate that taint. With only a toleration the Pod can still land on other nodes, so to pin it to a specific node you must add nodeAffinity or nodeSelector as well. The toleration’s value must be quoted as a string to avoid a "true" boolean-interpretation error.

Define the headless Service and the StatefulSet together.

apiVersion: v1
kind: Service
metadata:
  name: cache
  namespace: data
spec:
  clusterIP: None
  selector:
    app: cache
  ports:
    - port: 6379
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: cache
  namespace: data
spec:
  serviceName: cache
  replicas: 3
  selector:
    matchLabels:
      app: cache
  template:
    metadata:
      labels:
        app: cache
    spec:
      containers:
        - name: redis
          image: redis:7
          ports:
            - containerPort: 6379
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi

k apply -f cache.yaml
k -n data get pods -l app=cache

Explanation: A StatefulSet must be tied to a headless Service (clusterIP: None) via serviceName to grant stable DNS in the form cache-0.cache.data.svc.cluster.local. volumeClaimTemplates automatically creates a separate PVC per Pod, and even when a Pod is recreated it reattaches to the same PVC. Pods being named sequentially from 0 is another difference from a Deployment.

k -n net create deploy web --image=nginx --replicas=2
k -n net expose deploy web --name=web-np --type=NodePort --port=80 --target-port=80

Pin the nodePort value to 30080.

k -n net patch svc web-np --type='json' \
  -p='[{"op":"replace","path":"/spec/ports/0/nodePort","value":30080}]'

Explanation: When you create a NodePort with expose, nodePort is auto-assigned from the 30000〜32767 range, so to pin it to a specific value you either patch it or write nodePort: 30080 directly into the dry-run YAML and apply. Verify with curl <node IP>:30080 to confirm a response.

k -n net create ingress web-ing \
  --class=nginx \
  --rule="web.example.com/*=web-np:80" $do > ing.yaml

The generated manifest looks like this.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ing
  namespace: net
spec:
  ingressClassName: nginx
  rules:
    - host: web.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-np
                port:
                  number: 80

k apply -f ing.yaml

Explanation: The --rule of create ingress takes the form host/path=service:port, and the trailing /* of the path converts to pathType: Prefix. Drop --class=nginx and ingressClassName is left empty, so routing won’t work on a cluster with no default IngressClass. Actual operation requires the ingress-nginx controller, but grading looks at the correctness of the resource definition.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow
  namespace: net
spec:
  podSelector:
    matchLabels:
      app: db
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: api
      ports:
        - protocol: TCP
          port: 5432

k apply -f db-allow.yaml

Explanation: podSelector selects the target Pods the policy applies to (app=db), and ingress.from selects the allowed sources (role=api). Once even one NetworkPolicy applies to a Pod, all traffic not explicitly listed is blocked, so other ingress is shut off without a separate deny-all. Putting from and ports in the same rule makes it an AND of both conditions, and it is enforced only on a policy-capable CNI such as Calico.

Define the PV, PVC, and Pod in order.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-data
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-data
  namespace: storage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pv-user
  namespace: storage
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: pvc-data

k apply -f pv.yaml
k -n storage get pvc pvc-data

Explanation: For a PVC to bind to a PV, the accessModes must match and the PV’s capacity must be greater than or equal to the PVC’s request (2Gi ≥ 1Gi). A PV is a cluster-wide resource so it has no namespace, while the PVC and Pod must live in the same namespace. With reclaimPolicy: Retain, the PV’s data survives even after you delete the PVC, and the PV goes into the Released state.

Define the StorageClass and PVC.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: rancher.io/local-path
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-fast
  namespace: storage
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast
  resources:
    requests:
      storage: 3Gi

k apply -f sc.yaml
k -n storage get pvc pvc-fast

Explanation: WaitForFirstConsumer defers volume creation until a Pod that uses the PVC is scheduled, so a PVC on its own staying in Pending is normal. allowVolumeExpansion: true is required to later grow the PVC’s resources.requests.storage for online expansion. If you don’t specify storageClassName on a PVC, the default StorageClass is used.

First check the node status and conditions.

k get nodes
k describe node node01

Connect to the node and look at the kubelet status and logs.

ssh node01
sudo -i
systemctl status kubelet
journalctl -u kubelet -e

If kubelet is stopped, restart it; if it’s a config error, fix the file the logs point to and then restart.

systemctl enable --now kubelet
systemctl restart kubelet

Explanation: The most common causes of NotReady are that the kubelet service died (systemctl restart kubelet), a kubeconfig/CA path error, or disk/memory pressure. The Conditions in describe node and journalctl -u kubelet pin down the cause, and if kubelet is inactive at boot, enable --now turns on automatic start at boot too. The key is recognizing that this is not a control plane problem but something you must look at on the node itself.

Connect to the control plane node and look at the apiserver container status.

ssh cluster2-controlplane
sudo -i

crictl ps -a | grep kube-apiserver
crictl logs <apiserver-container-id>

Review the static Pod manifest and fix the wrong field (for example, a typo’d port, a wrong certificate path, or broken indentation).

vim /etc/kubernetes/manifests/kube-apiserver.yaml

Wait for kubelet to detect the manifest change and bring the apiserver Pod back up, then verify.

crictl ps | grep kube-apiserver
k get nodes

Explanation: kubectl only works once the apiserver is up, so in this state the key is to read the container logs directly with crictl instead of kubectl. A static Pod is automatically recreated by kubelet when you edit its manifest file, so moving the file out and back briefly produces a forced restart. A typo in the --etcd-servers path or a certificate path is a common cause.

Compare the Service, the endpoints, and the Pod labels.

k -n apps get svc frontend -o wide
k -n apps get endpoints frontend
k -n apps describe svc frontend
k -n apps get pods --show-labels

If the Service’s selector is out of step with the Pods’ labels, fix the selector to match the Pod labels.

k -n apps patch svc frontend \
  -p '{"spec":{"selector":{"app":"frontend"}}}'
k -n apps get endpoints frontend

Explanation: Empty endpoints are a sign that the Service’s selector matches no Pod label. Even when Pods are Running, if the selector is out of step they aren’t registered in the endpoints and traffic can’t reach them. After fixing the selector, verify that get endpoints fills in with Pod IPs, and check for port name/number mismatches at the same time.

Diagnose the state and the termination cause.

k -n apps describe pod report
k -n apps logs report --previous > /tmp/report.log

If Last State is OOMKilled, raise the memory limit. A Pod’s resources can’t be edited in place, so pull the manifest, fix it, and recreate.

k -n apps get pod report -o yaml > report.yaml

    resources:
      limits:
        memory: "256Mi"
      requests:
        memory: "128Mi"

k -n apps delete pod report
k apply -f report.yaml

Explanation: CrashLoopBackOff is a state where the container repeatedly terminates, so the current log may be empty — use --previous (-p) to pull the logs of the container that terminated just before. If the Last State Reason in describe is OOMKilled, an insufficient memory limit is the cause. A running Pod’s resources are immutable, so you must edit the manifest and delete,recreate it, and if the Pod is managed by a Deployment, fix the Deployment’s template instead.