Focused, hands-on DevOps and server-side problems with hints, feedback, and automated solution checks.
Challenges contributed by the community members sharing their knowledge and expertise.
node-02 is back from a kernel upgrade but still shows Ready,SchedulingDisabled, and the Pods that can only run on it are stuck in Pending. Bring the node back into service and get the workload running, without touching the workload itself.
A storefront needs eight replicas, and the platform team wants them split down the middle between the two availability zones. An uneven split must be refused by the scheduler rather than quietly tolerated.
The storefront APIs are served through a Traefik Ingress with TLS and two path rules. Reproduce that configuration with a Gateway and an HTTPRoute on the same hostname, cut traffic over to it, and retire the Ingress.
A new intern learning about probes wrote a small Pod manifest. The exec command and the application are both correct, but the Pod never becomes Ready because one probe parameter is missing. Find it and add it.
The security team left five NetworkPolicy files on the workstation. Only one of them lets the frontend reach the backend while granting nothing more. Identify it and deploy it, unchanged.
A worker node dropped to NotReady and part of the workload went with it. The container runtime is fine and the control plane is healthy; the trail leads from kubectl symptoms down into systemd and the kubelet configuration. Diagnose the node and bring it back.
Build five ways to combine containers in one Pod: a sidecar that extends the app, an init container that finishes before the app starts, a native sidecar with a startup guarantee, an ambassador that mutates an outbound call, and an adapter that translates an inbound one.
kubectl is dead: the kube-apiserver certificate expired and the control plane is down, while the workload quietly keeps serving. Diagnose the expiry offline, renew the certificates, bring the control plane back, and prove the cluster recovered.
Every kubectl command against a kubeadm cluster fails, and the workload is still serving. With no API to query, the usual tools tell you nothing. Work from the node itself to find what broke and bring the control plane back.
Kubernetes 1.37 can hand every pod its own short-lived X.509 identity, no service mesh and no sidecar involved. The API is served out of the box, but it issues nothing without a signer, and a request nobody answers leaves the pod waiting forever. Get a stalled workload its certificates, give its client an identity of its own, and make the server actually enforce mutual TLS.
