Production-First DevOps Roadmap

$ method - problems before tools

Most 2026 DevOps roadmaps fail because they treat learning as badge collection. This path starts from a production-shaped problem, not a YouTube playlist.

• →Pick one problem a production team actually has.
• →Learn the smallest tool set that solves that problem.
• →Build a project that can fail in public (GitHub, dated commits).
• →Write the failure down: README section, ADR, incident note, or short post.
• →Tear cloud resources down. Zero leftover cost is part of the skill.
• →Only then add the next layer.

Gate: if you cannot answer what broke and how you proved it is fixed, you are not done with that phase. Documentation is not extra work. It is the deliverable. Atlas reads well because the repo ships ADRs, runbooks, teardown scripts, and demos, not because the README name-drops Argo CD.

$ phase 0 - operating system literacy

Time: 2 to 3 weeks. No cloud bill. Containers, Kubernetes, CI agents, and on-call all sit on Linux primitives: processes, files, users, networking, disks, logs.

Skills

• →Filesystem and permissions: ls, stat, chmod, chown, umask, sticky bit.
• →Processes: ps, top or htop, signals, nice, foreground vs background.
• →Users, groups, sudo, SSH keys.
• →systemd: unit files, journald, restart policies.
• →Networking: IP, CIDR, DNS, ports, ss, /etc/hosts, default route.
• →Disks: mount, inodes, logs filling /var.
• →Shell: variables, pipes, jq, exit codes, cron.
• →Git as daily work: branch, rebase vs merge, pull request, .gitignore, tags.

Project

Run Ubuntu on a cheap VM (local or a tiny cloud box you will delete). Write a bash script that checks disk and memory, lists failed systemd units, tails a service log, writes a dated report, and runs from cron. Then build a minimal rootfs, chroot, mount proc, inspect processes. That is the container-from-scratch exercise (github.com/prashant-zo/container-from-scratch).

Done when you can explain, without notes: why a process is running but not listening; why a container sees host files only when you mounted them; why permission denied is a policy outcome, not mysticism. Do not start AWS here. Skipping this phase is how people drown in EKS later.

$ phase 1 - one cloud by hand

Time: 3 to 4 weeks. AWS only. Ignore Azure and GCP until one cloud is boring. Cloud here means identity, network isolation, and blast radius.

• →IAM: users vs roles vs policies, least privilege, access keys on laptops as a smell.
• →VPC: public vs private subnet, route table, IGW, NAT, security group vs NACL.
• →EC2 lifecycle, AMI, user-data, key pairs.
• →S3: bucket policy, encryption, public vs private.
• →Billing alarms on day one.
• →AWS CLI and jq until JSON output is readable.

Project A: AWS Resource Tracker

Bash on EC2 with an IAM role (no keys in the repo) inventories EC2, S3, Lambda, IAM users, writes a timestamped report, cron schedule. Repo: github.com/prashant-zo/aws-resource-tracker.

Done when you can draw the VPC on paper and trace a packet from the internet to a private instance, and you can find and release an unused Elastic IP.

$ phase 2 - infrastructure as code

Time: 3 to 4 weeks. The console teaches. The console as source of truth rots environments.

• →Terraform: provider, resource, data source, variable, output, state.
• →Why state exists; why local state is a trap; S3 backend and DynamoDB lock.
• →plan vs apply vs destroy; drift when someone edits a security group in the console.
• →Modules only after ugly-but-working .tf files exist.
• →Never commit terraform.tfstate or secrets.

Project B: terraform-aws

Provision EC2 with Terraform, destroy it, then add security group, key pair, variables, remote state. Repo: github.com/prashant-zo/terraform-aws. Rule: every apply has a matching destroy documented in the README. An orphaned EBS volume is a failed project even when apply succeeded.

Done when you can explain two applies without locking, and you have a terraform plan screenshot showing a change you did not expect.

$ phase 3 - containers you can debug

Time: 2 to 3 weeks. Docker is image layers, PID 1, networking, and the gap between a healthy container and a healthy app.

• →Image vs container vs registry.
• →Dockerfile: base image, layers, cache, non-root user, .dockerignore.
• →Multi-stage builds.
• →Compose for app plus database plus volume.
• →Healthchecks, logs, bind mounts vs named volumes.
• →Why floating latest tags break rollbacks.

Project C: two-service Compose

Web app plus database. Expose /health and /crash. You will reuse this stack in Phase 6. Done when you can read docker inspect, explain a restart loop, and rebuild without busting every layer cache.

$ phase 4 - ci/cd as a contract

Time: 3 weeks. Learn one CI deeply (Jenkins is still common in enterprises). Learn GitHub Actions for public repos.

• →Separate build, test, artifact, deploy stages.
• →Agents vs container agents.
• →Secrets in the platform, not plaintext in YAML.
• →Idempotent jobs.
• →Green pipeline does not prove production health.

Project D: Jenkins then Actions

Jenkins on EC2 with Docker agents and a multi-stage pipeline (backend, frontend, database check). Repo: github.com/prashant-zo/jenkins-pipelines. Add GitHub Actions on the same app: lint, test, build image, push to a registry.

Done when you can explain why the backend stage should not run on a Node-only image, and you have a pipeline failure caused by a real test assertion, not YAML indentation.

$ phase 5 - kubernetes as an api

Time: 5 to 7 weeks. Local first (kind or k3d). Cloud later. Walk the object model in order, similar to github.com/prashant-zo/kubernetes-prc.

• →Control plane reconciliation mental model.
• →Pods, probes, resources, QoS.
• →ReplicaSets and Deployments.
• →Services: ClusterIP, NodePort, kube-proxy dataplane.
• →ConfigMaps and Secrets (Secrets are not secret by default).
• →Volumes, PVCs, StorageClasses.
• →StatefulSets and database semantics.
• →Jobs and CronJobs.
• →Ingress or Gateway API.
• →RBAC, HPA, Helm as packaging.
• →kube-state-metrics: what the metrics mean.

