Cloud engineer roadmap

The most common gap in self-taught cloud engineers is networking. Everything in cloud infrastructure sits on it, and without it you are pattern-matching tutorials rather than reasoning. When a service cannot reach another service, networking knowledge is what turns a day of guessing into ten minutes of diagnosis.

You do not need a networking qualification. You need to genuinely understand addressing, subnets, routing, DNS resolution and how a packet gets from one machine to another — and to be able to explain why a connection is failing rather than trying settings until one works.

The test of whether you have enough is whether you can predict what will break before you change something. Engineers who can say that widening a subnet will not fix a routing problem, and explain why, are reasoning; everyone else is experimenting in production.

• IP addressing and subnetting, well enough to plan a range
• Routing tables and gateways
• DNS resolution end to end, including why caching confuses people
• Firewalls, security groups and the difference between them
• TLS — what it protects and where it terminates
• Load balancing at different layers

Comfortable command-line Linux is assumed rather than requested. Processes, permissions, systemd, logs, disk and memory diagnosis. You will spend a lot of time on machines you cannot access through any interface but a terminal.

The specific habit worth building is diagnosis under pressure: a service is down, you have a shell, find out why. That is a practised skill, and it is what a troubleshooting interview round is checking for.

Build the habit of working from evidence rather than from memory of what usually goes wrong. Check what is listening, check what the logs actually say, check whether the disk is full — in that order, every time, rather than guessing at the cause you saw last month.

Pick the provider with the strongest hiring market where you want to work and learn it properly. Learning three shallowly is a common and expensive mistake — you end up unable to solve a real problem in any of them.

The services that matter are fewer than the catalogue suggests. Compute, storage, networking, identity, managed databases and the monitoring stack cover the overwhelming majority of real work. Identity and access management deserves particular attention, because it is where both the hardest bugs and the worst breaches originate.

Resist the pull of the service catalogue. Providers release dozens of products a year and almost none of them appear in job requirements; a candidate who knows the core six properly is more employable than one who has touched thirty.

• Compute — virtual machines, containers, serverless functions
• Storage — object, block and their durability and cost characteristics
• Virtual networking — the cloud expression of what you learned above
• Identity and access management, studied properly rather than copied
• Managed databases and their backup and failover behaviour
• Monitoring, logging and alerting

Clicking through a console makes you a cloud user. Defining infrastructure in code that can be reviewed, versioned and reproduced makes you a cloud engineer. Employers screen for this explicitly, and its absence is disqualifying at anything above junior level.

Learn one tool well. What matters is understanding state, drift between declared and actual infrastructure, module structure and how to make changes safely in an environment people depend on. Applying a change that destroys and recreates a database teaches this lesson memorably.

Learn to read a plan before applying it, and to be suspicious of any plan proposing to replace rather than update a stateful resource. That single habit prevents the most common category of self-inflicted production incident in this discipline.

Cloud engineers who can reduce a bill are valued disproportionately, because the saving is measurable and recurring. This is one of the few areas where an individual contributor can point to a figure and have it believed.

Learn where money actually goes: idle resources nobody owns, oversized instances chosen defensively, data transfer between regions, storage tiers never reviewed. A documented cost reduction is one of the strongest items you can carry into an interview.

Cross-region data transfer deserves a specific mention because it surprises people. It is easy to design an architecture that moves large volumes between regions without noticing, and the charge appears as a line nobody can immediately attribute to a decision.

An associate-level certification is genuinely useful when you have no cloud experience on your CV, because it gets you past automated filters and signals baseline familiarity. Beyond that first one, returns fall quickly.

Nobody senior is impressed by a stack of certificates without corresponding experience, and some interviewers treat a long list with mild suspicion. One certification plus one real system you built and can discuss beats four certifications and nothing built.

The exception is consultancies and partner organisations, where certification counts are a commercial requirement. If you are targeting those specifically, the calculation genuinely changes and more certifications have direct value.

Deploy something real, defined entirely in code, with monitoring, a deployment pipeline and a documented recovery procedure. It does not need to be large. It needs to be complete, and you need to be able to explain every decision in it.

Then break it deliberately and fix it. Delete a resource and restore it. Explaining a failure you caused and recovered from is more convincing than describing a system that has never been tested.

Write the recovery procedure before you need it, then follow it exactly during the deliberate break. Discovering that your own runbook is wrong is the most useful hour in the whole exercise, and it is a story that lands well in an interview.