Cloud engineer roadmap
Every stage applies. It starts with Linux and networking, moves through compute, storage, IAM, VPCs, containers and infrastructure as code, and ends with observability, security, cost and designs that survive losing a region.
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 networking
Cloud servers are mostly Linux machines you reach through an API. Before learning a provider, get comfortable with processes, the shell, and the TCP, DNS and TLS layers that every request passes through.
Core: Linux and the shell
Filesystems, permissions, processes, pipes and grep. Every instance you launch runs this, and many strange production problems are explained at this level.
CodexOperating systems SimulatorLinux boot Outside linkGNU Bash manual
Core: TCP/IP and HTTP
Handshakes, ports, timeouts and retransmits, and the HTTP request and response on top. When a service is slow, the cause is often in one of these two layers.
Core: DNS
Records, TTLs, resolvers and caching. Cloud platforms use DNS for service discovery, failover and shifting traffic, and a wrong record can stay cached until its TTL expires.
Core: TLS and HTTPS
Certificates, the handshake and the chain of trust. Nearly all cloud traffic uses TLS, and expired certificates or broken chains are a common cause of outages.
GuideHow HTTPS works CodexSecurity Outside linkLet's Encrypt docs
Recommended: SSH and remote machines
Key pairs, agents, jump hosts and tunnels: how you reach and work on a remote server, and how to do it safely.
Stage 2
Core cloud services
Under the long list of services, a cloud provider sells three basic things: machines, storage, and an identity system that controls who can use them. This stage uses AWS as the example, and the same ideas apply on Google Cloud and Azure.
Core: How a cloud provider is organised
Regions, availability zones, accounts, and the API behind the console. Later stages assume this vocabulary.
CodexCloud CodexAWS foundations Outside linkAWS documentation
Core: Compute: VMs, autoscaling and serverless
Instances, machine images, autoscaling groups, and functions that run only when called. The options range from a server you manage to a handler you upload, with different costs and limits at each end.
CodexCloud compute CodexEC2, EBS & AMIs CodexLambda execution model
Core: Storage: object, block and file
Object storage for files and blobs, block volumes that act as disks, and file systems shared between machines. Object storage such as S3 is the one you will use most.
CodexCloud storage CodexS3 internals SimulatorS3 prefix sharding
Core: IAM
Principals, policies, roles, and the rules that decide whether each API call is allowed. Many cloud breaches come from a policy that grants too much, rather than from an exploit.
CodexCloud identity & access CodexAdvanced IAM Outside linkAWS IAM best practices
Recommended: Managed databases
Managed relational databases such as RDS, and managed NoSQL such as DynamoDB. You pay more and give up some control, and the provider handles backups, patching and failover.
CodexCloud databases CodexAurora & RDS CodexDynamoDB internals
Stage 3
VPCs and cloud networking
A VPC rebuilds the networking from the first stage as API objects: subnets, route tables, gateways and firewall rules. Plan the address ranges and layout early, because changing them under a running production system is slow and risky.
Core: VPCs, subnets and route tables
Address ranges, public and private subnets, and the route tables that decide where a packet goes next. You should be able to sketch your VPC layout without looking it up.
GuideVPC networking SimulatorVPC packet flow CodexCloud networking
Core: Security groups and network ACLs
Security groups are stateful firewalls attached to instances; network ACLs are stateless rules on subnets. Deny by default, open only the ports a workload needs, and review rule changes like code.
CodexVPCs on AWS GuideVPC networking Outside linkAWS VPC security best practices
Core: NAT and private connectivity
NAT gateways for outbound-only traffic, and VPC endpoints and peering to keep traffic off the public internet. Data transfer through these is also where unexpected networking charges come from.
GuideHow NAT works SimulatorVPC packet flow CodexCloud networking
Core: Load balancers
Layer 4 and layer 7 balancers, health checks, target groups and connection draining. When some requests fail and others succeed, check the load balancer early.
GuideHow load balancing works SimulatorLoad balancer CodexAWS load balancing
Recommended: Cloud DNS and traffic routing
Hosted zones, failover based on health checks, and weighted or latency-based routing. Services such as Route 53 give you basic global traffic control at low cost.
Stage 4
Containers and Kubernetes
A container image packages an application with what it needs to run. Kubernetes keeps the declared number of containers running and moves them when a node fails. Most cloud workloads ship this way, so learn how both work, not only the YAML.
Core: What a container is
A process with its own namespaces, cgroup limits and a layered filesystem, sharing the host kernel. This explains how images, isolation limits and privileged mode behave.
Core: Images, layers and the build cache
Each Dockerfile instruction becomes a cached layer. Put the steps that change least first and rebuilds take seconds; use multi-stage builds to keep images small.
SimulatorContainer layers Outside linkDockerfile reference Outside linkMulti-stage builds
Core: Pods and reconciliation
You declare the state you want and controllers keep working to reach it. Following one pod from
kubectl applyto a running container shows how the parts fit together.GuideHow a pod gets created CodexKubernetes Outside linkKubernetes concepts
Recommended: Services, ingress and cluster networking
How a Service gives short-lived pods a stable address, and how outside traffic reaches them. Newcomers often get stuck on this part.
GuideK8s networking GuideService discovery Outside linkKubernetes services
Recommended: Rollouts, scheduling and resource limits
Rolling updates, resource requests and limits, and what happens when a node runs out of memory. Requests set too high waste money; too low, and pods get evicted.
SimulatorK8s rollout SimulatorContainer scheduler SimulatorPod eviction
Stage 5
Infrastructure as code and CI/CD
Changes made in a console are hard to review, repeat or roll back. Terraform puts infrastructure in versioned code with a plan you read before applying, and a CI/CD pipeline makes releases routine.
Core: Terraform: plan and apply
Describe the end state, read the plan Terraform computes, then apply it. Reading the plan is how you catch a change that would delete something important.
Outside linkTerraform docs Outside linkTerraform tutorials CodexCloud
Core: State, backends and locking
Terraform records what it manages in a state file. On a team, keep it in a remote backend with locking so two people cannot apply at once.
Core: Modules and multiple environments
Reusable, parameterised modules instead of copied resource blocks, promoted through dev, staging and production.
Outside linkTerraform modules Outside linkTerraform workspaces
Core: CI/CD pipelines
Stages, artifacts, caching and checks that must pass. A passing build should mean the commit is safe to release, infrastructure changes included.
Outside linkGitHub Actions docs Outside linkGitLab CI/CD docs GuideHow Git works
Recommended: Deployment strategies
Blue-green, canary and rolling deploys, plus feature flags: ways to change production gradually and undo the change quickly.
SimulatorK8s rollout CodexSystem design Outside linkArgo Rollouts docs
Stage 6
Observability and reliability
Metrics, logs and traces show what a system is doing. SLOs and error budgets turn "reliable" into a number the team agreed on, and a practised incident process makes outages shorter.
Core: Metrics, logs and traces
Metrics are for alerting, logs are for investigating, and traces show where a request spent its time. Each answers different questions and costs different amounts to keep.
CodexObservability CodexLogs, metrics & traces Outside linkPrometheus docs
Core: SLIs, SLOs and error budgets
Pick a measure users notice and set a target. The gap between the target and 100% is the error budget: spend it on shipping, and when it runs out, the team agrees to focus on reliability.
Outside linkSRE Workbook: implementing SLOs Outside linkGoogle SRE Book CodexCloud observability
Core: Incident response and postmortems
Clear roles, one channel for updates, stopping the damage before finding the cause, and afterwards a blameless written review so the same failure is less likely to repeat.
Outside linkSRE Book: managing incidents Outside linkSRE Book: postmortem culture
Recommended: Alerting
Alert on symptoms users notice, route alerts by severity, and remove noisy ones. An alert that fires every hour gets ignored.
Outside linkPrometheus alerting Outside linkSRE Workbook: alerting on SLOs
Recommended: Distributed tracing and OpenTelemetry
Following one request across many services by passing a trace context along with it. Once there are more than a few services, it is the practical way to find the slow one.
Recommended: Resilience patterns
Timeouts, retries with backoff, circuit breakers and bulkheads, which stop one slow dependency from causing a wider outage.
Stage 7
Security and cost
Two common ways cloud projects go wrong are a role with too many permissions that leads to a breach, and a bill nobody can explain. Both improve when access and spending are visible, narrowly scoped and reviewed like code.
Core: Least-privilege IAM
Give each workload only the permissions it needs, use roles instead of long-lived access keys, and check who can assume which role. One wildcard policy can be enough for a breach.
CodexCloud identity & access CodexAdvanced IAM Outside linkAWS IAM best practices
Core: Encryption, KMS and secrets
Envelope encryption, key policies, and a secrets manager instead of environment files in a repository. Encrypt by default and write down the reason for any exception.
CodexKMS & secrets Outside linkAWS KMS concepts CodexSecurity
Core: The shared responsibility model
The provider secures its infrastructure, and you are responsible for how you configure what runs on it. Public buckets and open security groups expose far more data than new exploits do.
Core: Cost and FinOps
Compute, storage and data transfer make up most cloud bills. Tagging, right-sizing, and reserved or spot capacity keep it under control, and cost belongs on a dashboard like any other metric.
Stage 8
High availability, disaster recovery and multi-region
The earlier stages are about running one system well. This one covers what happens when an availability zone fails, traffic triples or a whole region goes down, and the queues, caches and CDNs that give you headroom before any of that.
Core: High availability and failure domains
Spread workloads across availability zones, remove single points of failure, and know how much breaks when one component fails. High availability is mostly a matter of layout.
CodexSystem design Outside linkAWS Well-Architected: reliability pillar CodexCloud
Core: Queues and asynchronous work
A queue between two services absorbs bursts, makes retries easier and lets each side deploy on its own. In return you accept eventual consistency and need to watch a dead-letter queue.
Core: Caching and CDNs
Serve static files from a CDN near users and cache frequently read data in the application. Latency removed at the edge never has to be fixed in the backend.
GuideHow a CDN works GuideHow caching works SimulatorCloudFront cache
Recommended: Disaster recovery
Backups you have tested by restoring them, agreed recovery time and recovery point objectives, and a strategy (backup and restore, pilot light, warm standby or active-active) that matches what downtime costs.
Outside linkAWS: disaster recovery workloads CodexMulti-region patterns
Recommended: Multi-region design
Replicating data, routing traffic between regions, and the consistency trade-offs of having writes in more than one place. Most problems in this roadmap get harder here.
CodexMulti-region patterns SimulatorCAP theorem CodexSystem design
After this roadmap
- Cloud in the CodexStudy pages on AWS, Google Cloud and Azure: compute, storage, networking, IAM, cost and multi-region patterns.
- SimulatorsVPC packet flow, S3 prefix sharding, Kubernetes rollouts and autoscaling, as models that run in the browser.
- How it worksGuides to DNS, NAT, VPC networking, CDNs and load balancing.