30-Day Cloud Learning Plan Cheatsheet: One Month to Build Real Skills

Thirty days will not make you a cloud engineer. But it will give you a real foundation and a project to show for it — and that is more than most people who claim to be “learning cloud” have after six months of passive watching.

The plan is structured so each week builds on the last. Week 1 is foundations. Week 2 is core cloud services. Week 3 is infrastructure as code and containers. Week 4 is CI/CD and portfolio. By Day 30 you will have a working end-to-end project on GitHub and a clear view of what to focus on next.

Before You Start#

Prerequisites:

Pick one cloud provider. Do not try to learn all three at once. The core concepts are transferable. The specifics are not identical. Switching between providers mid-plan will slow you down without making you better prepared.

Week 1: Foundations (Days 1–7)#

The goal of Week 1 is to understand what the cloud is and get comfortable operating in it.

Day 1 — Cloud fundamentals:

Do not just read. Open your cloud console and click around. Find where you would launch a VM, where the storage section is, where billing lives.

Days 2–3 — Linux basics:

Exercise: Create a virtual machine in your cloud console. SSH into it from your laptop. Run a few commands. This is fundamental — if you cannot SSH into a VM you cannot do most of the practical work ahead.

Days 4–5 — Networking basics:

Exercise: Create a VPC (or virtual network) in your cloud console. Launch a VM inside it. Verify the firewall rules allow SSH from your IP only.

Days 6–7 — Review and first build:

Consolidate what you have learned. Document your setup in a README file. This is not optional — getting used to documenting as you build is a habit that matters throughout your career.

Week 1 deliverable: A running cloud account, a VPC, a VM accessible via SSH, and a README that explains what you built and how to reproduce it.

Week 2: Core Cloud Services (Days 8–14)#

The goal of Week 2 is hands-on experience with the services that appear in almost every cloud role.

Days 8–9 — Object storage:

Days 10–11 — IAM (Identity and Access Management):

Days 12–13 — Compute deeper:

Day 14 — Review and diagram:

Draw a rough architecture diagram of what you have built so far: VPC, subnets, VM, storage bucket, IAM role. Use draw.io, Excalidraw, or even paper. Get used to visualising and communicating architecture.

Week 2 deliverable: Working VM, storage bucket with a lifecycle policy, IAM role with least-privilege permissions. All documented.

Week 3: Infrastructure as Code and Containers (Days 15–21)#

The goal of Week 3 is to stop clicking in consoles and start managing infrastructure as code.

Days 15–16 — Terraform fundamentals:

Days 17–18 — Docker fundamentals:

Days 19–20 — Containers in the cloud:

Deploy your Docker image to a managed container service:

Each of these lets you run a container without managing the underlying server. You provide the image; the platform handles scheduling, networking, and scaling.

Day 21 — Refactor with Terraform:

Rewrite your container deployment so it is managed by Terraform instead of configured by hand in the console. This is the key habit: every resource should be managed as code, not clicked into existence.

Week 3 deliverable: A Dockerised application deployed to your cloud provider via Terraform. The Terraform configuration is in a Git repository.

Week 4: CI/CD and Portfolio (Days 22–30)#

The goal of Week 4 is to automate your deployment pipeline and turn your work into a portfolio piece.

Days 22–23 — Basic CI/CD pipeline:

Set up a GitHub Actions (or GitLab CI) pipeline that triggers on every push to the main branch. At minimum it should:

  1. Check out the code
  2. Run a lint or test step (even a simple syntax check counts)
  3. Build the Docker image

This establishes the pattern. You will extend it next.

Days 24–25 — Deploy from the pipeline:

Extend your pipeline to:

  1. Push the built Docker image to your container registry
  2. Trigger a deployment (update the container service, or run terraform apply)

Now a push to GitHub results in an updated, running application in the cloud with no manual steps. This is the core DevOps loop.

Days 26–27 — Write up the project:

Write a README that includes:

A recruiter or engineer who looks at your GitHub should be able to understand the project in 2 minutes without asking you anything.

Days 28–29 — Polish your GitHub profile:

Day 30 — Reflection and planning:

Write down:

Week 4 deliverable: A complete end-to-end project on GitHub with a CI/CD pipeline, good documentation, and a readable profile.

What Comes After 30 Days#

Common Reasons People Fall Behind#

Learning multiple clouds at once. The concepts are similar. The APIs, CLIs, and specific services are different. Pick one and finish the plan with it.

Watching tutorials without building. A tutorial where you copy commands without understanding what they do gives you an illusion of progress. Break things. Fix them. Understand why the fix works.

Skipping the documentation step. Writing up what you built is not optional padding. It forces you to understand it well enough to explain it, and it produces the portfolio artifact you need when you start applying.

Related topics to read next

If this page helped, these guides are useful next steps.