I once watched a developer breeze through three Docker courses and then freeze solid the first time a real container crashed. Tutorials teach commands. Incidents teach engineers.
Every DevOps roadmap I found when I started was either a 200-node skill tree with no order, or a funnel into a $400 course. So I spent the last few months building the thing I actually needed — a day-by-day, 90-day path from "I write application code" to "I can deploy, debug, and un-break infrastructure" — and the entire plan is in this post. You don't need to click a single link to use it.
Why this order, and why 90 days
Most roadmaps fail for one of two reasons: they present everything at once (so you bounce between Kubernetes videos and bash tutorials with no thread), or they teach tools in the wrong order (Kubernetes before Linux is how you end up copy-pasting kubectl commands you can't debug).
The ordering rule I settled on: every layer must let you debug the layer above it.
- Kubernetes problems are usually container problems.
- Container problems are usually Linux problems.
- Cloud networking problems are usually DNS-and-ports problems you can learn on localhost.
So: Linux first, containers second, cloud third, orchestration fourth, job prep last. 45–60 minutes a day, about 80 hours of core work total. That's a real commitment — I won't pretend it's "10 minutes a day" — but it's doable alongside a full-time job, and 90 days is short enough that you can see the end from the start.
Phase 1 — Linux & the terminal (Days 1–21)
Three weeks feels like a lot for Linux when Kubernetes is the shiny thing. It isn't. Roughly every DevOps incident ends with someone SSH'd into a box reading logs, and this phase is where you stop being scared of that.
What you cover: navigation, files, permissions, processes, systemd, logs, networking basics (DNS, ports, ss, curl), bash scripting, cron, SSH, users.
The test of whether Phase 1 worked isn't "can you list flags for ls". It's whether this sequence feels natural:
$ systemctl status nginx
● nginx.service - A high performance web server
Active: failed (Result: exit-code) since Tue 09:41:02 UTC
$ journalctl -u nginx -n 20 --no-pager
nginx[1247]: bind() to 0.0.0.0:80 failed (98: Address already in use)
$ sudo ss -ltnp | grep :80
LISTEN 0 511 0.0.0.0:80 users:(("apache2",pid=1201,fd=4))
Read the status, read the log, find the actual error string, find the process squatting on the port. That loop — observe, read the real error, trace it down one layer — is the whole job. Everything after Phase 1 is that loop with more expensive tools.
Everything here runs locally on WSL2 or any Linux box. Cost: $0.
Phase 2 — Docker & CI/CD with GitHub Actions (Days 22–45)
Two skills, deliberately paired: packaging software (Docker) and shipping it automatically (GitHub Actions). Learning one without the other leaves you either building images by hand forever, or writing pipelines you can't debug.
Docker side: images vs containers, Dockerfiles, layers and caching, volumes, networks, compose. CI side: real Git workflows, then pipelines that lint, test, build, and push an image on every commit.
This phase ends with Project 1: containerize a real app — a FastAPI URL shortener called linkstash — with Docker and compose, database included:
$ docker compose up -d --build
[+] Building 42.3s (11/11) FINISHED
✔ Container linkstash-db-1 Healthy
✔ Container linkstash-api-1 Started
$ curl -s localhost:8000/healthz
{"status":"ok"}
That healthz line matters more than it looks. From here on, you carry this exact app up the rest of the stack — which I'll come back to.
Still 100% local. Still $0.
Phase 3 — AWS (Days 46–65)
IAM, EC2, VPC networking, S3, RDS, load balancers, observability, and then real deployment. The order inside the phase matters too: IAM and VPC first, because 80% of AWS confusion is "why can't this thing talk to that thing", and the answer is almost always a security group or a subnet route.
Project 2: take the same linkstash container from Phase 2 and deploy it properly — ECS Fargate behind an ALB, RDS Postgres, spread across two availability zones. Not a toy deploy; the architecture a small company would actually run.
Honest tradeoff: this is the phase that can cost money. The approach I take: every AWS lab carries a cost box up front and a mandatory teardown at the end. Follow the teardowns and you stay in free tier. Skip them and AWS will remind you why one of the week-7 incident drills is literally called "AWS Bill Shock".
Phase 4 — Kubernetes & Terraform (Days 66–85)
Pods, deployments, services, config, probes, ingress, Helm — practiced on local clusters first (kind), so mistakes are free. Then Terraform, so you stop clicking around consoles and start writing infrastructure that's reviewable and repeatable.
Project 3 is the capstone: linkstash again, now on Kubernetes — k3s on a single EC2 instance, provisioned entirely by Terraform, packaged as a Helm chart, with Traefik ingress and cert-manager doing real TLS.
Why k3s on one t3.small instead of EKS? Money. EKS charges ~$73/month for the control plane before you run a single pod. The k3s setup is ~$19/month if you leave it up — effectively $0 on free tier with same-day teardown. You learn the same Kubernetes; you just don't pay AWS to hold the API server. The tradeoff: you won't touch EKS-specific glue (IRSA, managed node groups) — that's fine to learn on the job.
Phase 5 — Job-Ready (Days 86–90)
The last five days are the part every roadmap skips: converting skills into a hire. Resume rewritten around the three projects (deployments and architecture decisions, not "familiar with Docker"), portfolio and GitHub polish, incident management fundamentals (severity levels, blameless postmortems, error budgets), and interview drilling on the exact Q&A you've been collecting — every single day of the program ends with 3–5 interview questions, so by day 86 you've already answered 300+.
The day-by-day skeleton
| Days | Focus | Incident drill at the end |
|---|---|---|
| 1–7 | Terminal fluency: files, permissions, pipes | Server Down! |
| 8–14 | Processes, systemd, logs, DNS & ports | DNS Detective |
| 15–21 | Bash, cron, SSH, users | Locked File |
| 22–28 | Docker: images, containers, Dockerfiles | Docker Rescue |
| 29–35 | Compose, volumes, networks, registries | — |
| 36–40 | Git workflows → GitHub Actions CI | Broken Pipeline |
| 41–45 | Project 1: containerize linkstash | — |
| 46–49 | AWS: IAM, EC2, cost hygiene | AWS Bill Shock |
| 50–56 | VPC, S3, RDS, backups | Database Recovery |
| 57–61 | Load balancers, Route 53, monitoring | — |
| 62–65 | Project 2: linkstash on AWS (Fargate + ALB + RDS) | — |
| 66–73 | Kubernetes: pods, services, config, probes, debugging | Kubernetes Chaos |
| 74–80 | Ingress, Helm, Terraform | Terraform Trouble |
| 81–85 | Project 3: linkstash on k3s, all Terraform | — |
| 86–90 | Resume, portfolio, incidents, interview drill | The Midnight Outage |
Print that table. That's the roadmap.
One app, carried up the whole stack
The best design decision in the whole plan — and you can steal it even if you ignore everything else: don't build three throwaway projects. Build one app and carry it up the stack.
linkstash gets containerized in Phase 2, deployed to AWS in Phase 3, and orchestrated on Kubernetes in Phase 4. In interviews, that turns "I did some tutorials" into "here's one system I've run three ways, and here's why each layer exists." The compare-and-contrast is the story interviewers actually want.
The part nobody puts in roadmaps: incidents
Reading about journalctl and using it at 00:14 during an outage are different skills. Nobody gets paged because everything is working — ops is a job you do almost entirely on the failure path.
So the plan ends every week with an incident drill (that right-hand column in the table): a downed server, a DNS mystery, a broken pipeline, a surprise AWS bill, crashing pods. The final boss is "The Midnight Outage" — a SEV-1 where one security-group change cascades into DNS failover and pods that can't start, and you have to fix it upstream-first: aws → kubectl → dig, instead of restarting pods that were never the problem.
Whether or not you follow my plan, steal the diagnostic walk order:
| Layer | Question to ask | Command |
|---|---|---|
| DNS / edge | Where is traffic actually going? | dig +short <domain> |
| Load balancer | Are targets healthy? | aws elbv2 describe-target-health |
| Network | Did rules change recently? | aws ec2 describe-security-groups |
| Orchestrator | What state are the workloads in? |
kubectl get pods / describe
|
| App | What does the process itself say? | kubectl logs |
And to practice it today, break something yourself: chmod 000 a config your service reads, delete the Secret a deployment references, revoke a rule on a test security group, point a DNS record at nothing. Timer on, docs closed, fix it.
Honest tradeoffs
- 90 days makes you hireable-junior, not senior. You'll be dangerous enough to contribute and debug; depth comes on the job.
- Self-paced means no accountability partner. A visible streak helps; it doesn't replace discipline.
- It's opinionated. GitHub Actions, not Jenkins. AWS, not Azure. k3s, not EKS. I chose the highest-leverage default in each slot; your target job may differ.
- The AWS phase requires a card on file. Teardowns keep it near zero, but the risk isn't zero.
If you want it guided
Everything above is the complete plan — you can run it solo with the table and a search engine. But I also built it as a full free site: Mission: 90 Days DevOps. Every one of the 90 days has the same shape — a short concept with a diagram, a hands-on lab with real commands and real outputs, a "Common Errors & Fixes" section with the actual error strings you'll hit, and 3–5 interview Q&A. The ten incident drills are playable missions in a browser terminal — no setup, no code required.
No signup, no email wall, no paywall. It's a static site; your progress saves in your browser. I'm one engineer building this in public, and the deal is simple: it's free, and if it helps, tell someone.
Start with Day 1, or just play the first mission — "Server Down!" takes about ten minutes and needs zero setup.
Two questions for the comments — I read every one:
- If you've already made the dev → DevOps jump: what did your first real production incident teach you that no tutorial did? I'm collecting these — the best ones tend to become new missions.
- If you're starting now: which phase looks scariest?
Top comments (0)