People regularly ask me where to start in Kubernetes, DevOps or platform engineering with no Linux, networking or coding background. A list of links and course names doesn’t help much when you don’t yet know what a process, a subnet or a YAML file is.
So I wrote the path down properly, as a GitHub repo you can clone and work through in order: zero-to-senior-cloud-native-engineer. It covers a roadmap, a certification order, numbered labs, on-call style break/fix tickets and a capstone project spec. This post explains what is in it, how it is meant to be used, and which parts are still unfinished.
Who it is for
The repo assumes you are starting from nothing. Each lab follows the same structure:
- Why this matters: what the topic is and where you will meet it at work
- Concepts: the few ideas you need before typing anything
- Hands-on steps: exact commands and what you should see
- Real-world scenario: a broken system to fix, written like an on-call ticket
- Check yourself: questions and tasks that show you actually learned it
- Cert mapping: which exam objectives the lab covers
The README’s golden rules: type every command yourself, break things on purpose, spend two hours in the lab for every hour of reading, and explain each topic out loud.
The roadmap: 30 months, about 25 hours a week
ROADMAP.md lays out 20 phases (0 to 19) over roughly 30 months, assuming about 25 hours a week. The order goes from fundamentals to specialisation:
| Phase | Topic | Exam at the end |
|---|---|---|
| 1-4 | Linux, networking, Bash/Git/Python, RHEL admin | RHCSA |
| 5-6 | Docker, AWS, Terraform, CI/CD | AWS SAA, Terraform Associate (optional) |
| 7-10 | Kubernetes from fundamentals to security | KCNA, CKAD, CKA, KCSA, CKS |
| 11-15 | Ansible, observability, GitOps, service mesh, platform engineering | RHCE, PCA, OTCA, CGOA, CAPA, ICA, CCA, KCA, CBA, CNPA, CNPE |
| 16-18 | OpenShift, cloud security, AI/MLOps | EX280, EX316, AWS Security Specialty |
The roadmap also tells you to start applying for your first job around month 8 to 10 instead of waiting until the end, and to keep studying while you work.
It is also direct about salary. Certifications alone will not get you to the top pay bands. Skill you can show live in an interview, production and on-call experience, public visibility and a specialisation will. The career ladder gives indicative India ranges per stage and makes clear they vary widely.
The labs
The labs/ folder has 19 numbered labs, from 00-setup to 18-ai-security. Lab 01 is Linux from absolute zero. Lab 15 is OpenShift and OpenShift Virtualization. Most labs come with real files, not just notes:
- 02-networking:
netns-lab.shbuilds container networking by hand with two network namespaces, a bridge, veth pairs and NAT, plus a subnet quiz in Python. - 03-bash-git-python: a health-check script, a log analyser, and a small FastAPI service (
lab-api) with pytest tests. Later labs reuse it for Docker, Kubernetes, Istio and observability. - 07-kubernetes-core: a 3-node kind cluster config, a hardened
lab-api.yaml, and a kubeadm install guide for CKA practice. - 09-kubernetes-security: audit policy, encryption-at-rest config, read-only RBAC, Falco custom rules and Kyverno policies.
- 10-redhat-ansible: an Ansible role and a mock RHCSA exam.
- 18-ai-security: a prompt-injection lab that needs no real model. A naive bot leaks a secret, and your job is to write a safer version that blocks every listed attack.
To start, set up a local cluster with the lab’s own kind config:
git clone https://github.com/Willey2003/zero-to-senior-cloud-native-engineer.git
cd zero-to-senior-cloud-native-engineer/labs/07-kubernetes-core
kind create cluster --config manifests/kind-3node.yaml --name lab
kubectl get nodes -o wide
On-call scenarios
My years in VMware support taught me that you learn troubleshooting under pressure, not from slides. So scenarios/README.md lists 30 tickets across Linux, networking, Docker, cloud, Kubernetes, security, observability, GitOps, service mesh, OpenShift and AI. Examples include “Disk full but files not visible”, “Service has no endpoints”, “etcd data loss” and “mTLS broke legacy client”.
To be clear about what exists today: five of the Kubernetes tickets (14, 15, 16, 20 and 21) have a script that breaks a kind cluster on purpose. The other 25 are written ticket descriptions with the skills they test, and you set up the failure yourself.
kubectl apply -f labs/07-kubernetes-core/manifests/lab-api.yaml
./scenarios/k8s/break.sh 16 # "curl api.shop hangs but pods are Running"
Set a 30-minute timer, write down your hypothesis before each command, and finish with the post-mortem template in the same file.
Certifications and the capstone
CERTIFICATIONS.md lists 24 exams in a suggested order, from RHCSA through Kubestronaut and Golden Kubestronaut to RHCA, with a short reason for each position. It also includes exam-day tips for the hands-on exams. Formats and prices change, so check the official page before you book.
capstone/README.md describes “ShopPlatform”, an internal platform project: Terraform or kubeadm infrastructure, Argo CD app-of-apps, Kyverno and Falco, Istio canaries with automatic rollback, an SLO dashboard, a Backstage template and a RAG assistant with tenant isolation. It is a specification with eight milestones, not a finished build. It is meant to be the project you build yourself and walk interviewers through.
What is still in progress
This is an early, single-commit release, so here is where it stands:
- The roadmap, certification guide, scenarios list and labs 00 to 18 are written.
- The later labs (11 onwards) are shorter and point you to more self-directed work than the early ones.
- The weekly
journal/has a template and a stub for week 1. It is meant to be filled in by whoever follows the path. - Only five scenarios are scripted so far.
I plan to add more scripted scenarios and expand the later labs. If you spot a mistake or want a specific scenario, open an issue.
Get it
Repo: github.com/Willey2003/zero-to-senior-cloud-native-engineer
Read ROADMAP.md once from start to finish, then start at labs/00-setup and go in number order. Commit after every lab, because your Git history becomes your proof of work. If it helps, star the repo and share it with someone just starting out.
Top comments (0)