DevOps engineer roadmap
Every stage applies. The order runs from the Linux shell to pipelines, containers, Kubernetes, infrastructure as code and the cloud, then to the observability and reliability work that keeps services up.
Core and recommended topics. Optional ones stay hidden until you have some real work behind you.
- Core: needed for most jobs of this kind
- Recommended: worth learning early
- Optional: learn it when your work needs it
Stage 1
Linux and the shell
Most servers run Linux. Learn the filesystem, processes, signals and the shell well, because they are what you fall back on when a dashboard shows nothing useful.
Core: Filesystem, permissions and processes
Paths, inodes, file descriptors, the process tree and Unix permissions. These ideas explain a lot of later material, from Docker image layers to systemd units.
CodexOperating systems SimulatorFilesystem Outside linkThe Linux man pages Outside linkkernel.org docs
Core: Shell scripting and the command line
Bash, pipes, grep, sed and awk, exit codes and
trap. Most automation starts as a shell script, and plenty of it stays one.Outside linkGNU Bash manual Outside linkcoreutils manual CodexOperating systems
Recommended: System calls
Reading a file, writing to a socket and starting a process are all system calls. Tools like strace show them, which helps when a program hangs and its logs say nothing.
SimulatorSyscall journey Outside linksyscalls(2) CodexOperating systems
Recommended: Boot, init and systemd
What happens between power-on and a login prompt, and how systemd units, targets and journald start and supervise services.
SimulatorLinux boot Outside linksystemd documentation CodexOperating systems
Stage 2
Networking for ops
Most production problems that look strange turn out to be network problems. You do not need a networking certification, but you should be able to reason about TCP, DNS, TLS and the proxies between a client and your service.
Core: TCP/IP and the connection lifecycle
The handshake, the receive window, timeouts and retransmits. Many latency spikes and hung requests are explained at this layer.
GuideHow TCP works SimulatorTCP handshake CodexNetworking Outside linkRFC 9293: TCP
Core: DNS and service discovery
Record types, TTLs and caching. A wrong record can keep serving from caches until its TTL runs out, which is why DNS changes need planning.
Core: TLS and HTTPS
Certificates, the handshake, SNI and mutual TLS. Expired certificates still cause outages, so automate renewal and alert well before expiry.
GuideHow HTTPS works CodexSecurity Outside linkLet's Encrypt docs
Recommended: NAT, VPCs and private networking
Subnets, route tables, security groups and address translation. Cloud networks are built from these parts, with a console on top.
GuideHow NAT works GuideVPC networking SimulatorVPC packet flow
Recommended: Load balancers and reverse proxies
Layer 4 and layer 7 balancing, health checks and connection draining. When some requests fail and others work, the load balancer is a good first place to look.
GuideHow load balancing works GuideReverse proxy SimulatorLoad balancer
Stage 3
Version control and collaboration
In operations work Git holds more than application code. Infrastructure, pipeline definitions and deploy manifests live there too, so the commit history doubles as the record of what changed in production.
Core: How Git stores data
Blobs, trees, commits and refs. Once you see Git as a store of snapshots addressed by hash, rebase and merge are easier to reason about.
Core: Branching and pull requests
Trunk-based development and GitFlow, short-lived branches, and code review. The goal is a main branch that is always safe to release.
Recommended: GitOps
The desired state of a system lives in a repository, and a controller such as Argo CD or Flux keeps the cluster matching it. Rolling back is a revert.
Outside linkArgo CD docs Outside linkFlux docs CodexKubernetes
Stage 4
CI/CD pipelines
Continuous integration catches a broken change soon after it is pushed. Continuous delivery makes releasing routine. The aim is a pipeline the team trusts enough that a deploy is not an event.
Core: Pipeline fundamentals
Stages, jobs, artifacts and caching, with the fast checks run first. A passing build should mean the change is safe to ship.
Outside linkGitHub Actions docs Outside linkGitLab CI/CD docs
Core: Builds, tests and quality gates
Unit and integration tests, linting and coverage thresholds. Each check that fails in CI is a problem that does not reach production.
Outside linkGitHub Actions: building & testing Outside linkGitLab CI testing
Core: Deployment strategies
Blue-green, canary and rolling deploys, plus feature flags. Each is a way to change production gradually and undo the change quickly if it goes wrong.
SimulatorK8s rollout CodexSystem design Outside linkArgo Rollouts docs
Recommended: Artifact registries and the supply chain
Versioned, immutable and signed images and packages. Knowing exactly what is running in production is the starting point for any security claim.
Outside linkDocker registry docs Outside linkSLSA framework CodexSecurity
Stage 5
Containers (Docker)
A container image packages the application with the libraries and files it needs, so it runs the same on a laptop and in production. On Linux a container is a process isolated with namespaces and limited with cgroups, and knowing that makes most container problems easier to debug.
Core: What a container is
A process with its own namespaces, cgroup limits and a layered filesystem. It shares the host kernel, which is the main difference from a virtual machine.
GuideHow containers work SimulatorDocker internals CodexOperating systems
Core: Images, layers and the build cache
Each Dockerfile instruction produces a cached layer. Put the steps that change least at the top and rebuilds take seconds instead of minutes.
SimulatorContainer layers Outside linkDockerfile reference Outside linkDocker build cache
Recommended: Multi-stage builds and small images
Compile in a large build image and copy only the result into a small runtime image. Smaller images pull faster and carry fewer packages with known vulnerabilities.
Outside linkMulti-stage builds Outside linkDocker best practices
Recommended: Container networking and volumes
Bridge networks, published ports and volumes. Containers are meant to be replaceable, so any data that must survive goes in a volume.
Outside linkDocker networking Outside linkDocker volumes SimulatorDocker internals
Stage 6
Kubernetes
Kubernetes runs control loops that compare the state you declared with what is running and fix the difference, including moving work off failed nodes. It takes a while to learn, and it is what most container platforms are built on.
Core: Pods, the control plane and reconciliation
The API server stores the desired state, and controllers keep changing the cluster until it matches. Deployments, Jobs and most operators work the same way.
SimulatorPod creation CodexKubernetes Outside linkKubernetes concepts
Core: Deployments, ReplicaSets and rollouts
You set the number of replicas and the image, and the Deployment controller replaces pods to match. A rollout or rollback is a change to one field.
SimulatorK8s rollout Outside linkDeployments CodexKubernetes
Core: Services, ingress and cluster networking
How a Service gives short-lived pods a stable address, and how traffic from outside reaches them through an ingress or gateway. Newcomers often get stuck here.
GuideK8s networking GuideService discovery Outside linkKubernetes services
Recommended: Scheduling, requests and limits
How the scheduler places pods on nodes using their resource requests. Requests set too high waste money; too low, and pods get evicted or throttled under load.
SimulatorContainer scheduler SimulatorPod eviction Outside linkResource management
Recommended: Helm and operators
Helm packages manifests as versioned, templated releases. Operators go further and put the steps a person would follow to run software, such as a database, into a controller.
Outside linkHelm docs Outside linkOperator pattern CodexKubernetes
Stage 7
Infrastructure as code
Changes made by clicking in a console are hard to review and hard to repeat. Infrastructure as code puts them in files that go through the same review, history and rollback as application code.
Core: Declarative infrastructure and plan/apply
You describe the end state, the tool works out the difference from what exists, and the plan shows that difference before anything changes.
Outside linkTerraform docs Outside linkTerraform tutorials CodexCloud
Core: State, backends and locking
Terraform records what it manages in a state file. Teams keep that file in a remote backend with locking, so two people cannot apply changes at the same time.
Outside linkTerraform state Outside linkRemote backends SimulatorDistributed lock
Recommended: Modules
Reusable, parameterised pieces of infrastructure, such as a standard VPC or database setup, so each team does not write its own.
Recommended: Drift, imports and multiple environments
Someone changes a resource in the console and the code no longer matches. Detect drift, import resources created by hand, and keep dev, staging and production in step.
Outside linkImport existing resources Outside linkWorkspaces CodexCloud
Stage 8
Configuration and secrets
Many failed deploys come down to a wrong setting or a missing credential. Keep configuration out of the code, keep secrets out of Git, and rotate credentials often enough that it is a normal job.
Core: Configuration and the twelve-factor app
Settings come from the environment rather than being built into the image, so the same build artifact moves from staging to production unchanged.
Core: Secrets management
Vault, cloud secret managers and short-lived credentials. Treat any secret that reaches a Git repository as leaked and rotate it.
Outside linkHashiCorp Vault docs Outside linkAWS Secrets Manager CodexSecurity
Recommended: Kubernetes ConfigMaps and Secrets
Pass settings and credentials to pods without rebuilding images. Kubernetes Secrets are only base64-encoded unless encryption at rest is turned on.
Recommended: Rotation and least privilege
Short-lived credentials with narrow permissions do less damage when they leak. Automate rotation, or it will not happen.
Stage 9
Cloud platforms
AWS, Google Cloud and Azure rent out compute, storage, networking and many managed services. The services have different names on each provider but similar designs, so learning one well makes the others easier.
Core: Compute, storage and networking
Virtual machines, object storage, block storage and VPCs. Most higher-level cloud services are built from these.
CodexCloud Outside linkAWS documentation Outside linkGoogle Cloud docs
Core: IAM and shared responsibility
Identity and access management decides who can do what in an account, and misconfigured permissions are a leading cause of cloud breaches. The provider secures the platform; you secure how you use it.
Outside linkAWS IAM docs Outside linkAzure RBAC CodexSecurity
Recommended: Managed services or self-hosting
A managed database or queue costs more and ties you to a provider, but someone else handles patching, backups and failover. The question is which work you want your team to own.
CodexCloud Outside linkAWS Well-Architected CodexSystem design
Recommended: CDNs and the edge
Serving static files and cached responses from locations near users. It is often the cheapest large latency improvement available.
GuideHow a CDN works SimulatorCloudFront cache GuideAPI gateway CodexNetworking
Stage 10
Observability
Metrics, logs and traces let you answer questions about a running system. With them, "users say checkout is slow" becomes something like "p99 latency on the checkout service rose after the 14:02 deploy".
Core: Metrics and time series
Counters, gauges and histograms, and the RED and USE methods. Metrics are cheap to store and query, which makes them the usual basis for alerts. Keep label cardinality low.
Outside linkPrometheus docs Outside linkGrafana docs CodexPerformance
Core: Structured logs and aggregation
Logs as JSON with request IDs are much easier to search than free text. Collect them centrally so nobody has to SSH into nodes during an incident.
Core: Distributed tracing
Following one request through many services, with timing for each step. In a system of many services it is often the only way to find where the time went.
Outside linkOpenTelemetry tracing Outside linkJaeger docs CodexSystem design
Recommended: Dashboards and alerting
Dashboards are for people investigating; alerts are for waking someone up. Alert on symptoms users notice, such as errors and slow responses, rather than on every internal metric.
Outside linkPrometheus alerting Outside linkGrafana alerting
Stage 11
Scaling and load management
Handling more traffic means more than adding servers. You autoscale on a signal that tracks real load, reject excess work before it piles up, and stop one overloaded service from dragging down the ones that call it.
Core: Horizontal and vertical scaling
Add more instances or use bigger ones, and let an autoscaler adjust the count. Scaling on the wrong metric adds cost and can make the system add and remove instances over and over.
GuideHow autoscaling works SimulatorAutoscaling Outside linkKubernetes HPA
Core: Load balancing algorithms
Round robin, least connections and consistent hashing. The algorithm decides whether one slow or overloaded server affects everyone else.
SimulatorLoad balancer GuideHow load balancing works CodexSystem design
Recommended: Caching
Browser, CDN, application and database caches. A cache hit avoids work entirely, but every cache needs a plan for when data changes.
GuideHow caching works SimulatorDistributed cache CodexPerformance SimulatorThundering herd
Recommended: Rate limiting and load shedding
Rejecting some requests on purpose when traffic exceeds what the system can handle, so the requests you do accept still succeed.
Stage 12
Reliability engineering
Site reliability engineering, as Google describes it, treats reliability as a target with a budget. You define what working means in numbers, spend the remaining error budget on change, and run incidents with a set process.
Core: SLIs, SLOs and error budgets
Pick a measure users notice, set a target, and the gap between the target and 100% is the error budget. While budget remains, ship; when it runs out, focus on reliability.
Outside linkSRE Workbook: implementing SLOs Outside linkGoogle SRE Book CodexSystem design
Core: Incident response and on-call
Clear roles such as incident commander, one channel for updates, and a focus on stopping the damage before finding the cause.
Outside linkSRE Book: managing incidents Outside linkPagerDuty incident response
Core: Blameless postmortems
A written review of an incident that looks at how the system and process allowed it, rather than who to blame. People report problems more readily when they are not punished for them.
Outside linkSRE Book: postmortem culture Outside linkSRE Workbook: postmortems
Recommended: Resilience patterns
Timeouts, retries with backoff, circuit breakers and bulkheads. They keep one slow dependency from causing a wider outage.
SimulatorCircuit breaker SimulatorRetry strategy CodexSystem design
Recommended: Chaos engineering
Injecting failures on purpose, with a limited scope, to check that failover and alerts work. A failover that has never been tested may not work when it is needed.
Stage 13
Security and compliance
Security checks belong in the pipeline and the platform, where they run on every change, rather than in a review at the end. Scan what you build, restrict what runs, and log enough to spot an attacker who gets in.
Core: Scanning in the pipeline
Static analysis, dependency scanning and image scanning in CI. A problem found before merge is much cheaper to fix than one found in production.
CodexSecurity Outside linkOWASP Top Ten Outside linkTrivy docs
Core: Container and supply-chain security
Minimal base images, signed artifacts and an SBOM, so you can show what is running and where it came from.
Outside linkDocker security Outside linkSigstore docs Outside linkSLSA framework
Recommended: Kubernetes security and policy
RBAC, network policies, Pod Security Standards and admission control. By default many of these are open, so a new cluster needs them set deliberately.
Outside linkKubernetes security Outside linkPod Security Standards CodexKubernetes
Recommended: Network security and zero trust
Mutual TLS, segmentation, and checking identity on every connection instead of trusting anything inside the network perimeter.
Stage 14
Platform engineering
Platform teams build internal tooling for other engineers and treat it as a product with users. A good platform makes the safe way to build and deploy a service the easiest way too.
Core: Internal developer platforms
A supported default way to build, deploy and run a service, with self-service in place of tickets for the common cases.
Recommended: Service catalogs and developer portals
One place to find each service with its owner, documentation and health. Backstage is the best-known open-source example.
Recommended: Self-service infrastructure
Templates and guardrails that let teams create databases, queues and environments themselves within limits the platform team sets.
Outside linkCrossplane docs Outside linkTerraform modules CodexCloud
After this roadmap
- SimulatorsModels of Kubernetes rollouts, autoscaling, circuit breakers and load balancers that run in the browser.
- How it worksGuides to DNS, TLS, containers, load balancing and the other parts of the stack this roadmap covers.
- CodexLonger study pages on Kubernetes, the cloud, operating systems and networking.