How to become a Cloud Engineer / Solutions Architect

A complete, honest roadmap for the skills cloud engineers and solutions architects actually use, from networking and core services through infrastructure as code, security, reliability, scaling, cost, containers, architecture trade-offs, communication, and AI. It runs top to bottom, foundational to advanced, so you always know what comes next. Free to read, no signup required.

How to use this: each step below is collapsed. Tap one to expand its details, skill pills, and guidance (only one opens at a time). Work down the spine in order; each stage assumes the ones above it. The cloud is learned by building on it, so use a real account as you go, because the concepts only stick once you’ve deployed them.

01
Cloud work rests on understanding what the cloud is and how networks connect it. Get these foundations solid before touching individual services.
What the cloud is: On-demand computing you rent rather than own, and the regions and availability zones it runs across.
Networking: IP, DNS, subnets, and routing, plus virtual networks, since almost everything in the cloud connects over them.
The shared responsibility model: What the cloud provider secures and operates, and what stays your job, a distinction that matters constantly.
How requests flow: Following a request from a user to a service and back, so you can design and debug real systems.
Cloud engineers lean toward building and operating cloud systems; solutions architects lean toward designing them and working with stakeholders. The roles share most of their foundations, which is why this roadmap covers both.
What the cloud isRegions & AZsNetworkingVPCShared responsibility
02
Every cloud offers the same building blocks under different names. Learn them deeply on one platform, since the concepts carry across all of them.
Compute: Virtual machines, containers, and serverless functions, and when each is the right way to run code.
Storage: Object storage, block storage, and their trade-offs in durability, speed, and cost.
Databases: Managed relational and NoSQL databases, and choosing the right one for a workload.
One platform, deeply: AWS, Azure, or Google Cloud. Get genuinely comfortable with one; the ideas transfer to the others.
ComputeStorageDatabasesAWS / Azure / GCPServerless
03
You operate the cloud through command lines and scripts far more than through a web console. Comfort here makes you faster and more reliable.
Linux basics: The command line, processes, and permissions, since most cloud workloads run on Linux.
The cloud CLI: Driving cloud resources from the command line, which is faster and far more repeatable than clicking.
Scripting: Automating routine tasks with shell and a language like Python.
LinuxCloud CLIScriptingAutomation
04
Clicking through a console doesn’t scale and can’t be trusted for anything real. Describing infrastructure as code makes it repeatable, reviewable, and recoverable.
Declarative provisioning: Defining your infrastructure in code with tools like Terraform or CloudFormation, then applying it.
Reproducible environments: Recreating whole environments on demand, so dev, staging, and production genuinely match.
Reviewable changes: Treating infrastructure changes like code: versioned, reviewed, and safe to roll back.
TerraformCloudFormationDeclarative infraReproducible environments
05
Security in the cloud is mostly about who can do what. Getting identity and access right is one of the most important and most commonly mishandled parts of the job.
Identity & access: IAM users, roles, and policies, and granting the least privilege needed rather than broad access.
Encryption: Protecting data in transit and at rest, and managing keys properly.
Network security: Security groups, firewalls, and private networking to limit what can reach what.
Compliance basics: Awareness of the standards and controls that regulated workloads have to meet.
Most cloud security incidents trace back to misconfiguration, especially over-broad permissions and exposed storage. Least privilege is not a formality; it’s the single highest-value habit you can build.
IAMLeast privilegeEncryptionNetwork securityCompliance
06
Designing systems that stay up despite failures is core architecture work. The cloud gives you the tools; using them well is the skill.
High availability: Removing single points of failure by spreading a system across availability zones and regions.
Fault tolerance: Designing so that when a component fails, the system degrades gracefully rather than falling over.
Disaster recovery: Backups and recovery plans, and knowing your recovery time and recovery point objectives.
Statelessness: Keeping services stateless where possible, which makes scaling and recovery far simpler.
High availabilityFault toleranceMulti-AZDisaster recoveryBackups
07
A good architecture holds up as demand grows. Knowing how to scale, and when not to, is central to the role.
Scaling: Load balancing and autoscaling so capacity follows demand instead of being fixed and wasteful.
Caching & CDNs: Serving frequent and static content from cache and the edge to cut load and latency.
Decoupling: Using queues and events so parts of a system can scale and fail independently.
Performance: Finding bottlenecks and choosing the right service so a system stays fast under real load.
AutoscalingLoad balancingCachingCDNsMessage queues
08
Cloud makes it easy to spend a fortune by accident. Designing and running systems cost-effectively is a skill that architects are specifically valued for.
Understanding the bill: Knowing what actually drives cost, so you can design and decide with the price in mind.
Right-sizing: Matching resources to real need rather than over-provisioning out of caution.
Pricing models: Using reserved, spot, and savings options where they fit to cut cost substantially.
FinOps habits: Tagging, monitoring, and reviewing spend so cost stays visible and under control.
Cost driversRight-sizingReserved & spotFinOps
09
Modern cloud architectures lean on containers and serverless. Knowing what each is good for lets you design systems that are efficient and easy to run.
Containers: Packaging and running apps consistently, and using managed Kubernetes when orchestration is needed.
Serverless: Running code without managing servers, and where that model saves effort versus where it doesn’t fit.
Choosing the model: Matching the runtime to the workload, since neither containers nor serverless is right for everything.
ContainersManaged KubernetesServerlessChoosing the model
10
Architecture is the art of trade-offs. There is no perfect design, only the right one for a given set of requirements and constraints.
Well-architected frameworks: The pillars the major clouds define (reliability, security, performance, cost, operations) as a checklist for good design.
Balancing trade-offs: Weighing reliability, cost, speed, and simplicity against each other for the situation at hand.
Designing to requirements: Starting from what the business actually needs rather than reaching for the most impressive design.
Avoiding over-engineering: Choosing the simplest architecture that meets the requirements, because complexity has an ongoing cost.
The most common architecture mistake is building for a scale and complexity you don’t have yet. Good architects design for real requirements, not imagined ones.
Well-architectedTrade-offsRequirements-drivenSimplicity
11
Solutions architects work with people as much as systems. Translating business needs into architecture, and explaining it clearly, is what makes the design real.
Understanding requirements: Drawing out what stakeholders actually need before proposing how to build it.
Explaining architecture: Communicating a design clearly to both technical and non-technical audiences, often with diagrams.
Working with stakeholders: Aligning teams and decision-makers around an approach, and being honest about trade-offs.
Documentation: Recording decisions and designs so others can build, run, and evolve the system.
RequirementsDiagramsStakeholdersDocumentation
12
AI is now a major cloud workload and a useful tool for cloud work. Understanding both is increasingly part of the role.
Cloud AI services: The managed AI and ML services the major clouds offer, and where they fit into an architecture.
Infrastructure for AI: Designing for the compute, GPUs, and data pipelines that AI workloads need, a fast-growing demand.
AI-assisted work: Using AI to help write infrastructure code and review designs, with careful checking since it’s production.
AI raises demand for people who can architect the infrastructure behind it. The fundamentals in this roadmap are exactly what let you design cloud systems that AI workloads can actually run on.
Cloud AI servicesAI infrastructureGPUsAI-assisted design

