Everything from the map above, on one page. Dashed topics are optional. The hours are rough estimates for reading plus hands-on practice.
Stage 1 · Beginner Foundations
DevOps engineers spend their day in terminals, on networks and in Git. These foundations matter more than any single tool, and every later topic assumes them.
What DevOps is (and isn't)
DevOps is a way of working, not a job title or a tool: the people who build software and the people who run it share responsibility for it, automate the boring and risky parts, and get fast feedback from production. The goal is to ship small changes often and safely, instead of big risky releases a few times a year.
The DORA research programme measures this with four key metrics: how often you deploy, how long a change takes to reach production, how often changes cause failures, and how quickly you recover. High-performing teams are good at all four at once: speed and stability go together.
What to learn
- The problems DevOps solves: hand-offs, "throw it over the wall", slow and risky releases
- The four DORA metrics: deployment frequency, lead time, change failure rate, time to restore
- CALMS: culture, automation, lean, measurement, sharing
- The difference between DevOps, SRE and platform engineering
- The Twelve-Factor App principles for software that is easy to deploy and run
Free resources
Practice
Think of a project you know (at work, college or open source). Estimate its four DORA metrics and write down the one change that would improve the worst of them.
Linux and the command line
Almost every server, container and CI runner you will touch runs Linux. You need to be at home in a terminal: moving around the filesystem, reading and editing files, managing permissions, processes and services, and finding out why something isn't working.
Our Linux & Shell roadmap covers all of this step by step. For DevOps, focus on its topics on the terminal, permissions, processes, services and logs, linked below.
What to learn
- Navigate and manage files:
ls cd cp mv rm find, absolute vs relative paths
- Users, groups and permissions (
chmod, chown, sudo)
- Processes and services:
ps top kill, systemctl, journalctl
- Package managers (
apt, dnf) and where config and logs live (/etc, /var/log)
- Text processing with pipes:
grep sed awk sort uniq head tail
- Connecting to servers with SSH keys
Free resources
Practice
Install Ubuntu in a VM or WSL. Create a user, give them sudo, install nginx, find its config and log files, and make it start at boot with systemctl enable.
Networking for DevOps
Most production problems end up being network problems: a wrong DNS record, a closed port, an expired certificate, a firewall rule. You don't need to be a network engineer, but you must be able to follow a request from a browser to a server and back, and test each step.
Learn IP addresses and subnets (you'll need CIDR for every cloud network), TCP vs UDP and ports, DNS records, and the tools to debug them: ping, dig, curl, ss and traceroute.
What to learn
- The OSI/TCP-IP layers at a practical level: what lives at L3, L4 and L7
- IPv4 addressing, private ranges, CIDR notation and subnetting
- TCP vs UDP, common ports (22, 53, 80, 443, 5432) and what a socket is
- DNS: A, AAAA, CNAME, MX, TXT records, TTLs and resolving with
dig
- NAT, firewalls, load balancers and reverse proxies
- Debugging with
curl -v, ss -tlnp, ping, traceroute
Free resources
Practice
Pick any website. Use dig to find its IP addresses and name servers, curl -v to see the TLS handshake and HTTP headers, and traceroute to count the hops to it.
Git and version control
In DevOps, everything lives in Git: application code, pipeline definitions, infrastructure as code and Kubernetes manifests. Git is the audit trail, the review process and, with GitOps, the deployment mechanism.
Our Git & GitHub roadmap covers it in depth. For DevOps you need confident everyday use, branching, pull requests and protected branches.
What to learn
- Commits, the staging area and writing good commit messages
- Branches, merging and rebasing, and resolving conflicts
- Remotes: clone, fetch, pull, push
- Pull requests and code review
- Branch protection and required checks
- A
.gitignore, and never committing secrets
Free resources
Practice
Create a repository for your DevOps notes and scripts. Work on a feature branch, open a pull request, merge it, and protect main so nobody can push to it directly.
Scripting and a programming language
Automation is the heart of DevOps, so you need to write scripts. Start with Bash for gluing commands together, then learn one general-purpose language. Python is the most common choice for automation and tooling; Go is what most cloud-native tools (Docker, Kubernetes, Terraform) are written in.
You don't need to be a software engineer, but you should be able to read an API's JSON, loop over servers, handle errors, and write a small command-line tool that a teammate can run.
What to learn
- Bash scripts: variables, conditions, loops, functions, exit codes and
set -euo pipefail
- Checking scripts with ShellCheck
- Python basics: data types, functions, files, virtual environments and
pip
- Calling HTTP APIs and parsing JSON and YAML
- Command-line arguments, environment variables and logging
Free resources
Practice
Write a script that checks a list of URLs, prints the HTTP status and response time of each, and exits with an error if any of them is down. Then rewrite it in Python.
How the web works: HTTP, TLS and APIs
Most things you deploy talk HTTP. Know what happens when you type a URL: DNS lookup, TCP connection, TLS handshake, the HTTP request and response, and the status code that tells you what went wrong.
HTTPS certificates are a classic source of outages: they expire, they cover the wrong names, or the chain is incomplete. Learn how they work and how to inspect one.
What to learn
- HTTP methods, headers, status codes and caching
- REST APIs and JSON, and calling them with
curl
- TLS certificates: chains, expiry, SANs and Let's Encrypt
- Cookies, tokens and JWTs at a basic level
- HTTP/1.1 vs HTTP/2 vs HTTP/3, and WebSockets
Free resources
Practice
Use curl -v against three APIs and explain every line of the output. Then decode the certificate of a website you use and note when it expires.
Terminal productivity: editors, tmux and dotfiles
You will edit files on servers that have no graphical editor, often over a slow connection. Knowing the basics of vim (or nano), a terminal multiplexer like tmux and a tidy set of dotfiles saves time every single day.
What to learn
- vim survival: insert mode, save, quit, search and replace
- tmux: sessions, windows and panes that survive a dropped SSH connection
- Shell aliases, history search (Ctrl+R) and a dotfiles repository
Free resources
Practice
Do a full day of server work using only vim and tmux, and put your shell config in a dotfiles repository.
Am I ready? Stage 1 quiz
Which of these is one of the four DORA metrics?
- Lines of code written per week
- Change failure rate
- Number of servers
- Test coverage
DORA measures deployment frequency, lead time for changes, change failure rate and time to restore service.
A script must stop as soon as any command fails. What should it start with?
#!/bin/sh -xset +etrap exitset -euo pipefail
-e exits on errors, -u on unset variables and pipefail makes a pipeline fail if any part fails.
How many addresses does a /24 network contain?
- 256
- 24
- 512
- 65,536
32 − 24 = 8 host bits, and 28 = 256.
A website works by IP address but not by name. Which tool do you reach for first?
chmodtopdiggit log
If the IP works and the name doesn't, it's a DNS problem, and dig shows what the name resolves to.
What does HTTP status 503 mean?
- The page was not found
- The service is unavailable, often overloaded or down for maintenance
- You are not logged in
- The request was successful
5xx codes are server errors; 503 Service Unavailable often comes from a load balancer with no healthy targets.
Stage 2 · Build and ship Containers, pipelines and releases
Turn code into something that runs the same everywhere, test it automatically on every change, and release it safely. This is the "continuous" in continuous integration and delivery.
Containers and Docker
A container packages an application with everything it needs (runtime, libraries, config) so it runs the same on a laptop, in CI and in production. Docker builds images from a Dockerfile and runs them; Docker Compose (now the docker compose command, built into the Docker CLI) runs several containers together for local development.
Good images are small, rebuild quickly thanks to layer caching, don't run as root and contain no secrets. Note that Docker Desktop needs a paid subscription at organisations with more than 250 employees or more than $10 million in annual revenue; Docker Engine on Linux, Podman and Rancher Desktop are free alternatives.
What to learn
- Images vs containers, layers and the build cache
- Writing a Dockerfile: base images,
COPY, RUN, CMD vs ENTRYPOINT
- Multi-stage builds for small images, and a
.dockerignore
- Ports, volumes, environment variables and container networking
- Docker Compose for multi-container apps
- Running as a non-root user and scanning images for vulnerabilities
Free resources
Practice
Containerise a small web app with a database using a multi-stage Dockerfile and a Compose file. Get the image under 100 MB and make it run as a non-root user.
CI/CD pipelines
Continuous integration means every change is merged often and checked automatically: build, lint and test on every push and pull request. Continuous delivery keeps the main branch always deployable; continuous deployment goes one step further and releases every change that passes automatically.
GitHub Actions and GitLab CI are the most common tools today; Jenkins is still everywhere in larger companies. The concepts carry over: triggers, jobs, steps, runners, caching, artifacts, environments and secrets.
What to learn
- CI vs continuous delivery vs continuous deployment
- Pipeline building blocks: triggers, jobs, steps, runners and matrices
- Caching dependencies and passing artifacts between jobs
- Environments, manual approvals and deploying from a pipeline
- Least-privilege permissions and short-lived cloud credentials (OIDC)
- Keeping pipelines fast: run only what changed, run jobs in parallel
Free resources
Practice
Add a pipeline to your containerised app that lints, tests and builds the image on every pull request, and pushes it to a registry when main changes.
Testing in the pipeline
A pipeline is only as good as the checks in it. Fast unit tests catch most bugs; slower integration and end-to-end tests catch what unit tests miss. Static analysis, linting and dependency scanning catch whole classes of problems before a human reviews the code.
Aim for a pipeline that gives an answer in minutes. Put the fastest, most likely-to-fail checks first, and run load tests against staging before big launches.
What to learn
- The test pyramid: unit, integration and end-to-end tests
- Linters and formatters as pipeline gates
- Smoke tests after a deployment
- Load and performance testing basics (k6, Locust)
- Dealing with flaky tests instead of retrying forever
Free resources
Practice
Add a smoke test that runs after each deployment and fails the pipeline if the health endpoint doesn't answer within 30 seconds. Then load-test your app locally to find where it starts to slow down.
Artifacts, registries and versioning
A build produces an artifact: a container image, a package or a binary. Store it once in a registry (Docker Hub, GitHub Container Registry, Amazon ECR) and deploy that exact artifact to every environment, so what you tested is what you run.
Tag images with something traceable, such as the Git commit SHA or a semantic version, rather than only latest.
What to learn
- Build once, deploy many times: promote the same artifact through environments
- Container registries: pushing, pulling, authentication and retention
- Image tags vs digests, and why
latest is risky
- Semantic versioning and release notes
Free resources
Practice
Make your pipeline tag every image with the commit SHA and, for Git tags like v1.2.0, with the version too. Deploy by digest once.
Configuration and secrets
Keep configuration out of the code and in the environment, so the same artifact runs in development, staging and production. Secrets (passwords, API keys, certificates) need extra care: never commit them to Git, never print them in logs, and rotate them.
Use the secret store of your platform (GitHub Actions secrets, AWS Secrets Manager, Kubernetes Secrets with encryption, HashiCorp Vault) and prefer short-lived credentials over long-lived keys wherever you can.
What to learn
- Twelve-factor config: environment variables and config files per environment
- Secret stores: pipeline secrets, cloud secret managers, Vault
- Short-lived credentials (OIDC, IAM roles) instead of stored keys
- Detecting committed secrets with secret scanning, and what to do if one leaks
- Rotating secrets without downtime
Free resources
Practice
Move every setting of your app into environment variables, store the secrets in your CI's secret store, and turn on secret scanning for the repository.
Release and deployment strategies
How you release matters as much as what you release. A rolling deployment replaces instances a few at a time; blue-green switches traffic between two identical environments; a canary sends a small share of traffic to the new version first. Feature flags separate deploying code from turning features on.
Whatever the strategy, know how to roll back in one step, and make database changes backwards compatible so the old and new versions can run side by side.
What to learn
- Rolling, blue-green and canary deployments, and their trade-offs
- Feature flags and dark launches
- Rolling back quickly, and roll forward vs roll back
- Backwards-compatible database migrations (expand and contract)
Free resources
Practice
Deploy two versions of your app behind a reverse proxy and send 10% of traffic to the new one. Then practise a rollback and time it.
Build tools and task runners
A Makefile (or a task runner like just or npm scripts) gives every project the same entry points: make test, make build, make deploy. The pipeline and developers then run exactly the same commands.
What to learn
- Make targets, dependencies and phony targets
- Language build tools: npm, Maven/Gradle, Go modules, pip
- Reproducible builds and lock files
Free resources
Practice
Add a Makefile to your project and change your pipeline to call only make targets.
Am I ready? Stage 2 quiz
What is the main benefit of a multi-stage Docker build?
- Containers start in parallel
- Images are signed automatically
- The final image contains only what's needed to run, not the build tools
- It replaces Docker Compose
Build in one stage, copy only the result into a small runtime stage.
What is continuous delivery?
- Every change is kept releasable, and releasing is a simple, routine step
- Every commit goes to production with no checks
- Releasing once a quarter
- Deleting old branches automatically
Continuous deployment releases automatically; continuous delivery keeps everything ready to release at any time.
Why tag images with the Git commit SHA instead of only latest?
- It makes images smaller
- Registries reject
latest - It speeds up the build
- You always know exactly which code is running and can roll back to it
latest moves; a SHA tag (or a digest) always means the same build.
An API key was committed to a public repository. What should you do first?
- Delete the commit and force-push
- Revoke and rotate the key
- Make the repository private
- Add the file to
.gitignore
Assume it's already been copied. Revoke it first; cleaning the history comes after.
Which strategy sends a small percentage of real traffic to a new version first?
- Blue-green
- Recreate
- Canary
- Big-bang
A canary release exposes a few users to the new version and widens the rollout if the metrics stay healthy.
Stage 3 · Intermediate Cloud, infrastructure as code and Kubernetes
Run your containers on real infrastructure, and describe that infrastructure in code so it can be reviewed, repeated and rebuilt.
A cloud provider
Pick one cloud (AWS, Azure or Google Cloud) and learn it properly before touching a second; the concepts transfer. You need identity and access management, virtual networks, virtual machines, object storage, managed databases, load balancers and how billing works.
Our AWS roadmap covers AWS in depth. Whatever you choose, set a budget alert on day one.
What to learn
- Identity and access: users, roles, policies and least privilege
- Virtual networks, subnets, security groups and NAT
- Compute (VMs), object storage and managed databases
- Load balancers, DNS and auto scaling
- Billing, budgets and the free tier
- The cloud's CLI, so everything can be scripted
Free resources
Practice
By hand in the console, build a VPC with a public and a private subnet, a VM running your container, and a load balancer in front of it. Then delete everything; you'll rebuild it with code in the next topic.
Web servers, reverse proxies and TLS
Something has to sit in front of your application: terminate HTTPS, serve static files, compress responses and pass requests to the app. Nginx is the classic choice; Caddy gets certificates from Let's Encrypt automatically; in the cloud, a managed load balancer often does the job.
What to learn
- Reverse proxy and load-balancing configuration in nginx
- HTTPS with Let's Encrypt and automatic renewal
- Gzip/Brotli compression, caching headers and HTTP/2
- Health checks and timeouts between proxy and app
Free resources
Practice
Put nginx in front of your app with a free certificate, and get an A rating on an SSL test. Check the certificate chain and expiry yourself.
Infrastructure as code with Terraform or OpenTofu
Infrastructure as code (IaC) describes servers, networks and databases in text files that live in Git. You review changes in pull requests, preview them with a plan, apply them the same way every time, and can rebuild an environment from scratch.
Terraform is the most widely used tool. In August 2023 HashiCorp moved it from an open-source licence to the Business Source License, and the community forked it as OpenTofu, now an open-source project under the Linux Foundation. The two use the same language (HCL) and work almost identically, so what you learn applies to both. HashiCorp's Terraform Associate (004) exam, a one-hour multiple-choice test, covers Terraform 1.12.
What to learn
- Providers, resources, variables, outputs and data sources
- The plan/apply workflow and reading a plan carefully
- State: what it is, remote state with locking, and never editing it by hand
- Modules for reusable infrastructure
- Separate environments (workspaces or directories) and drift
- Running Terraform in CI with plan output on pull requests
Free resources
Practice
Rebuild the network, VM and load balancer from the cloud topic in Terraform or OpenTofu, with remote state. Destroy it and recreate it with one command.
Configuration management with Ansible
Terraform creates infrastructure; Ansible configures what runs on it: installing packages, writing config files, managing users and services across many servers at once. It connects over SSH and needs no agent on the servers.
With containers and immutable images, you configure servers less often than before, but Ansible is still everywhere for VMs, network devices and bootstrapping.
What to learn
- Inventories, ad-hoc commands and playbooks
- Modules, idempotence and handlers
- Variables, templates (Jinja2) and roles
- Ansible Vault for secrets
Free resources
Practice
Write a playbook that installs nginx and your app on two VMs, templates the config, and restarts nginx only when the config changes. Run it twice and check that nothing changes the second time.
Kubernetes
Kubernetes runs containers across a cluster of machines: it restarts them when they crash, scales them, rolls out new versions and routes traffic to them. It's complex, but it's the standard platform for running containers at scale and appears in most DevOps job descriptions.
Our Kubernetes roadmap takes you from Pods to production in 33 topics. For this roadmap, aim for its stages 1 and 2: deploying, exposing, configuring and debugging an application on a local cluster. The CNCF's hands-on CKA exam is the usual next step.
What to learn
- Pods, Deployments and Services
- ConfigMaps, Secrets and resource requests and limits
- Health probes and rolling updates
- Routing traffic in with the Gateway API
- Packaging apps with Helm
- Debugging with
kubectl describe, logs and events
Free resources
Practice
Deploy your app and its database to a local kind cluster with a Deployment, a Service, a ConfigMap, a Secret and probes. Package it as a Helm chart.
GitOps
With GitOps, Git holds the desired state of your clusters, and an agent inside the cluster (Argo CD or Flux) keeps the cluster matching it. You deploy by merging a pull request; you roll back by reverting one. Nobody needs kubectl apply access to production.
What to learn
- The OpenGitOps principles: declarative, versioned, pulled, continuously reconciled
- Argo CD or Flux: applications, sync and drift detection
- Separating application code repos from deployment config repos
- Promoting a change from staging to production with a pull request
Free resources
Practice
Install Argo CD on your kind cluster, point it at a repository with your Helm chart, and deploy a new version by changing the image tag in a pull request.
Serverless
Serverless functions (AWS Lambda, Azure Functions, Google Cloud Run functions) run your code on demand, scale to zero and bill per request. They suit event-driven work, glue code and spiky traffic, and remove servers from your to-do list, at the cost of cold starts and vendor lock-in.
What to learn
- Functions, triggers and event sources
- Cold starts, timeouts and concurrency limits
- When serverless is cheaper, and when it isn't
Free resources
Practice
Build a function that resizes images dropped into a storage bucket, deployed with your IaC tool.
Am I ready? Stage 3 quiz
What does terraform plan do?
- Creates the resources immediately
- Shows what would change, without changing anything
- Formats the code
- Deletes the state file
Always read the plan before apply; it's the main safety check in IaC.
Why store Terraform state remotely with locking?
- It makes plans faster
- Providers require it
- It hides secrets
- So a team shares one state and two people can't apply at the same time
Local state on one laptop gets lost or out of date; locking prevents two concurrent applies corrupting it.
An Ansible task is idempotent. What does that mean?
- Running it again makes no further changes once the system is in the desired state
- It runs on every host at once
- It can't fail
- It needs an agent on each server
Idempotence lets you run the same playbook safely again and again.
In GitOps, how do you roll back a bad deployment?
- SSH into the nodes
- Run
kubectl delete on the namespace - Revert the commit in the config repository
- Restart the cluster
Git is the source of truth: reverting the change makes the GitOps agent restore the previous state.
Your reverse proxy returns 502 Bad Gateway. What is the most likely cause?
- The user typed the wrong URL
- The application behind the proxy is down or not listening on the expected port
- The certificate expired
- The DNS record is missing
502 means the proxy couldn't get a valid response from the upstream; a timeout would be 504.
Stage 4 · Advanced Observe, respond and improve
Shipping is half the job. Know what your systems are doing, find out about problems before your users do, handle incidents calmly, and keep everything secure and affordable.
Monitoring with Prometheus and Grafana
Metrics are numbers over time: requests per second, error rate, latency, CPU, memory, queue length. Prometheus collects them by scraping your services and stores them as time series; Grafana turns them into dashboards. Together they're the open-source standard, especially on Kubernetes.
Start with the golden signals for every service: latency, traffic, errors and saturation.
What to learn
- Metric types: counters, gauges and histograms
- Prometheus scraping, exporters (node exporter) and labels
- PromQL basics:
rate(), sum by, percentiles from histograms
- Grafana dashboards for the four golden signals
- The RED and USE methods
Free resources
Practice
Run Prometheus and Grafana with Docker Compose, expose metrics from your app, and build a dashboard with request rate, error rate and p95 latency. Then load-test the app and watch the graphs move.
Centralised logging
When you run many containers across many machines, you can't SSH in to read log files. Applications should write logs to standard output, ideally as structured JSON; a collector (Fluent Bit, Vector, the OpenTelemetry Collector) ships them to a central store such as Grafana Loki, Elasticsearch/OpenSearch or a cloud service, where you search them.
What to learn
- Logs as event streams on stdout, not files
- Structured (JSON) logging, log levels and correlation IDs
- Shipping logs with a collector and querying them centrally
- Retention, cost and keeping secrets and personal data out of logs
Free resources
Practice
Switch your app to JSON logs with a request ID, ship them to Loki, and find every log line for one failed request.
Distributed tracing and OpenTelemetry
In a system of many services, one slow request might pass through ten of them. A trace follows a request through every service and shows where the time went. OpenTelemetry is the vendor-neutral standard for producing traces, metrics and logs; you instrument once and send the data to any backend (Jaeger, Grafana Tempo or a commercial tool).
What to learn
- Traces, spans and context propagation between services
- Auto-instrumentation vs manual spans
- The OpenTelemetry Collector: receivers, processors and exporters
- Sampling, and linking traces to logs and metrics
Free resources
Practice
Add OpenTelemetry auto-instrumentation to two services that call each other, send traces to Jaeger, and find the slowest span in a request.
Alerting and on-call
Good alerts are rare, urgent and actionable: they wake someone up only when users are affected and a human must act. Alert on symptoms (errors, latency) rather than causes (high CPU), and attach a runbook to every alert so whoever is on call knows what to do.
What to learn
- Symptom-based alerts vs cause-based alerts
- Prometheus alerting rules and Alertmanager routing, grouping and silencing
- Pages vs tickets: what needs a human now
- Runbooks and healthy on-call rotations
- Fighting alert fatigue: deleting noisy alerts
Free resources
Practice
Write an alert that fires when your app's error rate is above 5% for 5 minutes, route it to email or chat, and write the runbook it links to.
Incident response and postmortems
Incidents will happen. What matters is how quickly you restore service and what you learn. A clear process helps: someone takes the incident commander role, communication goes to one channel, mitigation comes before root cause, and afterwards a blameless postmortem records what happened and the actions that prevent a repeat.
What to learn
- Severity levels and when to declare an incident
- Roles: incident commander, communications, operations
- Mitigate first (roll back, fail over), investigate later
- Status pages and communicating with users
- Blameless postmortems with concrete, owned follow-up actions
Free resources
Practice
Break something on purpose in your lab (fill the disk, kill the database). Handle it as a real incident with a timeline, then write a one-page blameless postmortem.
SLIs, SLOs and error budgets
A service level indicator (SLI) measures what users care about, such as the share of requests that succeed in under 300 ms. A service level objective (SLO) sets a target for it, like 99.9% over 30 days. The gap to 100% is your error budget: while you have budget left you can ship fast; when it's spent, reliability work comes first.
What to learn
- Choosing SLIs: availability, latency, freshness, correctness
- Setting realistic SLOs, and SLOs vs SLAs
- Error budgets and error budget policies
- Burn-rate alerts based on SLOs
Free resources
Practice
Define two SLOs for your app, calculate how many minutes of downtime a month each allows, and replace your error-rate alert with a burn-rate alert.
DevSecOps and supply-chain security
Security belongs in the pipeline, not at the end. Scan dependencies and container images for known vulnerabilities, check infrastructure code for risky settings, keep secrets out of repositories, and give every system the least privilege it needs. Supply-chain security adds signed artifacts and provenance, so you know exactly what was built from which source.
What to learn
- The OWASP Top 10 at a high level
- Dependency and image scanning (Dependabot, Trivy) in CI
- Static analysis and IaC scanning
- Least privilege for people, pipelines and workloads
- Signing images and SLSA provenance
- Patching and keeping base images up to date
Free resources
Practice
Add Trivy to your pipeline so a build fails on critical vulnerabilities, turn on Dependabot, and remove every long-lived cloud key from your CI in favour of OIDC.
Cost awareness (FinOps)
In the cloud, every architecture decision is also a spending decision. FinOps brings engineering and finance together: everyone can see what their services cost, resources are tagged by owner, and waste (idle machines, oversized databases, forgotten disks) is cleaned up continuously.
What to learn
- Reading a cloud bill and tagging resources by team and environment
- Rightsizing, auto scaling and turning things off at night
- Commitment discounts and spot capacity
- Kubernetes cost allocation
Free resources
Practice
Tag every resource in your lab with an owner and environment, then find the three most expensive things and cut the cost of one of them in half.
Platform engineering and developer portals
As organisations grow, a platform team builds an internal developer platform: self-service "golden paths" that let product teams create a service, a pipeline and an environment in minutes without becoming experts in every tool. Developer portals like Backstage are the front door to it.
What to learn
- Platform as a product: who your users are and what they need
- Golden paths and service templates
- Service catalogues and developer portals
Free resources
Practice
Create a template repository that gives a new service a Dockerfile, a pipeline and a Helm chart, so starting a service takes one click.
Chaos engineering
Chaos engineering tests your confidence in a system by injecting failures on purpose, such as killing pods, adding latency or cutting a dependency, in a controlled way. It finds weaknesses before a real outage does.
What to learn
- Hypothesis, steady state and blast radius
- Game days with the whole team
- Chaos tools for Kubernetes
Free resources
Practice
Run a game day: predict what happens when one replica of your app and then the database disappear, run the experiment, and compare.
Am I ready? Stage 4 quiz
Which is one of the four golden signals?
- Number of deployments
- Disk brand
- Saturation
- Lines of log output
The golden signals are latency, traffic, errors and saturation.
An SLO is 99.9% availability over 30 days. Roughly how much downtime does the error budget allow?
- About 43 minutes
- About 4 hours
- About 7 hours
- About 3 days
0.1% of 30 days (43,200 minutes) is 43.2 minutes.
Which alert is the best one to page someone at 3 a.m.?
- CPU above 80% on one server
- A disk 60% full
- A new deployment started
- Checkout errors above 5% for 5 minutes
Page on symptoms users feel; causes like CPU belong on dashboards or in tickets.
During an incident, what comes first?
- Finding the root cause
- Restoring service, for example by rolling back
- Writing the postmortem
- Finding out who made the change
Mitigate first; investigate when users are no longer affected. Postmortems are blameless.
What does OpenTelemetry provide?
- A database for metrics
- A paid monitoring service
- A vendor-neutral standard and tools for producing traces, metrics and logs
- A Kubernetes distribution
You instrument once with OpenTelemetry and export to whichever backend you choose.
How to use this roadmap
- Foundations first. Linux, networking, Git and scripting make every later topic easier. Don't jump to Kubernetes before you can debug a container and a DNS problem.
- Build one project all the way through. Most practice tasks use the same small app: containerise it, build a pipeline, deploy it with IaC, run it on Kubernetes, then monitor it. By the end you have a portfolio project that shows the whole lifecycle.
- Follow the links into the other roadmaps when you want depth: Linux & Shell, Git & GitHub, Kubernetes and AWS.
- Track your progress. Tick sub-skills in each topic: ticking the first marks a topic as in progress, ticking them all marks it as done. Progress stays in this browser. Use Export to move it to another device, or Share progress to send a link.
- Choose a direction. Use the filter to highlight the core path, the SRE / reliability topics or the platform & cloud topics. Optional topics (dashed borders) don't count towards the percentage.
DevOps, SRE or platform engineering?
The titles overlap a lot. DevOps engineers usually build and run pipelines, infrastructure and deployments. Site reliability engineers (SREs) focus on reliability: SLOs, monitoring, incident response and automation that removes toil. Platform engineers build internal platforms that let product teams ship on their own. All three start from the same foundations, which is why they share this roadmap.
Keeping costs at zero while learning
Almost everything here runs on your own computer: Docker, kind, Prometheus, Grafana, Loki, Argo CD and Jenkins are all free. When you use a cloud provider, set a budget alert first, build with infrastructure as code, and destroy everything when you finish each session.