6 Month Cloud Roadmap: The Part-Time Beginner Plan

Why 6 months is the sweet spot for most beginners

Six months is long enough to build genuine depth and short enough that most people can maintain motivation to the finish line. Compare this to the 3 month cloud roadmap, which requires full-time study and suits a narrower audience, or the 12 month cloud roadmap, which is better suited to people with very limited weekly hours or significant other commitments.

At 15 to 20 hours per week over 6 months, you accumulate 360 to 480 hours of study and practice. That is enough to develop real skills — not just certification knowledge, but the ability to actually build and troubleshoot infrastructure. Employers can tell the difference between someone who crammed for a cert and someone who has spent months working in a cloud environment.

The realistic outcome at month 6: one foundational certification, one associate-level certification, two to three portfolio projects in GitHub, a working understanding of Terraform, Docker, Kubernetes, and CI/CD, and a CV that reflects all of this. Most people at this stage are ready to apply for junior cloud engineer or cloud support engineer roles. Whether they get hired in month 6 or month 8 depends on factors like location, market, and the interview process — but the skills will be there.

Setting up a realistic study schedule

Fifteen to twenty hours per week sounds manageable in theory but requires active scheduling to actually happen. The most common failure mode is leaving study time unscheduled and trying to fit it around whatever gaps appear in the day — which means it consistently gets squeezed out by real life.

A workable structure for most people looks like this: two hours on weekday evenings (Monday, Tuesday, Wednesday, Thursday), and four to five hours on one weekend day. That gives you thirteen to fourteen hours without touching both weekend days. Pick up another session on a second weekend day or a weekday morning to reach fifteen to twenty hours.

Protect these sessions the same way you would protect a meeting or a work commitment. Put them in your calendar. Tell the people you live with what you are doing. Studying cloud infrastructure in thirty-minute fragments is significantly less effective than two uninterrupted hours. You need long enough sessions to deploy something and see it work — or fail and troubleshoot it.

Months 1–2: Foundations and your first certification

Weekly hours: 15–20. Goal: Build Linux and networking fundamentals, understand the core shape of your chosen cloud platform, and pass a foundational certification.

Linux first, cloud second. Spend the first two to three weeks on Linux before you open a cloud console. You need to be comfortable navigating the file system, managing file permissions, using ssh, reading logs, and writing basic shell scripts. This is not optional — nearly every cloud task involves a terminal, and fumbling at the command line in an interview or on the job will hold you back. Use a free Ubuntu VM locally via VirtualBox, or spin up a free-tier Linux instance on your chosen cloud provider.

Networking fundamentals. Spend a week on the networking concepts that cloud infrastructure is built on: IP addresses, subnets and CIDR notation, DNS, routing, HTTP versus HTTPS, and what happens when you type a URL into a browser. You do not need to be a network engineer. You need to understand what a VPC is trying to do and why security groups exist. This knowledge makes everything else in cloud click into place faster.

Cloud platform fundamentals. Pick one provider — AWS or GCP are the strongest choices for early career — and study its core services: compute (EC2 or Compute Engine), storage (S3 or Cloud Storage), networking (VPC, subnets, security groups), and identity management (IAM). Set up a free tier account, configure a billing alert immediately, and start deploying things manually. A static website hosted on S3 with a custom domain configured through Route 53 is a classic first project — simple, but it touches enough services to be instructive.

Foundational certification. AWS Cloud Practitioner or GCP Cloud Digital Leader are appropriate first certifications. Neither is a deep technical exam — they test your understanding of the platform’s services, pricing model, and shared responsibility framework. Prepare with the official exam guide, one structured course, and multiple practice exams. Aim to sit it by the end of month 2.

Months 3–4: Terraform, Docker, and your first real project

Weekly hours: 15–20. Goal: Learn infrastructure as code with Terraform, containerise an application with Docker, and produce your first portfolio project committed to GitHub.

Terraform. Infrastructure as code is a core expectation in cloud roles, and Terraform is the most widely used tool for it. Work through the HashiCorp tutorials, which are free and well structured. The key concepts to master: writing resource definitions, understanding state, using variables and outputs, and creating real cloud infrastructure — not just reading about it. Your goal by week 10 is to be able to delete everything you created manually in months 1 and 2 and rebuild it entirely from a .tf file. Commit all of this to a public GitHub repository with a README that explains what it does.

