Cloud Engineer Roadmap With Free Resources

Cloud Engineer Roadmap With Free Resources

A cloud engineer designs, builds, secures, and pays the bill for the infrastructure that applications run on, which day to day means networking topology, identity policies, managed service selection, and cost investigations. Realistic time to employable is eight to fourteen months from a technical background, or two to three years starting from nothing.

Updated for 2026. Salary figures are indicative and move quarterly.

What This Role Actually Does

The job ad promises architecture and innovation.

The actual week: an IAM policy is too permissive and you spend Monday narrowing it without breaking four services. Tuesday, the bill jumped 30 percent and it turns out a team enabled detailed logging on a high-traffic bucket. Wednesday, you design a VPC layout for a new environment and argue about subnet sizing. Thursday, a managed database version reaches end of support and needs a migration plan. Friday, someone needs cross-account access and you write the trust policy.

The pattern: cloud engineering is roughly one-third network design, one-third identity and security, and one-third cost and lifecycle management. Only a small slice is the greenfield architecture diagram people picture.

What people wrongly imagine it is: clicking through a console to launch servers. Console clicking is what you do while learning; production work is written as code, reviewed in a pull request, and applied by a pipeline. The second misconception is that "the cloud handles scaling for you." It handles the mechanism. Deciding what should scale, at what threshold, and what it will cost is the job.

The third: that cloud engineers stop needing to understand networking because the provider abstracts it. The opposite is true. Route tables, security groups, NAT, and DNS are where most of your debugging time goes.

Choosing a Platform

The decision rule: open a job board, filter to your city or your target remote market, and count postings. Learn whichever platform wins that count. Everything else is preference.

Concepts transfer. A person fluent in AWS networking learns Azure networking in a few weeks, because subnets, routing, and firewall rules are the same ideas under different names. This is why depth beats breadth.

The Roadmap

Six stages, ordered by dependency.

Stage 1 — Linux, Networking, and Scripting Foundations

What to learn: Linux filesystem, permissions, processes, systemd, and ssh. Networking: TCP/IP, DNS, HTTP and TLS, CIDR notation and subnetting, NAT, firewalls, load balancers. Scripting: Bash for glue work and Python for anything longer than twenty lines.

Subnetting is the single highest-leverage topic here. Almost every cloud networking failure traces back to an address range that overlaps or is too small.

Realistic time: 8–12 weeks at 8–10 hours per week.

Free resources by name: Linux Journey, OverTheWire Bandit, freeCodeCamp's Linux and Python courses, the Cloudflare Learning Center for DNS and TLS explanations, and Julia Evans' free networking material. Professor Messer's free CompTIA Network+ video series is an excellent free networking curriculum even if you never sit the exam.

Portfolio project: a Python script that takes a CIDR block and outputs a valid subnet plan for a three-tier network, plus a written explanation of why you sized each tier as you did.

How you know you are done: you can subnet 10.0.0.0/16 into public, private, and database tiers across three availability zones on paper, without a calculator.

Stage 2 — Cloud Core Services on One Platform

