Fix a Kubernetes CrashLoopBackOff
A real kubernetes problem you debug end to end in a live cloud workspace, then show on your portfolio. No tutorial, no toy app - a broken system that behaves like production.
The scenario
A Deployment called web was rolled out to your namespace, but it never comes up -- the pod keeps restarting with CrashLoopBackOff.
The broken code you start with
containers:
- name: app
image: busybox:1.36
command: ["sleeep", "86400"] # typo: 'sleeep' is not a commandWhat this teaches you
What you did: kubectl describe pod exposed the container exit code + events, kubectl logs showed the command failing on a typo. Fixed the Deployment's command: field and re-applied - pod came up Running.
Why it matters: describe + logs solve 90% of pod startup failures. The Events tail at the bottom of describe is where Kubernetes tells you *why* it can't schedule, pull, or start your container - the rest is reading carefully.
In the real world: "Why is this pod CrashLooping?" is the most-asked question in any K8s on-call rotation. The muscle memory of "describe → logs → events" is what makes the difference between solving it in 30 seconds vs. 30 minutes.
What you'll practice
- Reading pod events and container logs with kubectl
- Telling CrashLoopBackOff apart from other pod states
- Correcting a broken container command in a Deployment
Why this impresses a hiring manager
- This is a real kubernetes problem teams hit in production - not a synthetic puzzle.
- It shows you can diagnose and fix a Kubernetes issue in a live system end to end.
- It lands on your portfolio as a scenario a hiring manager can open and click through.
Read the pod's events + logs, found a typo in the container command, and corrected the Deployment so it starts cleanly
Keep going
Build this project free
You're in a real cloud workspace in 30 seconds. Fix it, and it lands on your portfolio.
Start this project →