Docker. Containerisation is now a baseline skill in most cloud engineer roles. Learn to write a Dockerfile, build an image, run it locally, and push it to a container registry. Understand the difference between an image and a container. Build a simple web application — a basic Python Flask or Node.js app — containerise it, and deploy it to a managed container service on your cloud platform. AWS ECS Fargate or Google Cloud Run are both reasonable choices and have free tier options.

Version control habits. By the end of month 4, you should have the habit of committing everything to Git. Your GitHub profile should show at least two repositories with meaningful README files — one demonstrating Terraform, one demonstrating a containerised app. This is what hiring managers and technical reviewers look at. The quality of your READMEs matters almost as much as the code itself — write them as if explaining your project to someone who has never seen it.

The plateau problem: why month 3–4 is where most people quit

Almost everyone who follows a 6-month learning plan hits a motivation wall around months 3 to 4. The initial excitement of starting something new has worn off. You are past the beginner material but not yet at a point where things feel fluent. You are spending your evenings wrestling with Terraform state errors and Docker networking issues instead of making satisfying progress. Job offers feel far away. This is the plateau, and it is completely normal.

The people who get cloud jobs are mostly the people who got through this phase without quitting — not necessarily the most talented or fastest learners, but the most consistent ones. A few things that help:

Shrink your goals. When motivation drops, the answer is not to push harder. It is to make the daily target smaller. Instead of “work on Terraform for 2 hours,” make it “open the Terraform project and write one new resource block.” Starting is the hard part. Most of the time, starting leads to continuing.

Change the format. If you have been watching tutorial videos, switch to reading documentation for a week. If you have been reading, switch to building something without guidance. Doing something different restores the sense of progress even when you are covering similar material.

Find one other person doing the same thing. A study partner, an online community, or even just posting your progress publicly on LinkedIn creates external accountability that internal motivation cannot always provide. The cloud community on Reddit and Discord is large and generally helpful.

Look back, not just forward. At the end of month 3, review what you knew at the start of month 1. The contrast is almost always striking. You have learned a significant amount — you are just too close to it to see it clearly.

Months 5–6: Associate cert, Kubernetes, CI/CD, and applications

Weekly hours: 15–20. Goal: Pass an associate-level certification, add Kubernetes and CI/CD to your portfolio, polish everything, and start applying.

Associate certification. AWS Solutions Architect Associate or GCP Associate Cloud Engineer are both solid choices and widely recognised. These are significantly harder than the foundational certs — they require real understanding of how cloud services work together, not just what they are. Dedicate three to four weeks of concentrated study. Use a structured course combined with practice exams. Practice exams are especially important for associate-level certs because the questions require you to reason through trade-offs, not just recall facts.

Kubernetes basics. You do not need to be a Kubernetes expert. You need to understand pods, deployments, services, and namespaces, and be able to use kubectl to interact with a cluster. Deploy your containerised application from months 3 and 4 to a managed Kubernetes cluster — Amazon EKS, Google Kubernetes Engine, or Azure AKS. Document what you did and add it to GitHub. This is a meaningful addition to your portfolio because Kubernetes appears in a large proportion of cloud engineer job descriptions.

CI/CD pipeline. Build a GitHub Actions pipeline that automatically builds your Docker image and deploys it when you push to the main branch. It does not need to be sophisticated. A pipeline that reliably does three things — test, build, deploy — is more valuable to show than a complicated one that is difficult to explain. Write a clear README section explaining what each step does and why.

Portfolio review. Before you start applying seriously, spend a few sessions reviewing your GitHub repositories with fresh eyes. Ask yourself: if I were a hiring manager who had five minutes to look at this, would I understand what the candidate built and why? Improve any READMEs that are thin. Make sure all projects actually run as described.

Applications. Start applying from month 5 if you have your foundational cert and at least two GitHub projects. Do not wait until you feel “ready” — that feeling often does not arrive on a schedule. Review the entry-level cloud jobs guide to understand which roles fit your current skills and which roles to target as a next step.

What to expect from the job search

Getting your first cloud role typically takes longer than people expect, and the gap between “ready to apply” and “received an offer” often stretches to two to four months of active applications. This is normal. Read the realistic cloud career timeline for a fuller picture of what the search process looks like and what influences how long it takes.

Most people send between 20 and 50 applications before receiving their first offer. The number varies widely based on location, the specific roles targeted, how well your CV is written, and timing. Applying to roles slightly below your skills is not a mistake — cloud support engineer and IT infrastructure roles that involve cloud exposure are valid starting points. See the how to become a cloud engineer guide for a broader picture of the career path beyond the first role.