Roadmaps
Cloud & Infrastructure Engineer
From the command line to production you would be willing to be paged for.
The path from "I can use a computer" to "I run the systems a business depends on". It starts at the shell and the network because everything above them is a lie you have not debugged yet, then climbs through Linux and a cloud platform, adds automation, and ends on the part most people skip: operating what you built.
What you can do at the end
- Work on a Linux server without pasting commands you do not understand.
- Follow a request end to end — port, DNS, TLS, proxy, application — and say where it actually failed.
- Provision compute, storage and networking in a cloud account you can explain line by line.
- Describe infrastructure as code, so a second environment is a command rather than a weekend.
- Have monitoring, backups and access control in place before something breaks, instead of after.
Ticking a step is remembered in this browser only — there is no account and nothing is sent anywhere.
Foundations
The layer underneath everything else. Skipping it is why cloud problems look like magic — and why they then take three days instead of twenty minutes.
How a program actually runs
CPU, memory, processes, files. Enough to know that "it is slow" has more than one answer.
Planned in the LibraryOperating SystemsThe command line
Files, pipes, redirects, permissions, processes. Every server you ever touch will hand you a shell first.
Planned in the LibraryLinux & ServersGit, properly
Branches, merges and commits that read like a sentence. Not "wip" at 2am on the main branch.
Planned in the LibraryVersion ControlOne scripting language
Python or Go — enough to walk a directory, call an API and parse JSON without a notebook.
Planned in the LibraryAutomation & ScriptingNetworks: addresses, ports, packets
IP, subnets, TCP versus UDP, and why "connection refused" and "timed out" mean completely different things.
Planned in the LibraryComputer NetworksHTTP and DNS
The two protocols you will debug for the rest of your career: request, response and headers, plus the name lookup that happens before either.
After Networks: addresses, ports, packets
Planned in the LibraryNetworking & DNSTLS, in enough detail
OptionalCertificates, chains, expiry, and the three ways a handshake fails. You will spend real hours here.
After HTTP and DNS
Linux and servers
The platform under every cloud. Own one machine end to end — users, services, logs, disks — before you let a provider hide it from you.
Users, groups and permissions
Who may do what, sudo, ownership, umask — and why the wrong owner is the reason a web server says 403.
Planned in the LibraryLinux & ServersServices and systemd
Units, restarts, dependencies and `journalctl`. This is how anything stays running.
Planned in the LibraryLinux & ServersMeasuring a machine
top, free, df, ss, iostat. Find the bottleneck before you restart the thing and lose the evidence.
Planned in the LibraryMonitoring & ObservabilityInstalling and pinning software
apt or dnf, repositories, versions, and keeping a machine reproducible a year later.
Put one real thing online
A reverse proxy, an application process, a domain you own and a certificate that renews itself.
After Services and systemd
Planned in the LibraryWeb Hosting & DeploymentContainers
Images, layers, volumes, networking — and the honest difference between a container and a virtual machine.
Compose a small stack
OptionalApplication, database and proxy described in one file you can rebuild from scratch on a clean host.
After Containers
Close the obvious doors
Key-only SSH, a firewall with three rules, unattended upgrades. Cheap, and it works.
Planned in the LibrarySecurity & Access
A cloud platform
One provider, learned properly. The second provider is a week of reading once the first is not a mystery — and the credentials from the first course are usually enough for two.
Accounts, projects and cost control
Projects, IAM boundaries, budgets and alerts. Know what you are paying for before the invoice, not after.
Planned in the LibraryCloud FundamentalsIdentities and roles
Users, service accounts, roles and policies. Least privilege from the first day, because retrofitting it never happens.
Planned in the LibrarySecurity & AccessCompute you can reason about
VMs, managed containers and serverless functions — what each one hides from you, and what it charges for.
Planned in the LibraryCompute & StorageStorage classes and their trade-offs
Object, block and file storage; durability, latency, price and lifecycle rules that quietly save money.
After Compute you can reason about
Planned in the LibraryCompute & StorageNetworking inside a cloud
VPCs, subnets, routes, security groups, private versus public. Where most real outages are born.
Planned in the LibraryNetworking & DNSManaged databases
Backups, failover, connection limits, versions — and when a managed service beats a database on a VM.
Planned in the LibraryThe Relational Model & SQLDNS and certificates at the edge
Delegation, records kept in version control, automated certificates, and what a CDN changes about caching.
After Networking inside a cloud
Planned in the LibraryWeb Hosting & DeploymentPick one and commit to it
OptionalA free tier or a small paid account, one project, everything you build from here on inside it.
Automation and infrastructure as code
The point where you stop being the person who clicks and become the person who describes. Everything here is about making a change reviewable, repeatable and reversible.
Declarative infrastructure
The idea before the tool: describe the end state, let something else work out the steps. Compare it with a shell script that half-finished.
Planned in the LibraryAutomation & ScriptingTerraform or OpenTofu
Providers, resources, plan and apply. Read the plan properly — a delete is printed in the same font as a create.
After Declarative infrastructure
Planned in the LibraryAutomation & ScriptingState, modules and environments
AdvancedRemote state, locking, small reusable modules — and why one workspace shared between staging and production is a trap.
After Terraform or OpenTofu
CI/CD pipelines
Build, test and deploy on every push; a pipeline that can roll back; secrets that never live in the repository.
After Terraform or OpenTofu
Configuration management
OptionalAnsible, cloud-init or a golden image: making a fresh machine identical to the last one, on purpose.
After CI/CD pipelines
Containers in production
AdvancedKubernetes is the default answer and often the wrong one. Learn what problem it solves before you adopt it.
After CI/CD pipelines
Secrets and credentials
Where they live, how they rotate, who can read them — and why the environment file in git is an incident, not a mistake.
Planned in the LibrarySecurity & Access
Operate it
The half of the job that separates a hobby from a system. It is also the half that hires you, because it is the half most candidates cannot describe.
Monitoring, logs and traces
Metrics that answer "is it healthy", logs that answer "what changed", alerts a human can act on at 3am.
Planned in the LibraryMonitoring & ObservabilityBackups you have restored
A backup nobody has restored is a rumour. Schedule one, restore it, and time how long it took.
Planned in the LibraryBackups & RecoveryIncidents and on-call
Runbooks, blameless reviews, and what to do in the first ten minutes — communicate, stabilise, then investigate.
After Monitoring, logs and traces
Hardening the attack surface
Patch cadence, exposed ports, dependency updates, and the small number of mistakes that cause most breaches.
Planned in the LibrarySecurity & AccessA cost review
Right-sizing, idle resources, egress and retention. Unglamorous, and the fastest way to be trusted with more.
Write it down
A diagram nobody has to guess at and a README that says how to restore this from nothing on a bad day.
Choose a direction
OptionalFrom here the paths split: security, data platform, Kubernetes-heavy platform engineering, or site reliability.
After Incidents and on-call · Write it down