A pod won't start. You run kubectl, get pods, and the status column says crash loop back off. So you describe it, and you need the bottom of the output that was a line. Exit code 137. That number is the whole video. Because 137 isn't a Kubernetes error. It's 128 plus 9. And 9 is S-I-G-K-I-L-L, a Linux signal. Kubernetes didn't tell you what broke. It handed you a Linux fact and walked away. Which is the real question nobody answers properly. What order do you actually have to learn this step in? Every tool in modern infrastructure is a wrapper around the one underneath it. Kubernetes schedules containers. A container is a Linux process but its namespace is fenced off. That process runs on a kernel and a machine inside a network. And a machine is a cloud resource somebody provisioned. While the top layer works, you never see any of that. The moment it fails, you fall straight through to the layer below and you debug there. So the order to learn this in isn't a matter of taste. It's the order you fall through, which puts cloud fundamentals first. Pick one platform, AWS or Azure, and stop there. Not both, not five. The core concepts transfer almost completely between them anyway. Compute, storage, networking, databases, load balancing, virtual networks, identity, security. What you're building is a mental model of where an application actually lives once it leaves your laptop. Your milestone. Deploy one simple application, then explain out loud which services you used, how they connect, and why you chose each one. If you can't explain the why, you click through a tutorial. Then Linux. This is the layer most people skip, and it's exactly by ExitCode 137 stops them cold. The command line, files and permissions, processes, services, networking, package management, logs, troubleshooting. You want to be able to run a machine with no graphical interface at all. Milestone. Connect to the server you just deployed over SSH. Find the application process, read its logs with JournalTel, restart the service, and fix something that's genuinely broken. On your own, with nobody's tutorial open. Every later above this one eventually drops you back here. Once you can operate a Linux box, automate it. Bash is where you stop being someone who runs commands and start being someone who ships procedures. Loops, conditionals, arguments, exit codes, redirecting output. Nothing exotic. Milestone. Take one task you've now done by hand more than twice. Installing dependencies, rotating a log, restarting a service after a deploy. and turn it into a script that runs start to finish and tells you clearly when it fails. That failure handling is the part that separates a script from a note file. Now you have scripts, so they need somewhere to live that isn't your home directory. Get it. And learn it properly. Repositories, Commits, Branches, Merging, Push, Clone, Remotes. Not just the three commands you memorize to get unstuck. Every pipeline you will ever build triggers off a Git event, so this is infrastructure, not paperwork. Milestone, your whole project sits on GitHub. The application code, the Bash scripts, the configuration, and the R-E-A-D-E-E that explains how to run the thing. All of it version controlled in one place. Python comes next and you're not becoming a software engineer. You're learning enough to do what Bash gets ugly at, calling APIs, parsing JSON, handling files, processing data, talking to a cloud SDK. The line is roughly this. When your Bash script grows a second function and starts picking apart structured data, rerun it in Python. Milestone. Automate one real thing in your project with it. Call an API and act on the response. Or create and tag a cloud resourcing code. One real task, not an exercise. No containers. Docker packages your application together with its dependencies so it runs the same way on your laptop with a build server and in production. images, containers, volumes, networking, the lifecycle. And notice what you're already carrying. A container is a Linux process, and a Docker file is mostly the install steps out of your bash script. You're not learning something new here. You're formalizing what you already did by hand. Monostone, Docker build, and Docker run on a machine that isn't yours, and it behaves identically, only now Kubernetes. It deploys, manages, and scales containers across a fleet of machines. pods, deployments, services, the scheduler. Milestone, deploy your container, push a new version and watch the rollout, then scale it up and back down. And there's your Exocode 137 again. Except now, the container crossed the memory limit set in its pod spec, so the code sent S-I-G-K-I-L-L and 128 plus 9 is 137. It was never a Kubernetes problem. It was a Linux signal with a the Kubernetes cause. Everything so far, you built by clicking. Terraform replaces the clicking. You write the virtual network, the machines, the database, and the permissions as code. Run Terraform plan to see exactly what would change. Then Terraform apply to make it real. The plan step is the whole point. Infrastructure you can review before it exists. Milestones. Destroy your environment and rebuild the entire theme from your Terraform files. Anything that's missing is a resource clicked into existence months ago and forgot about. Gotta find it now. Last piece of the foundation, AI. Again, not as a specialization. What a model is, and roughly how it learns. How you reach one over an API. The things, retrieval augmented generation, and what an agent actually is once you strip the marketing off it. Plants using AI in your own daily engineering work, which is table stakes now. Milestone. One small AI capability to your project and be able to say exactly what data goes to the model, what goes back, what it costs you, and what gets things wrong. That's the foundation. Cloud, Linux, Bash, Git, Python, Docker, Kubernetes, Terraform AI. Now the branch. Cloud engineer goes deeper into infrastructure, networking, security and operations. Add Ansible if the roles you're reading ask for it. DevOps engineer adds CI-CD, GitHub actions, Jenkins, GitLab, Argo CD. SRE adds observability, Prometheus, Grafana, Datadog, ELK stack. Platform engineering builds the developer platform itself, with Argo CD backstage and process plane. DevOps points the foundation at security, MLOps points the same skills at models. Look closely at what changed at that branch, though, not the foundation. Only the tools bolted on top of it. Which is the argument for the whole sequence. Build horizontally first, then specialize vertically. Learn the common layer once, and every direction stays open to you. Go vertical too early and you've built a career on a tool with a version number. And on tools, read the job listings in your own market rather than your roadmap written by someone hiring you in a different country. Jenkins and August CD are not equally in demand everywhere. So, plainly, three rules. Don't learn Kubernetes before Linux and containers. Don't touch a CI slash CD tool before Git and automation. Jump in five clouds at once and carry one project the whole way through. The same application, deployed, then scripted, then containerized, then orchestrated, then rebuilt from Terraform. Nine steps, one artifact, something real to show at the end of it. Tools change. GitHub Actions displace Jenkins for a lot of teams. will eventually displace Kubernetes. The order underneath all of it doesn't move, so. Which layer did you skip?
Machine-transcribed from the published render, so acronyms may be cased as ordinary words.