Project E: practice then three-tier

One folder per concept, one manifest you applied and broke on purpose. Then frontend, API, database on kind. Done when you can answer: CrashLoopBackOff causes; empty Service endpoints; Deployment rolled out but users still hit the old binary; why Postgres should not be a naked Deployment. If you cannot, do not open the EKS console yet.

kubectl explain pod.spec.containers
kubectl get endpoints -A
kubectl describe pod <name> | less

$ phase 6 - self-healing runtime

Time: 3 to 4 weeks. Terraform creates machines. Something still configures them and keeps processes alive.

Project F: Sentinel SRE

Flask app plus monitor polling /health and restarting the container on crash. Terraform for EC2, Ansible for the box and Compose deploy, GitHub Actions for CI/CD, remote state with locking. Repo: github.com/prashant-zo/sentinel-sre.

• →Recovery is a product feature.
• →Health endpoints are contracts.
• →CI that cannot apply infra is incomplete.
• →State locking is mandatory once a pipeline applies Terraform.

Done when you demo /crash, monitor restart, traffic returns, and you show the log line that proves it.

$ phase 7 - drift and gitops thinking

Time: 3 to 4 weeks. Move from provision to keeping reality aligned with Git.

Project G: GitOps Drift Shield

Terraform is desired state. drift-detector runs terraform plan -detailed-exitcode. Exit code 2 means drift. Alert, optional Jenkins remediation, audit JSON to S3, Prometheus metrics for the detector. Repo: github.com/prashant-zo/gitops-drift-shield.

• →Desired state vs actual state.
• →Detection without remediation still has value.
• →Remediation without an audit trail is dangerous.
• →Scheduled checks beat hoping someone notices.
• →Console edits are untracked deploys.

Done when you change a security group in the AWS console, watch the detector fire, and show a JSON audit object for the fix.

$ phase 8 - capstone platform (Atlas)

Time: 4 to 8 weeks. Do not start here. Repo: github.com/prashant-zo/atlas-platform. Build in slices:

• →Week A: kind or k3d with scripted up and down.
• →Week B: Argo CD app-of-apps, ApplicationSets, sync waves so operators exist before workloads.
• →Week C: Kustomize base plus overlays (dev, staging, prod).
• →Week D: CloudNativePG or equivalent: three instances, pooler, backup to MinIO or S3, measure your failover time.
• →Week E: Prometheus, Grafana, Loki, ServiceMonitors, multi-window SLO burn alerts per namespace.
• →Week F: Argo Rollouts canary with Prometheus AnalysisTemplate; demo good promotion and bad revision abort with stable still serving.
• →Week G: Terraform VPC, EKS, IRSA, bootstrap with jq, destroy script with zero EBS orphans, tear down when done.

Capstone done when: local path works from README on a fresh machine; cloud path documents billed hours and verified destroy; one canary abort backed by metrics; staging abort does not touch prod; at least four ADRs; one incident write-up from a bug you actually hit (gRPC port-forward, CRD Kustomize trap, CNPG timing, EBS orphan).

$ phase 9 - after the core path

Only after Phase 8. Pick one specialization, not three logos:

• →Internal platforms: golden paths, developer portals, environment vending, policy (Kyverno or OPA).
• →SRE depth: error budgets, incident command, load tests (k6 on Atlas), capacity.
• →AI infra: model serving, GPU scheduling, quantization, tracing token cost, eval pipelines.

Depth on one track beats a new badge on the homepage.

$ artifacts - what ships with every project

• →README with architecture and destroy steps (strangers can run it).
• →One ADR for a real decision (interviews are decision reviews).
• →One incident or learning note (shows debugging, not copying).
• →Screenshots or a 3 to 5 minute demo (proof, not claims).
• →Public GitHub plus a short build log when you are ready.

Write what you needed the night something broke. Atlas learning docs (Kustomize CRD trap, CNPG bootstrap timing, multi-env canary) are the pattern.

$ avoid - traps in 2026

• →Do not learn three clouds. Learn one until IAM and networking are boring.
• →Do not start with Kubernetes. You will memorize YAML and fail on-call.
• →Do not collect certifications before destroyable projects exist.
• →Do not keep EKS running for a screenshot. Record, then destroy.
• →Do not squash Git history into one final commit.
• →Do not confuse Helm install success with a platform.
• →Do not add service mesh, Crossplane, and five observability vendors to the first capstone.

$ calendar - realistic pace

Assume 10 to 15 focused hours per week.

• →Month 1: Phase 0, Linux plus Git plus rootfs (container-from-scratch).
• →Month 2: Phase 1, AWS by hand plus aws-resource-tracker.
• →Month 3: Phase 2, Terraform plus terraform-aws.
• →Month 4: Phase 3 to 4, Docker plus jenkins-pipelines.
• →Months 5 to 6: Phase 5, kubernetes-prc plus small three-tier.
• →Month 7: Phase 6, sentinel-sre.
• →Month 8: Phase 7, gitops-drift-shield.
• →Months 9 to 10: Phase 8, atlas-platform.
• →Month 11 plus: one specialization track.

Faster is possible. Skipping phases is how candidates explain Helm in interviews and fail a live CrashLoop debug.

$ interview - twenty minute checklist

If you followed this path, you should be able to explain:

• →Why you chose app-of-apps plus ApplicationSets.
• →How a canary abort protected stable traffic.
• →How Terraform module order and IRSA work on EKS.
• →How you verified destroy left no disks.
• →One production-shaped incident you caused and fixed yourself.