The DevOps Roadmap I Wish Someone Had Handed Me on Day One

I'm a software engineering student, about 16 months out from graduation, and somewhere in the last year "learn DevOps" quietly turned from a side interest into the actual plan — cloud, Kubernetes, Terraform, the whole stack, with an eye on eventually working in Europe. Along the way I built myself a fairly detailed personal roadmap, then went and stress-tested it against what's actually being hired for in 2026: platform engineering, AI-assisted workflows, security-shifted-left pipelines, GitOps.

This post is the result — a general-purpose DevOps roadmap for anyone starting from zero: students, developers pivoting from pure software engineering, sysadmins moving up the stack. It's opinionated on purpose. DevOps has an infinite tool list and an infinite number of YouTube channels willing to walk you through all of it. The actual skill isn't watching those videos — it's building things, breaking them, and fixing them yourself. The rule I hold myself to: for every hour spent reading or watching, spend an equal hour building.

What DevOps Actually Is (and What It Isn't)

DevOps is the practice of collapsing the wall between "people who write code" and "people who run it in production." In practice that means automation, infrastructure you can version and reproduce, pipelines that test and deploy without a human clicking buttons, and enough observability that you know something broke before your users tell you.

It is not a job title that means "the person who knows Docker." By 2026 the field has split into recognizable specializations — DevOps Engineer, Site Reliability Engineer (SRE), Cloud Engineer, Platform Engineer, DevSecOps Engineer — and the fastest-growing one is Platform Engineering: building internal developer platforms so the rest of the engineering org can ship without babysitting infrastructure. Worth knowing before you pick where to specialize.

The Roadmap, Start to Finish

Phase 1 — Foundations (Months 1–3)

Nothing after this phase works if this phase is shaky. Almost every production incident, at its root, is a Linux, networking, or Git problem wearing a fancier costume.

• Linux & Bash. Filesystems, permissions, processes, services, cron, SSH, and enough grep/awk/sed to parse a log file without opening it in an editor. Learn just enough vim to survive on a server with nothing else installed.
• Networking fundamentals. TCP/IP vs UDP, how DNS resolution actually works, the HTTP request/response cycle and status codes, TLS basics, and — critically for cloud work — what a VPC, subnet, and CIDR block are, and the difference between a firewall and a security group.
• Git, properly. Not just add/commit/push. Rebase vs merge and when each is appropriate, branching strategies (GitFlow vs trunk-based), Conventional Commits, and how to review a pull request like you mean it.
• A real scripting language. Python, taken to the point where you can write a CLI tool with argparse, hit an API with requests, and parse JSON/YAML without Googling the syntax every time. If you already know JavaScript, TypeScript basics (types, interfaces, generics) is a two-to-three-week add-on, not a separate project.

Checkpoint: you can write a Bash script from a blank file, build a small Python CLI tool that actually does something, and explain what happens between typing a URL and a page loading.

Phase 2 — Ship Something Real (Months 3–7)

This is where most roadmaps go wrong — people collect certificates and tutorials and never actually deploy anything a stranger uses. Don't do that. Pick a real, small problem, build it, and put it in front of real users.

Stack that won't fight you: a Python (FastAPI) or Node backend, a Postgres database, and a frontend if you need one — deployed to a cloud provider with a real domain and HTTPS, not localhost.

Non-negotiables for this project, from day one, not "later":

• Docker from week one, not week eight. docker-compose up should be the entire onboarding instructions for anyone touching your code.
• CI/CD from week two. GitHub Actions (or GitLab CI) running tests and deploying automatically on every push to main.
• Basic security scanning in the pipeline — Snyk or an equivalent is free for open source and catches embarrassing dependency vulnerabilities before a recruiter does.
• Monitoring, even basic CloudWatch or an uptime check — you should know your service is down before a user has to tell you.
• Deploy ugly, deploy early. A live, embarrassing version by week three beats a polished version that never ships.

Then get 20–30 real users — not installs, actual usage — and write an honest post-mortem about it: what you built, what broke, what you'd do differently. That post-mortem, not a certificate, is what you'll actually talk about in interviews.

Phase 3 — Infrastructure as Code, Kubernetes, and Security Depth (Months 7–12)

This is where you go from "can deploy an app" to "can be trusted with production infrastructure."

• Terraform. Learn it by rebuilding your Phase 2 infrastructure as code — VPC, compute, database, IAM — as reusable modules, with proper state management and a remote backend. The goal is a single terraform apply standing up your whole environment. (Pulumi is a legitimate alternative if you'd rather write infrastructure in a real programming language instead of HCL — worth knowing it exists, even if you go Terraform-first.)
• Kubernetes, to a genuinely solid level — this is no longer optional in 2026, it's closer to a baseline expectation for the field. Start a local cluster with minikube or kind on day one. Every concept you read about, run yourself within 24 hours. This is the most time-expensive part of the whole roadmap; budget real hours for it, and consider the CKA (Certified Kubernetes Administrator) as the structuring goal even if you don't sit the exam immediately.
• GitOps. Learn ArgoCD or Flux — the idea that Git is the single source of truth and changes to the repo trigger cluster changes automatically, rather than someone running kubectl apply from their laptop.
• DevSecOps basics. SAST scanning, container image scanning, secrets management (HashiCorp Vault conceptually is enough to start), and know the OWASP Top 10 cold — it comes up in nearly every security-adjacent interview.
• Observability. Prometheus + Grafana dashboards on top of whatever you've built. "I can see when it's unhealthy" is a very different sentence from "it's probably fine."

Build a second project during this phase that ties it together: Terraform-provisioned dev/staging/prod environments, the app running on managed Kubernetes, GitOps deployment, a pipeline with security scanning and a manual approval gate for production, and dashboards showing real health metrics. Document the architecture decisions in the README like you're explaining them to a hiring manager, because you are.

Start contributing to one open-source project in this space too — a Terraform provider, a Kubernetes operator, a Prometheus exporter. Small docs fixes first, real contributions later. A handful of merged PRs by the time you're job-hunting says more than most certifications.

Phase 4 — Platform Engineering and the Job Hunt (Months 12–18)

By 2026, "Platform Engineer" has become the label for the DevOps specialization most in demand — the difference is building the tools and paved paths that let other developers ship without needing to understand Kubernetes themselves.

A strong capstone here: a small self-service internal developer platform — a portal where a developer can spin up a new microservice (repo, CI/CD pipeline, Kubernetes namespace, the works) from a template in a few minutes. Look at Backstage.io for reference architecture. A junior engineer with a working demo of this is genuinely rare, and it's a very good interview conversation starter.

On the job-hunting side:

• Target titles, roughly in this priority order: Junior DevOps Engineer → Associate Cloud Engineer → Infrastructure/Operations Engineer with confirmed Kubernetes/Terraform in the description. Be wary of generic "Junior Software Engineer" postings unless cloud/infra work is explicit — the title is doing a lot of hiding.
• Certifications, in order of return on time invested: AWS Solutions Architect Associate first (broadly recognized, forces you to actually learn cloud architecture), Terraform Associate (cheap, quick, worth it), CKA once you have income to justify the exam fee.
• Ask this question before accepting any offer: "Will I actually be working with Kubernetes in production, managing infrastructure with Terraform, and building CI/CD pipelines here?" If the honest answer is no, keep looking — the first job sets the trajectory for everything after it.

The Part Nobody Puts in the Tool List: AI-Assisted Workflows

One real shift going into 2026 worth naming directly: AI is now a normal part of the DevOps toolbox, not a novelty. Engineers who use it well move faster — generating boilerplate Terraform, summarizing incident logs, drafting runbooks — but hiring managers are explicitly looking for people who understand why an infrastructure change is being made, not just people who can prompt a tool into producing a working pipeline. Use AI as a force multiplier on top of real understanding, not a substitute for it. The interview question is never "did AI write this" — it's "can you explain what this does and why it's built this way."

Things That Don't Change, No Matter the Year

• Tools rotate. Fundamentals compound. Linux, networking, and "how does a system fail" outlast every specific tool you'll learn on top of them.
• A live project with real users beats a stack of certificates, every time, in every interview I've read about or heard about.
• Write about what you build. A short, honest technical post — what broke, how you fixed it, what you'd change — is worth more than a polished tutorial, because it's the one thing a tutorial-follower can't fake.
• Don't collect tools. Build with them. If you finish a course on something and haven't built anything with it within a week, the course didn't work.

Realistic Timeline

Roughly a year and a half of consistent, unglamorous work — an hour or two most evenings, more on weekends — gets you from zero to genuinely employable in this field. It's not a race and it's not linear; some phases will take longer than others depending on what you're starting with. The only variable that actually matters is whether you keep the "one hour building for every hour watching" rule intact the whole way through.

If you're just starting out: pick one thing from Phase 1, ignore everything else on this list for now, and go build something with it today.