CKA Practice Questions 2026: 15 Realistic Scenarios + Answers

Scenario

The control-plane node is k8s-master. The etcd TLS assets are at /etc/kubernetes/pki/etcd/. Take a snapshot of the etcd database and save it to /opt/backup/etcd-snapshot.db.

Answer

SSH to the control-plane node, then run:

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

Verify: ETCDCTL_API=3 etcdctl snapshot status /opt/backup/etcd-snapshot.db --write-out=table. The output must show a non-zero Revision. The three TLS flags (--cacert, --cert, --key) are mandatory — omitting any one produces a connection refused error that costs full task marks.

Scenario

Restore the etcd snapshot at /opt/backup/etcd-snapshot.db to the directory /var/lib/etcd-restore. Then update the etcd static pod manifest to use the new data directory.

Answer

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

Then edit /etc/kubernetes/manifests/etcd.yaml. Find the --data-dir flag under spec.containers[0].command and the hostPath volume mount, changing both from /var/lib/etcd to /var/lib/etcd-restore. The kubelet watches the manifests directory and will restart the etcd pod automatically. Confirm with k get pods -n kube-system once etcd is Running again.

Scenario

In namespace dev, create a ServiceAccount named ci-runner. Create a Role named pod-reader that allows get, list, and watch on pods. Bind it to ci-runner via a RoleBinding named ci-runner-binding.

Answer

k create sa ci-runner -n dev
k create role pod-reader -n dev --verb=get,list,watch --resource=pods
k create rolebinding ci-runner-binding -n dev --role=pod-reader --serviceaccount=dev:ci-runner

Verify: k auth can-i list pods -n dev --as=system:serviceaccount:dev:ci-runner must print yes. The subject in the RoleBinding must use the namespace:serviceaccount-name form — the most common exam mistake is omitting the namespace prefix.

Scenario

The cluster is running Kubernetes v1.29. Upgrade the control-plane node to v1.30 using kubeadm, then drain the control-plane, upgrade kubelet and kubectl, and uncordon the node.

Answer

On the control-plane node:

apt-mark unhold kubeadm && apt-get install -y kubeadm=1.30.0-00 && apt-mark hold kubeadm
kubeadm upgrade plan
kubeadm upgrade apply v1.30.0
kubectl drain k8s-master --ignore-daemonsets --delete-emptydir-data
apt-mark unhold kubelet kubectl && apt-get install -y kubelet=1.30.0-00 kubectl=1.30.0-00 && apt-mark hold kubelet kubectl
systemctl daemon-reload && systemctl restart kubelet
kubectl uncordon k8s-master

Verify: k get nodes should show v1.30.x for the control-plane. Only upgrade one minor version at a time — skipping versions is not supported.

Scenario

Node node02 has the taint env=prod:NoSchedule. Create a Deployment named prod-web in namespace production running image nginx:1.25 with 2 replicas. The pods must schedule on node02.

Answer

k create deploy prod-web --image=nginx:1.25 --replicas=2 -n production $do > deploy.yaml

Add under spec.template.spec:

tolerations:
- key: "env"
operator: "Equal"
value: "prod"
effect: "NoSchedule"
nodeSelector:
kubernetes.io/hostname: node02

k apply -f deploy.yaml

Verify: k get po -n production -o wide — all pods should show node02 in the NODE column. Using operator: "Exists" instead of "Equal" with a value is a common YAML mistake that causes the toleration to silently fail.

Scenario

Deployment frontend in namespace default is running nginx:1.24. Update it to nginx:1.25-broken (an image that will fail). After confirming the rollout is degraded, roll it back to the previous version.

Answer

k set image deploy/frontend nginx=nginx:1.25-broken
k rollout status deploy/frontend # watch for degraded message
k rollout undo deploy/frontend
k rollout status deploy/frontend # confirm "successfully rolled out"

Verify: k describe deploy frontend | grep Image must show nginx:1.24. If you need to roll back to a specific revision: k rollout undo deploy/frontend --to-revision=1 (check history first with k rollout history deploy/frontend).

Scenario

Create a ConfigMap named app-config in namespace default with key APP_ENV=production. Create a Pod named app-pod using image busybox:1.36 that runs sleep 3600 and exposes APP_ENV as an environment variable sourced from the ConfigMap.

Answer

k create cm app-config --from-literal=APP_ENV=production
k run app-pod --image=busybox:1.36 --command -- sleep 3600 $do > pod.yaml

Add to spec.containers[0] in pod.yaml:

env:
- name: APP_ENV
valueFrom:
configMapKeyRef:
name: app-config
key: APP_ENV

k apply -f pod.yaml

Verify: k exec app-pod -- env | grep APP_ENV must print APP_ENV=production.

Scenario

Deployment web in namespace default exposes port 80. Create a NodePort Service named web-svc that maps port 80 on the Service to port 80 on the pods and exposes it as NodePort 30080.

Answer

k expose deploy web --name=web-svc --port=80 --target-port=80 --type=NodePort $do > svc.yaml

In svc.yaml, under spec.ports[0] add nodePort: 30080, then:

k apply -f svc.yaml

Verify: k get svc web-svc must show 80:30080/TCP. Test with curl <node-ip>:30080 from outside the cluster. NodePort range is 30000-32767; specifying a port outside that range causes validation failure.

Scenario

In namespace restricted, create a NetworkPolicy named default-deny-ingress that blocks all ingress traffic to every pod. Then create a second NetworkPolicy named allow-frontend that allows ingress to pods labelled app=backend only from pods labelled app=frontend on port 8080.

