3 Month Cloud Roadmap: Intensive Fast-Track Plan

Who this plan is actually for

Before diving into the month-by-month breakdown, you need to be honest with yourself about whether this plan applies to you. The 3-month cloud roadmap is intensive. It assumes roughly 35 to 45 hours of study per week — similar to a full-time job.

This plan suits people who are between jobs and have savings to cover 90 days without income, on a student or study visa with structured free time, on parental leave or a career break, or working very reduced hours while transitioning careers. It also suits people who have relevant adjacent experience — a developer who wants to move into cloud, or a sysadmin who already knows Linux and networking.

This plan does not suit people who are studying 1 to 2 hours per evening after work. If that is your situation, the 6 month cloud roadmap is a more honest fit. Trying to compress a 6-month plan into 3 months at half the hours simply produces a half-finished 6-month plan.

One more important point: if you have no prior tech background at all — no programming, no IT work, no networking knowledge — 3 months will not get you to your first cloud job. It can get you to a foundational certification and a basic portfolio, which is a strong start. But the job itself will likely require another 3 to 6 months of continued learning. Be honest about where you are starting from.

What 3 months can realistically produce

Here is what a disciplined 3-month fast track can achieve for someone with some prior tech exposure:

• One foundational cloud certification — AWS Cloud Practitioner or GCP Cloud Digital Leader
• Comfortable working at the Linux command line for everyday tasks
• One deployed portfolio project visible on GitHub
• Basic fluency with Terraform and Docker
• A working understanding of core cloud services: compute, storage, networking, and IAM
• An updated CV and LinkedIn profile that reflects your new skills

Here is what 3 months usually does not produce: a job offer. Most people will not receive their first cloud job offer within 90 days of starting from scratch, regardless of how hard they study. The application and interview process alone takes time. Hiring managers typically look for a combination of certification, hands-on evidence, and some comfort talking through cloud concepts under pressure — and that conversational fluency comes from repetition over time, not just cramming.

If you have prior relevant experience — development, Linux sysadmin work, or IT support — 3 months can realistically get you to your first interview and potentially an offer. Without that background, set your expectation at “strong foundation” rather than “hired.”

Month 1: Foundations and your first certification

Target hours: 35–40 hours per week. Goal: Pass AWS Cloud Practitioner or GCP Cloud Digital Leader, get comfortable at the Linux command line, and deploy a first application manually.

Week 1 — Linux fundamentals: Start with Linux before you touch cloud. Cloud engineers spend a significant portion of their day in terminals. Learn file system navigation, file permissions, user management, basic shell scripting, and package management. Use a free Linux VM — either locally via VirtualBox or on a free-tier cloud instance. Spend around 3 hours per day on this. The Ubuntu command line basics and the Linux Foundation’s free introductory content are both solid starting points.

Week 2 — Networking fundamentals: Cloud networking is impossible to understand without knowing what IP addresses, subnets, DNS, HTTP, and TCP/IP actually are. You do not need to become a network engineer. You need to understand what a VPC is and why it exists, what a subnet does, how DNS resolution works at a basic level, and why ports matter. Spend 3 to 4 hours on this. The rest of the week should move into cloud fundamentals: what regions and availability zones are, how the shared responsibility model works, and the core service categories.

Weeks 3 and 4 — Certification preparation: Pick one platform — AWS or GCP — and stick with it. AWS Cloud Practitioner and GCP Cloud Digital Leader are both foundational certs aimed at non-technical roles, but they are a genuine indicator that you understand the basic shape of the platform. Use official exam guides, practice tests, and one structured course. Aim to sit the exam by the end of week 4. Simultaneously, set up your free tier account, configure a billing alert so you do not accidentally spend money, and manually deploy a simple static web application — an HTML page served from S3 or Cloud Storage is enough at this stage.

By the end of Month 1 you should hold your first certification and have deployed something, however simple, to the cloud.

Month 2: Infrastructure as code, containers, and a real project

Target hours: 35–40 hours per week. Goal: Learn Terraform and Docker well enough to use them in a portfolio project. Rebuild your month 1 web app using Terraform. Containerise an application.

Weeks 5 and 6 — Terraform: Terraform is the most commonly used infrastructure-as-code tool in cloud roles, and it appears in a significant majority of cloud engineer job descriptions. Start with the official HashiCorp tutorials — they are free and well-structured. Focus on: writing a basic .tf file, understanding state, creating real resources (an EC2 instance, a VPC, an S3 bucket), and using variables and outputs. Your practical exercise for this fortnight: delete your manually-deployed web app and rebuild the entire infrastructure using Terraform. Commit all of it to a public GitHub repository with a clear README.