Design and deploy a real architecture

Nothing proves cloud ability like an architecture you designed, deployed, and can defend. A project that ties the pieces together is the most convincing thing you can show, because you can explain every trade-off you made.

Deploy a small app on a cloud, provisioned entirely with infrastructure as code from your repo.
Make it reliable: spread it across availability zones and add a load balancer and autoscaling.
Lock down access with least-privilege IAM and private networking, and encrypt data at rest.
Draw the architecture diagram and write a short note on your reliability, security, and cost choices.

Keep an eye on the bill and tear it down when you’re done. Being able to explain your trade-offs, and why you didn’t over-build, is exactly what an architecture interview looks for.

Frequently asked questions

What’s the difference between a cloud engineer and a solutions architect?

They overlap. Cloud engineers lean toward building, automating, and operating cloud infrastructure hands-on. Solutions architects lean toward designing systems, weighing trade-offs, and working with stakeholders, often at a higher level and more customer-facing. Many people do both, and the titles vary by company, which is why this roadmap covers the shared foundation.

How is this different from DevOps or SRE?

There’s real overlap in cloud, automation, and infrastructure. DevOps and SRE emphasise the pipeline, automation, and keeping running systems reliable, while cloud engineering and architecture emphasise designing and building the cloud infrastructure itself. In smaller teams one person may do all of it; in larger ones the focus differs.

Which cloud should I learn first?

Any of the major ones. AWS has the largest market share, but Azure and Google Cloud are widely used and share the same concepts. Learn one deeply enough to understand core compute, storage, networking, and identity, and most of it transfers to the others.

Are cloud certifications worth it?

They can help, especially for getting past hiring filters and giving your study a structure, and cloud certifications are among the more respected in tech. That said, they’re no substitute for having actually built and run things. Treat a certification as a way to organise learning, not the finish line.

How long does it take to become a cloud engineer or architect?

It depends far more on hands-on practice than any fixed timeline. Many people move in from software, operations, or system administration by adding cloud, infrastructure as code, and architecture skills. Building and deploying real systems on a cloud you can practise on is what accelerates it.

Do I need to master every topic on this roadmap?

No. Networking, core services, infrastructure as code, security, and architecture fundamentals are the core. Deep cost optimization, specific services, and the architect communication skills you deepen as your role demands, and cloud engineering and architecture roles emphasise different parts.

Early access

Cloud Engineer support is coming to Interview Ready

Our personalized Interview Ready plans don’t cover Cloud Engineer or Solutions Architect just yet, so unlike our other roles, this page doesn’t hand you off to a plan we can’t build for you honestly. This roadmap is free to use in the meantime. Want to be first in line when we add it? Register your interest and we’ll let you know the moment it’s ready.

Request early access Browse supported roles

How to become a Cloud Engineer / Solutions Architect

Step 01Cloud & networking foundations

Step 02Core cloud services

Step 03Linux, scripting & the CLI

Step 04Infrastructure as code

Step 05Identity, security & compliance

Step 06Architecting for reliability

Step 07Architecting for scale & performance

Step 08Cost optimization

Step 09Containers & serverless

Step 10The well-architected mindset & trade-offs

Step 11Communication & the architect role

Step 12AI & the modern cloud

Design and deploy a real architecture

Frequently asked questions

Cloud Engineer support is coming to Interview Ready

Other roles