I'm going to start a new set of practice quesions, found on Youtube. Credit for these questions go to the author of youtube. Note that I had not yet taken exam at this stage, I have no ideas if the questions below will be different or similar. However, it's still useful to practice solving the chanlleges, and it's fun!
Take a backup of the etcd cluster and save it to /opt/etcd-backup.db.
TIP: Use official doc, and search for etcd. There's a section called "Backing up an etcd cluster".
Sample code from the doc:
ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
member list
Instruction from the doc for backing up etcd:
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
snapshot save <backup-file-location>
The final command:
ETCDCTL_API=3 etcdctl --endpoints 127.0.0.1:2379 \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
snapshot save /opt/etcd-backup.db
Sample output:
# ETCDCTL_API=3 etcdctl --endpoints 127.0.0.1:2379 \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
snapshot save /opt/etcd-backup.db
{"level":"warn","ts":"2026-09-13T22:38:03.835748+1000","caller":"flags/flag.go:94","msg":"unrecognized environment variable","environment-variable":"ETCDCTL_API=3"}
{"level":"info","ts":"2026-09-13T22:38:03.836907+1000","caller":"snapshot/v3_snapshot.go:83","msg":"created temporary db file","path":"/opt/etcd-backup.db.part"}
{"level":"info","ts":"2026-09-13T22:38:03.847190+1000","logger":"client","caller":"v3/maintenance.go:236","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":"2026-09-13T22:38:03.855561+1000","caller":"snapshot/v3_snapshot.go:96","msg":"fetching snapshot","endpoint":"127.0.0.1:2379"}
{"level":"info","ts":"2026-09-13T22:38:04.161495+1000","logger":"client","caller":"v3/maintenance.go:302","msg":"completed snapshot read; closing"}
{"level":"info","ts":"2026-09-13T22:38:04.206962+1000","caller":"snapshot/v3_snapshot.go:111","msg":"fetched snapshot","endpoint":"127.0.0.1:2379","size":"19 MB","took":"369.91501ms","etcd-version":"3.6.0"}
{"level":"info","ts":"2026-09-13T22:38:04.208718+1000","caller":"snapshot/v3_snapshot.go:121","msg":"saved","path":"/opt/etcd-backup.db"}
Snapshot saved at /opt/etcd-backup.db
Server version 3.6.0
As etcd usually runs as a static Pod, we can check the manifest of the etcd Pod to get those required valus --cert, --key, --cacert.
# grep -E 'cert|key|ca' etcd.yaml
- --cert-file=/etc/kubernetes/pki/etcd/server.crt
- --client-cert-auth=true
- --key-file=/etc/kubernetes/pki/etcd/server.key
- --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
- --peer-client-cert-auth=true
- --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
- --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
name: etcd-certs
priorityClassName: system-node-critical
name: etcd-certs
Create a new deploymement called nginx-deployment, with image nginx:1.30 and 2 replicas. Next upgrade the deployment to version 1.31 using rolling update. (record it)
$ kubectl create deploy nginx-deployment --image=nginx:1.30 --replicas=2
deployment.apps/nginx-deployment created
$ k get deploy nginx-deployment -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
nginx-deployment 2/2 2 2 29s nginx nginx:1.30 app=nginx-deployment
To upgrade the deployment to newer image, and record it (annotate the CHANGE-CAUSE), we can use the following command.
$ kubectl set image deploy nginx-deployment nginx=nginx:1.31 --record
Flag --record has been deprecated, --record will be removed in the future
deployment.apps/nginx-deployment image updated
Verify the result:
$ k rollout history deployment nginx-deployment
deployment.apps/nginx-deployment
REVISION CHANGE-CAUSE
1 <none>
2 kubectl set image deploy nginx-deployment nginx=nginx:1.31 --record=true
$ kubectl get deployment nginx-deployment -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
nginx-deployment 2/2 2 2 4m49s nginx nginx:1.31 app=nginx-deployment
k delete deploy/nginx-deployment
Create a static pod named static-pod on the ckaworker1 noed that uses the busybox image and the command sleep 2000.
First, create a Pod manifest:
$ k run static-pod --image=busybox --dry-run=client -o yaml --command -- sleep 2000
apiVersion: v1
kind: Pod
metadata:
labels:
run: static-pod
name: static-pod
spec:
containers:
- command:
- sleep
- "2000"
image: busybox
name: static-pod
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
Drop the manifest to /etc/kubernetes/manifests on ckaworker1.
[root@ckaworker1 manifests]# pwd
/etc/kubernetes/manifests
[root@ckaworker1 manifests]# cat static-pod.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
run: static-pod
name: static-pod
spec:
containers:
- command:
- sleep
- "2000"
image: busybox
name: static-pod
Verify the result:
$ k get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
static-pod-ckaworker1 1/1 Running 0 65s 172.16.237.236 ckaworker1 <none> <none>
[root@ckaworker1 ~]# rm -f /etc/kubernetes/manifests/static-pod.yaml
Create a new Pod called super-pod with image busybox:1.28. Allow the Pod to be able to set SYS_TIME.
The container should sleep for 4800 seconds.
TIP: Search for capabilities or sys_time, in this case, in the official doc. Look for sample YAML file.
Samle YAML from the official doc:
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo-4
spec:
containers:
- name: sec-ctx-4
image: gcr.io/google-samples/hello-app:2.0
securityContext:
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
That looks like what we're looking for!
cat << EOF > super-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: super-pod
spec:
containers:
- name: busybox
image: busybox:1.28
command: ["sleep", "4800"]
securityContext:
capabilities:
add: ["SYS_TIME"]
EOF
kubectl apply -f super-pod.yaml
Verify the outcome:
$ k get pod
NAME READY STATUS RESTARTS AGE
super-pod 1/1 Running 0 3s
$ kubectl exec -it super-pod -- sh
/ # ps
PID USER TIME COMMAND
1 root 0:00 sleep 4800
17 root 0:00 sh
23 root 0:00 ps
/ # grep 25 /proc/1/status
CapPrm: 00000000aa0425fb
CapEff: 00000000aa0425fb
CapBnd: 00000000aa0425fb
k delete pod super-pod
Create an nginx pod called nginx-resolver using image nginx, expose it internally with a service called nginx-resolver-service. Test that you are able to look up the service and pod names from within a cluster. Ues the image busybox:1.28 for dns lookup. Record results in nginx.svc and nginx.pod.
$ kubectl create deploy nginx-resolver --image=nginx
deployment.apps/nginx-resolver created
$ k get deploy nginx-resolver
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-resolver 1/1 1 1 17s
$ kubectl expose deployment nginx-resolver --name nginx-resolver-service --port=80
service/nginx-resolver-service exposed
$ kubectl get svc nginx-resolver-service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-resolver-service ClusterIP 10.110.124.3 <none> 80/TCP 18s
Create a pod to test the dns lookups:
$ kubectl run dns-lookup --image=busybox:1.28 --command -- sleep 2000
k exec -it dns-lookup -- nslookup nginx-resolver-service
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
Name: nginx-resolver-service
Address 1: 10.110.124.3 nginx-resolver-service.default.svc.cluster.local
[kenno@ckacontrol ~]$ k exec -it dns-lookup -- nslookup nginx-resolver-service.default.svc.cluster.local
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
Name: nginx-resolver-service.default.svc.cluster.local
Address 1: 10.110.124.3 nginx-resolver-service.default.svc.cluster.local
$ k get pods nginx-resolver-7c6f4d98bc-n5kxf -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-resolver-7c6f4d98bc-n5kxf 1/1 Running 0 21m 172.16.116.20 ckaworker2 <none> <none>
$ k exec -it dns-lookup -- nslookup 172.16.116.20
Server: 10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
Name: 172.16.116.20
Address 1: 172.16.116.20 172-16-116-20.nginx-resolver-service.default.svc.cluster.local
Let's save the required dns results:
$ k exec -it dns-lookup -- nslookup 172.16.116.20 > ngix.pod
$ k exec -it dns-lookup -- nslookup nginx-resolver-service.default.svc.cluster.local > nginx.svc
k delete pod dns-lookup
k delete deploy nginx-resolver
k delete svc nginx-resolver-service
$ kubectl get service echoserver
$ kubectl run tmp --image=busybox --restart=Never -it --rm -- wget echoserver:8080
$ kubectl get endpoints echoserver
If the ENDPOINTS shows <none>, it indicates issues with connection to Pods.
Value needs to expose targeted IP address and ports of Pods.
Does any networke policy block ingress traffic to Pod?
$ kubectl get network policies
The Pod or container may have a runtime issue.