What to learn: compute (virtual machines and the provider's serverless function service), object storage and its storage classes, block storage, the virtual network layer including subnets, route tables, security groups, gateways, and load balancers, managed relational and NoSQL databases, and DNS at the provider level.

Realistic time: 8–10 weeks.

Free resources by name: AWS Skill Builder free digital courses and the AWS Free Tier; Microsoft Learn for Azure, which is free, structured, and includes free sandbox environments; Google Cloud Skills Boost free tier; and A Cloud Guru's free-tier course selection. freeCodeCamp publishes multi-hour cloud certification courses at no cost.

Set a billing alert at one dollar before your first resource. Then a second at ten.

Portfolio project: deploy a two-tier web application — a public-facing application server and a private managed database — with a load balancer, a properly segmented VPC, and no database exposure to the internet. Document the architecture with a diagram.

How you know you are done: you can explain, in terms of route tables and gateways, why your private subnet reaches the internet for updates but the internet cannot reach it.

Stage 3 — Identity, Security, and Cost

What to learn: the provider's identity system in depth — users, roles, policies, trust relationships, assumed roles, and cross-account access. Encryption at rest and in transit, key management, secrets storage, and the shared responsibility model. Then cost: pricing models, reserved and committed-use discounts, spot or preemptible instances, budgets, tagging strategy, and cost allocation.

This stage is what separates a cloud engineer from someone who can launch resources. It is also where interviews concentrate.

Realistic time: 6–8 weeks.

Free resources by name: the provider's own well-architected framework documentation (AWS Well-Architected Framework, Azure Well-Architected Framework, Google Cloud Architecture Framework) — all free and all directly interview-relevant. Add the OWASP top ten and the CIS Benchmarks documentation for hardening baselines.

Portfolio project: write a least-privilege policy set for a three-role application (deployer, application runtime, read-only auditor), plus a tagging and budget scheme, and a short written cost model estimating monthly spend for your Stage 2 architecture at two traffic levels.

How you know you are done: you can explain why an over-broad wildcard permission is a problem in concrete attack terms, not just as a best practice.

Stage 4 — Infrastructure as Code

What to learn: Terraform — providers, resources, variables, outputs, modules, remote state with locking, workspaces, plan versus apply, and importing existing infrastructure. Then the provider-native option for context: AWS CloudFormation, Azure Bicep, or Google Cloud Deployment Manager. Add configuration management with Ansible at a basic level.

Terraform is the market standard across all three clouds. Learn it first, learn the native tool second.

Realistic time: 8–12 weeks.

Free resources by name: the official Terraform documentation and HashiCorp's free tutorial track, KodeKloud's free Terraform labs, and the provider's own IaC documentation.

Portfolio project: rebuild your entire Stage 2 and 3 environment in Terraform with modules, remote state, and variables for environment differentiation. Then run terraform destroy and terraform apply to prove the whole thing reconstructs from nothing.

How you know you are done: your infrastructure exists only as code, and the console is where you verify, never where you create.

Stage 5 — Automation, Containers, and Delivery

What to learn: Docker — images, layers, multi-stage builds, registries. CI/CD with GitHub Actions or the provider's native pipeline service, including secrets handling, environments, and approval gates. The provider's managed container services and its managed Kubernetes offering at a working level. Serverless patterns and when they are cheaper than always-on compute.

Realistic time: 8–12 weeks.

Free resources by name: official Docker documentation and Play with Docker, GitHub Actions documentation, KodeKloud free Docker and Kubernetes labs, and the official Kubernetes tutorials with kind or minikube locally so you pay nothing.

Portfolio project: a pipeline that builds a container image, scans it, pushes it to a registry, runs terraform plan on pull request, and deploys to a staging environment on merge — with a manual approval gate before production.

How you know you are done: you push a commit and a running application updates without you touching a console or a terminal.

Stage 6 — Reliability, Monitoring, and Architecture Judgment

What to learn: the provider's monitoring and logging services, Prometheus and Grafana as the vendor-neutral pair, alerting that is actionable rather than noisy, high availability across availability zones, backup and restore, disaster recovery objectives (RTO and RPO), and multi-region trade-offs. Then architecture judgment: when a managed service beats self-hosting, when serverless costs more than a server, and how to say no to complexity.

Realistic time: 8–12 weeks, and honestly this stage never ends.

Free resources by name: the well-architected framework reliability pillars, Prometheus and Grafana official documentation, the free Google SRE Book available online, and provider architecture centre reference diagrams.

Portfolio project: take your existing environment, add multi-AZ redundancy, automated backups with a documented restore procedure you have actually executed, dashboards showing real metrics, and one alert that fires on a genuine failure condition. Write a one-page disaster recovery plan.

How you know you are done: you have restored from a backup successfully, not merely configured one.

Salary and Job Titles

Ranges below are indicative USD figures consistent with aggregated data of the kind published by Levels.fyi, Glassdoor, the Stack Overflow Developer Survey, and US Bureau of Labor Statistics figures for related computer and information technology occupations. Treat them as ballpark bands. They vary sharply by metro and employer tier and they move quarterly.

United States (USD, base salary)

Cloud security and FinOps specialisations command a premium over generalist cloud engineering at the same experience level, because the supply of people who understand both cloud infrastructure and their specialism is thin.

Canada (CAD, base salary)

Toronto, Vancouver, and Calgary anchor the top of the Canadian range. USD conversions are approximate and move with the exchange rate.

Say this out loud before negotiating: these are indicative aggregates, not offers. Check current data for your exact city, level, and company before quoting a number.

Who Should Not Take This Path

You want to write application code all day. Cloud engineering is configuration, policy, and architecture. You will write scripts and modules, not features. People who genuinely love programming often find this hollow.

You are uncomfortable owning money. A misconfiguration here has a dollar figure attached, and someone will ask you about it in a meeting. If financial responsibility for your mistakes creates disproportionate anxiety, this is a hard seat.

You dislike reading documentation. The cloud providers ship changes weekly. There is no textbook that stays current. Roughly a fifth of the job is reading release notes and provider docs.

You need visible credit. Successful cloud work is a system nobody notices. Attention arrives only during outages.

You want to avoid security work. Identity and access management is not a specialisation you can dodge here — it is a daily activity, and it is tedious, precise, and unforgiving.

You are hoping the certification alone gets you a job. It will not, and people who bet on that path lose six months learning it the expensive way.

The Five Mistakes

1. Learning all three clouds simultaneously. It feels like hedging and reads as unfocused. Depth in one platform demonstrates competence and transfers laterally in weeks. Breadth across three at a shallow level demonstrates nothing an interviewer can test.

2. Skipping networking because "the cloud handles it." It does not. Subnets, route tables, security groups, and DNS are where your debugging hours go, and every architecture interview is a networking interview wearing a different hat.

3. Never setting a billing alert. The first surprise bill is a rite of passage that costs real money and often ends someone's practice entirely. Set the alert before the first resource, then destroy everything at the end of each session.

4. Certification-first sequencing. Studying for the exam before you have built anything produces recall without judgment, and it collapses in the first scenario question. Build first, sit the exam second, and the exam becomes easy rather than a project of its own.

5. Building only in the console. Console-built infrastructure is unreviewable, unrepeatable, and undocumentable. It also teaches habits you have to unlearn. Move to Terraform as early as Stage 4 and never go back.

Print This Section

CLOUD ENGINEER ROADMAP — STAGE SUMMARY

0. PICK ONE PLATFORM
   Count job postings in your target market. Learn the winner.
   AWS = most jobs | Azure = enterprise/gov | GCP = data & ML

1. LINUX + NETWORKING + SCRIPTING     8-12 weeks
   Permissions, systemd, TCP/IP, DNS, CIDR, Bash, Python
   Project: subnet planner script with written rationale
   Done when: you can subnet a /16 across 3 AZs on paper

2. CLOUD CORE SERVICES                8-10 weeks
   Compute, object storage, VPC, managed DB, load balancers
   SET A BILLING ALERT AT $1 BEFORE THE FIRST RESOURCE
   Project: two-tier app, private DB, documented diagram
   Done when: you can explain private subnet egress

3. IDENTITY + SECURITY + COST         6-8 weeks
   IAM roles/policies/trust, KMS, secrets, tagging, budgets
   Project: least-privilege policy set + monthly cost model
   Done when: you can attack your own wildcard permission

4. INFRASTRUCTURE AS CODE             8-12 weeks
   Terraform modules, remote state, import; native IaC second
   Project: whole environment as code, destroy and rebuild
   Done when: the console is for verifying, never creating

5. CONTAINERS + CI/CD                 8-12 weeks
   Docker multi-stage, registries, pipelines, managed K8s
   Project: build-scan-plan-deploy pipeline with approval gate
   Done when: a git push updates a running app, hands off

6. RELIABILITY + MONITORING           8-12 weeks
   Multi-AZ, backups, RTO/RPO, Prometheus, Grafana, alerting
   Project: restore from backup + DR plan + one real alert
   Done when: you have RESTORED a backup, not just made one

TOTAL: 8-14 months from a technical background
       2-3 years from zero
Certifications: one associate-level, after the projects.

🔗 Next: the DevOps Engineer Roadmap is the natural sibling track once Stage 5 clicks, and the Networking Cheat Sheet covers Stage 1's hardest topic. Compare every track side by side in Tech Career Roadmaps Compared.