Weeks 7 and 8 — Docker and basic networking depth: Docker is not optional for modern cloud roles. Learn how to write a Dockerfile, build and run a container locally, push to Docker Hub or a cloud container registry, and understand port mapping. Alongside Docker, deepen your networking knowledge: subnets, route tables, security groups versus network ACLs, and what a load balancer actually does. Your practical exercise: containerise a simple web application (even a basic Python Flask or Node.js app) and deploy it to your cloud platform using a container service like AWS ECS or Google Cloud Run.

By the end of Month 2, your GitHub profile should have at least two repositories: one showing Terraform, one showing a containerised application. This is what interviewers actually look at.

Month 3: Kubernetes, CI/CD, and starting applications

Target hours: 30–35 hours per week. Goal: Understand Kubernetes well enough to deploy to a managed cluster, build a basic CI/CD pipeline, polish your portfolio, and start applying to junior roles.

Weeks 9 and 10 — Kubernetes basics: You do not need to be a Kubernetes expert at the junior level. You do need to understand what a pod is, what a deployment does, what a service exposes, and how to interact with a cluster using kubectl. Use a managed Kubernetes service — Amazon EKS, Google Kubernetes Engine, or Azure AKS — and deploy your containerised application from Month 2 to it. Document the process in your GitHub repository. Understanding Kubernetes at this level is enough to discuss it confidently in an interview.

Week 11 — CI/CD pipeline: A CI/CD pipeline is a standard expectation in cloud roles. Build a basic pipeline using GitHub Actions that does the following: runs on a push to main, builds your Docker image, pushes it to a container registry, and optionally deploys it. This does not need to be complex. A working pipeline that does three things is more impressive than a complicated pipeline that half-works. Add it to your portfolio and write a brief explanation of each step in the README.

Week 12 — Portfolio polish and applications: Spend this week reviewing your GitHub repositories. Every project needs a README that explains what it does, why it exists, what technologies it uses, and how to run it. Update your CV to reflect your certification, your projects, and the tools you now know. Update LinkedIn similarly. Write a short, direct cover letter template that you can personalise quickly. Start applying to cloud support engineer and junior cloud engineer roles. At month 3, you are unlikely to land a role immediately, but starting the process early means you understand what the market is asking for and can adjust your learning accordingly.

What comes after the 3 months

At the end of 90 intensive days, most people will be at a stage where they have the right building blocks but need continued application experience and interview repetition before landing a role. That is completely normal. Keep studying at a reduced pace — 10 to 15 hours per week — while applying. Use the how long to become a cloud engineer guide to calibrate your expectations for the full journey.

If you have prior development or IT experience and you have completed the above, you should be in a strong position to interview for entry-level cloud support and junior cloud infrastructure roles. Review the entry-level cloud jobs guide to understand what each role actually involves day to day, so you can target applications accurately.

For your next certification, look at AWS Solutions Architect Associate or the equivalent GCP Professional Cloud Architect. These are the certs that open doors to cloud engineer roles with more responsibility and better pay. They are not required to apply for junior roles, but having them booked and in progress demonstrates continued commitment.

Finally, avoid the temptation to add more tools before deepening your knowledge of what you already have. Three months in, it is easy to feel like you should learn Ansible, Helm, ArgoCD, and Prometheus because you saw them in a job description. Depth beats breadth at the junior level. Get really good at Terraform and Docker before layering anything else on top.

Common mistakes on the fast-track path

Skipping Linux to get to cloud faster. This always catches people out in interviews and on the job. Spend the time in week 1 on the command line. It pays dividends across everything else.

Studying without building. Watching tutorials and taking notes feels productive but does not produce portfolio evidence. Every week should include something deployed or committed to GitHub. If you finish a week with no new commit, you have not done enough practical work.

Collecting certifications instead of building things. One cert and two portfolio projects is significantly more compelling than three certs and no projects. Recruiters look at GitHub. Interviewers ask you to walk through what you built. Have something to show.

Burning out at week 6. Studying at 35 hours per week is unsustainable for many people. Build in at least one full rest day per week. If you hit a wall, take two days off completely — it is far better than grinding through at poor quality and quitting. See the common beginner mistakes guide for a fuller list of traps to avoid.