Answer

Create netpol.yaml:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: restricted
spec:
podSelector: {}
policyTypes: [Ingress]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend
namespace: restricted
spec:
podSelector:
matchLabels:
app: backend
policyTypes: [Ingress]
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080

k apply -f netpol.yaml

Verify: k get netpol -n restricted should list both policies. An empty podSelector: {} selects all pods in the namespace — the correct syntax for a blanket deny. Putting from: [] (empty list) instead of omitting from entirely means "allow from nothing" but is not the canonical default-deny form; use the policyTypes-only pattern.

Scenario

Services api-svc (port 8080) and web-svc (port 80) exist in namespace default. Create an Ingress named app-ingress that routes /api to api-svc:8080 and / to web-svc:80 using pathType: Prefix.

Answer

Create ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-svc
port:
number: 8080
- path: /
pathType: Prefix
backend:
service:
name: web-svc
port:
number: 80

k apply -f ingress.yaml

Verify: k describe ingress app-ingress must show both path rules and an ADDRESS assigned. If the nginx Ingress controller is not installed, the ADDRESS will remain empty — install it with k apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml if permitted by the task.

Scenario

Create a PersistentVolume named pv-logs with 500Mi capacity, accessModes: ReadWriteOnce, hostPath: /mnt/logs, and storageClassName: manual. Then create a PersistentVolumeClaim named pvc-logs in namespace default requesting 200Mi with the same storage class and access mode.

Answer

Create storage.yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-logs
spec:
capacity:
storage: 500Mi
accessModes: [ReadWriteOnce]
storageClassName: manual
hostPath:
path: /mnt/logs
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-logs
namespace: default
spec:
accessModes: [ReadWriteOnce]
storageClassName: manual
resources:
requests:
storage: 200Mi

k apply -f storage.yaml

Verify: k get pv,pvc — PVC must show Bound status. If it stays Pending, the storageClassName or accessMode does not match the PV — the most common mistake.

Scenario

Create a Pod named logger in namespace default using image busybox:1.36 that runs sleep 3600. Mount the PVC pvc-logs at /var/log/app inside the container.

Answer

Create logger-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
name: logger
spec:
containers:
- name: logger
image: busybox:1.36
command: ["sleep","3600"]
volumeMounts:
- name: logs-vol
mountPath: /var/log/app
volumes:
- name: logs-vol
persistentVolumeClaim:
claimName: pvc-logs

k apply -f logger-pod.yaml

Verify: k exec logger -- df -h /var/log/app should show a mounted filesystem. The volumes[].name must exactly match volumeMounts[].name — a typo here causes the pod to stay Pending.

Scenario

Pod broken-app in namespace staging is in CrashLoopBackOff. Identify why it is crashing and fix it. The pod should run image nginx:1.25 and remain Running.

Answer

Start with: k describe po broken-app -n staging — check State, Last State, and Events. Then: k logs broken-app -n staging --previous to see the exit message.

Common root causes and fixes:

• Wrong image tag: edit the pod spec (k edit po broken-app -n staging) and correct the image. Note: you may need to delete and recreate if the pod is not managed by a Deployment.
• Bad command / args: locate the command or args field causing the non-zero exit and correct it.
• Missing ConfigMap / Secret: k describe po Events will say Error: configmap "x" not found. Create the missing resource.
• Resource limits too low: OOMKilled exit code 137. Increase resources.limits.memory.

Verify: k get po broken-app -n staging must show Running with RESTARTS not incrementing.

Scenario

Node node03 shows NotReady in kubectl get nodes. SSH to node03 and restore it to Ready without rebooting the node.

Answer

On node03:

systemctl status kubelet # check if kubelet is running
journalctl -u kubelet -n 50 --no-pager # read recent errors
systemctl start kubelet # if stopped
systemctl enable kubelet # ensure it restarts on reboot

Common causes visible in journalctl:

• kubeconfig path wrong: look for failed to load Kubelet config file. Check /var/lib/kubelet/config.yaml exists and is valid.
• Container runtime down: systemctl status containerd. If stopped: systemctl start containerd.
• CNI plugin missing: log shows network plugin not ready. Apply the correct CNI manifest.
• Certificate expired: log shows x509: certificate has expired. Renew with kubeadm certs renew all on the control plane.

Verify from the control plane: k get nodes must show node03 Ready within ~60 seconds of fixing kubelet.

Scenario

Service payment-svc in namespace default is not routing traffic to its pods. The pods are Running. Diagnose and fix the connectivity issue.

Answer

Systematic diagnosis:

k get svc payment-svc -o yaml # check selector and port
k get po -l app=payment -o wide # check pod labels and IPs
k get endpoints payment-svc # if Endpoints is <none>, selector mismatch

If Endpoints shows <none>: the Service selector does not match the pod labels. Fix options:

• Edit the Service selector: k edit svc payment-svc → update spec.selector to match the pod labels exactly.
• Or add/correct the label on the pods: k label po <pod-name> app=payment.

If Endpoints is populated but traffic still fails:

k run test --rm -it --image=nicolaka/netshoot --restart=Never -- curl payment-svc:<port>

Check targetPort matches the container port. Check NetworkPolicy is not blocking the traffic. Use k exec -it <pod> -- netstat -tlnp to confirm the app is listening on the expected port.

Verify: k get endpoints payment-svc must show at least one IP:port pair. The test pod curl must return an HTTP response.