Somebody's deploy failed at 2:40 on a Friday, the person who wrote the pipeline left eight months ago, and the only remaining clue is a log line that says the health check timed out. Nobody in the room can explain why the service was healthy at 2:39. That gap, between a system that appears to work and a team that can explain why, is the space this job occupies, and the training below is built to close it rather than to pass an exam.
The pager is the real curriculum
A DevOps engineer is the person who makes software delivery repeatable and then keeps it observable when it is not. Concretely: build pipelines, infrastructure defined in files, containers and their orchestration, cloud accounts with guardrails, secrets that are not in a repository, dashboards that show the truth, and a rollback that works at the moment you need it. The title is contested because the work sits between development and operations, and different companies draw the border differently. The duties are less contested. Something has to build the thing, something has to ship it, and something has to know when it breaks.
The first surprise for people arriving from development is that the job is mostly reading. You read a failing pipeline, a diff of infrastructure state, a network policy, a query plan, an alert history, a postmortem from six months ago. Then you change one thing and watch. The writing part, whether that is a Terraform module or a workflow file, is the smaller half. Engineers who expect to spend their day typing are disappointed. Engineers who like finding the actual cause of a problem stay.
The second surprise is that most of the value is in removing work rather than doing it. A manual release that took two days of coordination becomes a button. A recurring incident becomes a check that runs before merge. A question that four people ask every week becomes a dashboard. None of that is visible in the same way a feature is visible, and this is why the role needs a habit of writing down what changed. If you cannot show the before and after, the improvement gets attributed to nobody.
The third surprise is the political texture. You will tell a team that their service cannot be deployed safely, that their image is 1.8 GB, that their credentials are in a public repository, or that the architecture they chose will cost four times what they budgeted. Being right is not sufficient. The engineer who can show a measurement, propose the smallest viable fix, and land it without blocking a release for a week is the one who gets trusted with the next system.
There is also a hard boundary worth naming at the start, because beginners cross it by accident. You are not the person who fixes every application bug, and you are not the person who owns every production failure. You own the path to production and the visibility of what happens on it. Teams that blur this end up with a DevOps engineer who debugs business logic at midnight while the delivery pipeline rots. The role's value comes from the platform, not from heroics.
Linux above, the database below
Four areas carry the work. The first three are obvious to anyone reading a job posting. The fourth is the one that pages you at three in the morning.
DevOps & Cloud
This is the centre of the trade. Linux fundamentals, containers, continuous integration, infrastructure as code, orchestration, and the cloud primitives that all of it runs on. The order inside the area matters less than the depth: knowing how a process gets its environment and its file descriptors explains more production bugs than any orchestration tutorial. Networking comes next, because a container that cannot resolve a name is not a container problem.
The catalog holds 30 live resources in this category, with 26 free and 4 paid. Linux Foundation: Introduction to Linux (LFS101) (FREE) is the structured on-ramp to the operating system you will spend your career inside, and DigitalOcean Community Tutorials (FREE) covers the specific setup tasks that block beginners on a real server. Docker Curriculum (FREE) takes you from a first container to a composed stack, and Play with Docker (FREE) gives you a browser lab so you can practise without a laptop that can run virtual machines.
For delivery, GitHub Actions Documentation (FREE) is the reference you will return to weekly, and GitHub Skills (FREE) is a set of short interactive courses that teach the mechanics by doing them. KodeKloud DevOps Free Labs (FREE) and Killercoda (FREE) are free lab environments where you can break things safely, which is the only way this material sticks.
For the operational side, Google Site Reliability Engineering Book (FREE) is the closest thing the field has to a shared vocabulary for reliability, and DevOpsCube (FREE) plus freeCodeCamp: DevOps Engineering Course for Beginners (FREE) cover the practical material that vendor documentation assumes you already know. DevOps Roadmap (FREE) is useful as a map of what you have not touched yet, not as a curriculum to complete.
Paid material here buys structure and lab volume. KodeKloud (PAID) is a subscription with guided paths and graded labs, and AWS Skill Builder (PAID) plus Google Cloud Training (PAID) are the vendors' own training libraries. They are worth it when you need deadlines and a sandbox that resets, not when you need another video.
Cyber Security
Security belongs in this roadmap because a delivery pipeline is an attack path with credentials attached. Every secret in a workflow file, every over-permissioned service account, every base image that has not been rebuilt in a year is a way in. You do not need to become a penetration tester. You need to know what an attacker would find useful and to remove the easy options before someone else finds them.
This area carries 31 live entries, 26 free and 5 paid. OWASP Top 10 (FREE) is the shared list of web failure classes and remains the fastest way to learn what "injection" and "broken access control" actually mean. OWASP Juice Shop (FREE) is a deliberately vulnerable application you can run locally and attack, which teaches more in an afternoon than a week of reading. OverTheWire Bandit (FREE) drills the command-line skills that security work assumes.
For the defensive vocabulary, MITRE ATT&CK (FREE) maps how real intrusions proceed, and NIST Cybersecurity Framework (FREE) plus NCSC Guidance (FREE) give you the language used in audits and vendor reviews. PortSwigger Web Security Academy (FREE) is a large free lab set on web vulnerabilities, and Hacker101 (FREE) is a free course from a bug bounty platform that covers the same ground from an attacker's point of view.
Paid security material is mostly practice volume. Hack The Box (PAID) and Blue Team Labs Online (PAID) sell realistic machines and investigations, and LetsDefend (PAID) simulates a security operations queue. Those are worth paying for only if you intend to work on the defensive side directly. For a delivery engineer, the free labs are enough.
Software Engineering
You cannot automate what you cannot read. This area gives you the ability to open a repository, understand the build, write a script that people will maintain, and review a change without guessing. It also gives you the debugging instinct that separates an engineer who fixes a pipeline from one who reruns it until it goes green.
The catalog lists 36 resources here, with 30 free and 6 paid. Learn Git Branching (FREE) is an interactive visualiser for branches, rebases, and merges, and it is the fastest way to stop fearing history rewriting. Git and GitHub for Beginners (Mohin Sheikh) (FREE) covers the workflow on a team. MDN Web Docs (FREE) is the reference for anything that touches HTTP, headers, and the browser, which is more of your day than you expect.
Software Engineering at Google (free ebook) (FREE) is unusually good on testing, dependency management, and the cost of a change, and MIT 6.031: Software Construction (FREE) covers the design habits that make code safe to modify. Exercism (FREE) and Codewars (FREE) provide practice with feedback, which matters more for scripting fluency than for interview preparation.
CS50x: Introduction to Computer Science (FREE) is the long path if your fundamentals have holes, and Learn X in Y Minutes (FREE) is a fast reference for picking up a language's syntax when a task requires it. Alison Interactive Coding Labs (Python) (FREE) is a lighter, browser-based start.
Databases & Backend
This is the area most delivery engineers neglect until it costs them a night. A deployment that is fine for the application can still take out the database: a migration that locks a large table, a connection pool that exhausts under a new replica count, a query that was fast with ten thousand rows and is not fast with ten million. Understanding the storage layer turns those from mysteries into predictable outcomes.
31 live resources sit in this area, 27 free and 4 paid. PostgreSQL Documentation (FREE) is the reference that settles arguments, and PostgreSQL Tutorial (FREE) is a gentler guided path through the same material. Select Star SQL (FREE) teaches query reading through guided exercises, and PostgreSQL Exercises (FREE) gives you practice on real schemas.
For how a database engine actually behaves, CMU 15-445 Intro to Database Systems (FREE) is a full university course on storage, indexing, and concurrency, and it explains why a vacuum, a lock, or an index choice shows up as a latency graph in your dashboard. DuckDB Documentation (FREE) is a useful contrast because it shows an analytical engine designed for a completely different workload.
Full Stack Open (FREE) is the practical bridge from a backend service to the pipeline that ships it, and MongoDB University (FREE) covers the document model for teams that use it. DB Fiddle (FREE) is a browser SQL sandbox for testing a migration statement before it touches anything real.
The route from laptop to on-call
The stages below run from the machine on your desk to the shift where you are the person who gets called. Each one ends with an artifact, because this trade hires on evidence of operation rather than on completion certificates.
Stage one: become fluent on a Linux box. Install a virtual machine or a cheap cloud instance and live in it for a month. Users and permissions, processes, systemd units, logs, disk, and networking. Linux Foundation: Introduction to Linux (LFS101) (FREE) is the structured course, DigitalOcean Community Tutorials (FREE) answers the specific server questions that come up along the way, and OverTheWire Bandit (FREE) is the drill that makes the shell automatic. Done means you have provisioned a server, disabled password login, run a service under systemd, and diagnosed a failure from logs alone.
Stage two: put every change through a pipeline. Learn Git properly, then build one workflow that runs on every push: lint, test, build, deploy to a staging environment. Learn what a runner is, how secrets are injected, and why a cache key decides whether your build takes ninety seconds or nine minutes. Learn Git Branching (FREE) covers the history mechanics, and GitHub Actions Documentation (FREE) plus GitHub Skills (FREE) cover the automation. Done means a push to the main branch reaches staging with no manual step and a failed test blocks the merge.
Stage three: learn containers as a packaging format, not a buzzword. Build an image for a small service, keep it minimal, and run a three-service stack with a database. Then climb to orchestration, which is where most of the confusion lives. Docker Curriculum (FREE) and Docker Get Started (FREE) cover the fundamentals, and Play with Docker (FREE) gives you a lab in a browser tab.
Orchestration should be learned twice. First with Kubernetes Basics Tutorial (FREE), which gets a workload running and explains the objects. Then, when you want to understand what the managed service is doing for you, Kubernetes the Hard Way (FREE) builds a cluster from components on virtual machines. Done means a deployment with a readiness probe, a resource limit, and a rollback you have actually performed.
Stage four: define infrastructure in files and prove it by destroying it. Manual cloud setup is knowledge that lives in one person's memory. Infrastructure as code is knowledge that survives them. Learn one tool deeply enough to create a network, a compute instance, a database, and permissions, then delete the whole environment and rebuild it from the repository. Ansible Resources (FREE) covers configuration management for the parts a provisioning tool should not own, and Microsoft Learn (FREE) is a large free library for the cloud fundamentals that transfer between vendors. DevOps Roadmap (FREE) is a useful checklist of the pieces you have not touched.
If your employer uses a specific cloud, the vendor's own material is worth the money at this stage: AWS Skill Builder (PAID) or Google Cloud Training (PAID), paired with KodeKloud (PAID) for graded labs. Done means a repository that creates a working environment from nothing, plus a documented teardown that does not leave orphaned resources behind.
Stage five: make the system legible. Instrument one service properly. Requests, errors, latency, saturation. Then write one alert that fires on a symptom a user would notice, and one runbook that tells a tired person what to check first. Google Site Reliability Engineering Book (FREE) supplies the reasoning behind service level objectives and error budgets, and DevOpsCube (FREE) has practical material on monitoring stacks and pipelines.
Add the database half here, because this is where it bites. Read PostgreSQL Documentation (FREE) on locking, connections, and backups, and take CMU 15-445 Intro to Database Systems (FREE) if you want the engine-level explanation. Done means a dashboard someone else can read, an alert that is not noise, and a backup you have restored into a scratch environment.
Stage six: take a rotation. On-call is a skill and the only way to learn it is to hold the pager with someone experienced behind you. Before that, learn the security basics that stop an incident from becoming a breach: OWASP Top 10 (FREE), secrets management, least privilege, and image provenance. Read two postmortems a week from public incident reports. Done means you have handled a real failure end to end, written the timeline, and changed something so it cannot happen the same way again.
The order is deliberate. Linux first because everything else is a layer on it. Pipelines before containers because automation is what makes container experiments repeatable. Orchestration before infrastructure as code, because you cannot codify a system you do not understand. Observability and databases before on-call, because the rotation will expose every gap you left.
Lab time, certifications, and the real bill
Most of this trade can be learned for nothing. The free material above covers Linux, containers, orchestration, pipelines, reliability theory, database fundamentals, and the security basics. What costs money is lab hours at scale, cloud resources that are not on a free tier, and the structured paths that keep a working adult on schedule.
Cloud bills are the line item beginners forget. A three-node cluster running for a month is real money, and a forgotten load balancer can quietly cost more than a course. Set a budget alert on day one, destroy environments when you finish an exercise, and prefer the free lab platforms for anything exploratory. Play with Docker (FREE), Killercoda (FREE), and KodeKloud DevOps Free Labs (FREE) exist precisely so you do not have to pay to break something.
Certifications are worth what a specific employer says they are worth. In some organisations and some countries they clear a hiring filter, particularly for cloud roles in large enterprises and for government-adjacent work. They are weak evidence of operational judgment, because a certificate proves you can answer questions about a service, not that you have restored a database under pressure. The honest sequencing is to build the artifact first and take the certificate when a job application or a client asks for it, not to collect certificates in the hope that confidence follows.
Time expectations. Someone with a development background can be useful in a pipeline within two to three months of part-time study. Someone arriving without any systems experience should expect six to nine months, and the last third of that is not study, it is operating something with real users. The first job usually comes from a team that already knows you, or from a small company that needs one person to own delivery and cannot afford a platform team. That job will be messier than the roadmap and more educational than any of it.
Paid subscription judgment: buy one lab platform at a time and cancel it when the labs stop being the bottleneck. The pattern that wastes money is three subscriptions running in parallel while none of them gets used, which is common because buying feels like progress.
Habits that break at scale
The first is clicking in the console and calling it infrastructure. A resource created by hand is a resource nobody can rebuild, and the drift it creates is invisible until the day you need to recreate the environment. If you must click to explore, write the code to reproduce it the same week or delete the resource. The repository has to be the truth.
The second is alerting on causes instead of symptoms. CPU above eighty percent is not an incident, and a page for it trains everyone to ignore pages. Alert on what a user experiences: error rate, latency, failed logins, queue depth, certificate expiry. Everything else belongs on a dashboard that a human reads during working hours.
The third is long-lived credentials. A key that never rotates is a key that will eventually appear somewhere it should not, and the pipeline is the easiest place for that to happen. Prefer short-lived tokens issued by the platform, scope each identity to one job, and rotate anything that must persist. If a secret has ever been printed in a log, treat it as compromised rather than hoping.
The fourth is a deploy with no way back. Every release needs a previous version that can be restored in one action, and a database migration that can run against the old code for at least one release. Teams that cannot roll back deploy less often, and deploying less often makes each release riskier. Small, reversible releases are a safety property, not a speed preference.
The fifth is an untested backup. A backup job that reports success has proven that a file was written. It has not proven that the file can restore a service. Restore into a scratch environment on a schedule, time it, and write down what broke. The first restore is always slower and messier than the plan assumed.
The sixth is a pipeline only one person understands. That person is a single point of failure, and they will eventually go on holiday. Documentation that names each stage, each secret, each environment, and each manual approval is part of the deliverable. A runbook written during a calm week is worth more than ten written during an incident.
After the first on-call rotation
Go deeper in the areas this roadmap rests on: DevOps & Cloud for delivery and infrastructure, Cyber Security for the attack paths that touch a pipeline, Software Engineering for the code you will read, and Databases & Backend for the layer that decides whether a deploy is safe.
Compare the neighbouring roles before you commit to a title. Cloud Architect is the design-side move once you have operated enough systems to know what fails. Full-Stack Developer is the build-side neighbour, and Product Manager is where reliability arguments turn into prioritisation arguments. The full index is at Browse by profession.
One action for this week: take any script or manual process you repeat, put it in a repository, and make it run the same way twice. Then break it on purpose and fix it. That loop is the whole job in miniature, and it costs nothing but an evening.
FAQ
Do I have to learn Kubernetes to get a DevOps job?
No, and learning it badly is worse than not learning it. Plenty of teams run containers on a managed platform, a few virtual machines, or a serverless stack, and they need people who can build a reliable pipeline far more than they need cluster operators. Learn containers first, then orchestration if the jobs you want list it. When you do learn it, learn the objects and the failure modes rather than the commands.
Can I move into DevOps without a systems administration background?
Yes, and the most common route is from development. What transfers is the ability to read code, debug systematically, and understand how an application fails. What you must add is the operating system, networking, and the habit of thinking about failure before it happens. The stages above assume that background. If you arrive from support or testing, the same route works with more time on stage one.
Which cloud should I learn first?
The one used by the employers or clients you can actually reach. The concepts transfer between vendors far better than the service names do, and every hiring manager knows that. Learn one cloud deeply enough to build a network, a compute service, a managed database, and identity, then treat the second cloud as a vocabulary exercise rather than a second career. Vendor-neutral fundamentals are the part that keeps paying.
Are certifications worth the money?
They are worth it when a specific job requires one, and they are a poor substitute for operating something. A certificate can clear a filter in a large organisation, and it can satisfy a client's procurement rules. It cannot answer the interview question about the worst outage you handled. Build the artifact, then buy the certificate if a real opportunity asks for it.
How much coding does this job involve?
More than the job description suggests and less than a software engineering role. You will write workflow files, scripts, small services, policy definitions, and query fragments. You will read far more code than you write. The skill that matters is being able to make a small, safe change in someone else's repository and prove it works, which is why the software engineering area appears in this roadmap at all.
How do I practise without a job that has production systems?
Build a small system and operate it as if it mattered. One service, one database, one pipeline, one dashboard, one alert, one backup, one restore, one deliberate outage that you cause and then fix while writing the timeline. Publish the postmortem. That single loop covers more of the job than any course, and it gives you something concrete to discuss in an interview besides theory.
SkillCache Editors · Updated November 13, 2026
