Why You Still Need to Know Linux to Survive in DevOps
Apr 12, 2026
Here’s the thing—five years back, I totally bought into that myth. I really did. Fresh off my RHCE cert, I landed this mid-sized enterprise gig in the Netherlands, thinking my Terraform and EKS skills meant Linux was ancient history. “Who needs to grub around in /proc anyway?” I figured. Then bam, during a weekend deploy—because of course it was a weekend—our Kubernetes cluster just tanked. I mean, pods were restarting like crazy because some process was hogging absolutely all the memory on the nodes. I was SSH’d in for a solid 12 hours. Just glued to my terminal, running top and ps aux over and over, finally pinning it down to a rogue Java heap dump that had eaten the filesystem. No fancy GUI dashboard or managed cloud console was gonna save me there. Man, that was a painful lesson.
Look, I’ve been grinding in tech for 14 years now—as a DevOps Engineer, SRE, even Systems Admin at startups, agencies, and big corps. Snagged my CKA and AWS Solutions Architect certs along the way. But let me tell you, nothing beats hands-on Linux when everything goes sideways. Sure, tools like Terraform provision your infra nice and clean, but when those EKS nodes start acting up? You’re knee-deep in Linux processes, memory, filesystems, permissions, and networking. That’s not some nice-to-have; it’s the raw execution layer everything else depends on.
Cloud VMs? Pure Linux. Containers? All powered by Linux kernel wizardry like cgroups and namespaces. I’m honestly not sure when we all decided to pretend the OS vanished into thin air, but even when you think you’re floating in some abstracted cloud paradise, you’re still wrestling with the exact same underlying system that’s been chugging along for decades.
I remember this one time I straight-up rescued a RHEL box after I fat-fingered rm -rf on the kernel file—poof, /boot/vmlinuz-3.10.0-957.el7.x86_64 was completely gone. Booted into rescue mode, chrooted right in, pulled a backup kernel from the repo with yum --disablerepo=* install kernel, then regenerated grub.cfg. Had the whole system back up in under an hour. Good luck pulling off that kind of save with some “managed” black-box service.
The reality is, folks trash-talk SELinux like it’s overkill, even in high-sec setups. I used to think that too—disabled it on a prod cluster once, figuring the audits were just noise. Got burned hard last month while messing with Vagrant boxes on VirtualBox (pro tip, by the way: always set ‘em to 2048MB RAM and 2 CPUs, or they’ll crawl like molasses). If you’re looking to set up a proper practice environment to avoid these kinds of gotchas, I’ve covered How to Build a Zero-Cost RHEL 10 Practice Lab Using VirtualBox separately. Turns out, SELinux actually caught a sneaky permission exploit I totally missed. Honestly, I think it gets way too much hate; it’s not nearly as brutal as the forums make it sound once you get the hang of it.
Yeah, containers and IaC make life sweet, but what happens when your CI runner’s OOM-killing everything? Or a pod refuses to mount because of apparmor? You drop straight to strace, journalctl -u kubelet, and sort it out the old-fashioned way. Even Vagrant for local testing? Still spinning up Linux VMs under the hood. And don’t get me started on “serverless”—peek underneath, and yep, still Linux running the whole show.
I know this is a bit of a tangent, but speaking of under-the-hood stuff, remember that time I wasn’t sure if cross-architecture builds needed qemu? Turns out the Linux kernel handles it natively, but only if your distro’s configured right—this stuff won’t fly if you’re stuck on some ancient Debian. This relates to something I covered in 5 Common Linux Installation Mistakes and How to Avoid Them, where outdated distros can really trip you up. Anyway, back to the point.
Edge case alert: if you’re all-in on Windows WSL2, you might slide by a little longer without learning the hard way. But me? I’m still not 100% convinced I’d
📚 Go from reader to practitioner
Reading about it is one thing. Actually doing it — with guided labs and a structured curriculum — is another. That’s exactly what RHCSA Bootcamp (RHEL 10) - Arabic gives you.
