Focused, hands-on problems for sharpening your DevOps and server-side skills. Some teach specific concepts while others mirror real-world scenarios. Every challenge includes hints, feedback, and automated solution checks.
Learn how to configure a Kubernetes CronJob to automatically take etcd snapshot backups every 6 hours — a critical skill for cluster disaster recovery and operational health.
Learn how to reconfigure the Kubernetes cluster DNS domain by updating CoreDNS ConfigMap and kubelet configuration on all nodes, a critical skill for custom cluster networking and CKA exam preparation.
The production "Calendar Todo" web application has been deployed in the prod namespace but all pods are stuck in Pending. Investigate the cluster, identify why the application cannot run, fix the underlying node issue, and verify the app is serving traffic on NodePort 31777.
Practice real-world disaster recovery — restore a deleted production workload by restoring an etcd snapshot and reconfiguring the etcd static pod to use the recovered data directory.
Harden a bastion host so only admins can get a shell on it, operators can open tunnels to arbitrary destinations, and developers can reach only the one internal service they actually need.
A web application is deployed but the website is not accessible. Investigate and fix the issue.
Make sure the Klustered deployment is running and that you can browse to it and see the counter increase with each refresh.
Configure the kube-scheduler static pod with CPU resource requests based on node allocatable, and disable the NodePort access to the Kubernetes API server so it is only reachable via ClusterIP.
Sometimes an image needs to be removed from a registry - because it was pushed by mistake, contains sensitive data, or simply should no longer be available. Practice purging a container image properly: remove the tag, trace it to the manifest and blobs behind it, and make sure the image can no longer be pulled - even by digest.
An internal service is halfway through a Python-to-Go rewrite: the amd64 build already runs the new Go code while arm64 still ships the legacy Python one - same API, two completely different codebases and Dockerfiles. Can you build and push a single multi-platform image from the two independent single-platform variants?
