Slow but Safe Cloud Path: Learning Cloud While Working Full Time

Who this path is actually for

This is for you if you have read the 6 month roadmap and thought “I genuinely cannot do 15 hours per week.” Not “I would prefer not to” — genuinely cannot, because of real, fixed constraints on your time. A demanding job that regularly runs past 6pm. A young child or elderly parent who depends on you. Chronic health issues that limit your energy. A financial situation where taking even partial leave is not an option.

The honest message of this page is simple: slow is fine. The cloud skills you are building are real and cumulative. Someone who studies for 20 months at 7 hours per week accumulates over 500 hours of learning and practice. That is substantial. It is enough to build three or four real portfolio projects, pass two or three certifications, and develop genuine fluency in Terraform, Docker, and Kubernetes. The timeline to the first job is longer, but the quality of the foundation is not compromised by studying slowly.

What is not fine is burning out. A sprint that collapses at month 3 produces nothing. An 18-month slow path that gets you to the finish line produces a cloud engineering career. The maths is not complicated. The hard part is accepting a slower timeline in a world full of “I got hired in 90 days” stories — which we will address directly.

About those “6 month success stories”

LinkedIn and Reddit are full of posts from people who say they got their first cloud job in three to six months of studying. Some of these are accurate. Many of these are incomplete. The person who “went from zero to cloud engineer in 4 months” typically had one or more of the following: a development or IT background that they did not mention, the ability to study full-time because they were between jobs, a partner or family member who covered their living costs during the transition, or a job description that stretched the meaning of “cloud engineer” significantly.

This is not to dismiss those stories — they are real and the people in them worked hard. But measuring your timeline against them when your circumstances are entirely different is a category error. It is like looking at a marathon time from someone who trained six days per week for a year and comparing it to your training plan of two evenings per week. You are both running the same race. Your finish time will be different. That does not mean you cannot finish.

The only timeline that matters is yours. Define it based on your hours, your background, and your constraints — not based on the best-case outcomes of people with different constraints.

What 7 hours of learning looks like in a real week

Seven hours per week does not sound like much. In a busy week, it requires deliberate scheduling. Here is what it can look like in practice for someone with a demanding full-time job:

Total: 7 hours. The key structural insight here is that the pattern has two short sessions and one longer session. The short sessions — 1.5 hours — are for consuming and processing new information. The longer session — 3 hours on Saturday morning — is for building. You cannot deploy infrastructure, hit an error, debug it, understand why it failed, and fix it in 90 minutes. You need the longer block for the hands-on work.

The Sunday optional session is for review and planning, not new material. Reviewing what you covered during the week is one of the highest-value uses of study time, and it is almost always the first thing cut when people feel busy. Do not cut it — it is what makes Monday’s new material stick.

The 18-month learning sequence

At 7 hours per week, 18 months gives you roughly 540 hours of study and practice. The sequence below distributes that time across the skills a junior cloud engineer needs.

Months 1–4: Linux, networking, and cloud fundamentals. Spend the first four months on foundations. Linux first — you need to be comfortable at the command line before the cloud console makes complete sense. Then networking: IP addresses, subnets, DNS, routing, and firewalls. These are not exciting topics, but they are the reason cloud networking concepts like VPCs and security groups exist. Once you have these, move into cloud platform fundamentals: the main service categories, the shared responsibility model, IAM, billing and cost management. Set up your free tier account early and explore the console without deploying anything expensive. By month 4, sit and pass your first foundational certification — AWS Cloud Practitioner or GCP Cloud Digital Leader.

Months 5–8: Core cloud services and your first project. Study compute, storage, networking, and database services in depth on your chosen platform. Go beyond the overview — understand what EC2 instance types exist and when to use each, how S3 storage classes work, what a VPC actually is and how subnets, route tables, and internet gateways connect. Deploy your first project manually: a web application on a cloud instance with a proper network configuration. Write it up on GitHub. Start studying Terraform in the second half of this block — the HashiCorp tutorials are free and well structured.

Months 9–12: Terraform, Docker, and a rebuilt project. Rebuild your month 5-8 project entirely in Terraform — delete the manual infrastructure and recreate it from code. This is one of the best learning exercises in cloud: you understand your infrastructure much better the second time when you have to express every component as a resource block. Then introduce Docker: write a Dockerfile, build an image, containerise a simple application, and deploy it using a managed container service. By month 12, you should have two solid GitHub repositories and be preparing for your associate-level certification.

Months 13–16: Associate certification and Kubernetes basics. This is the most technically demanding phase. An associate-level certification — AWS Solutions Architect Associate or GCP Associate Cloud Engineer — requires understanding how cloud services compose into architectures, not just what each service does. Dedicate the majority of your study hours to exam preparation: structured course, official documentation, and a large volume of practice questions. Sit the exam by month 15. In parallel, learn Kubernetes basics: pods, deployments, services, and kubectl. Deploy your containerised application to a managed Kubernetes cluster and document the process.

Months 17–18: CI/CD, portfolio polish, and early applications. Build a GitHub Actions pipeline that automates your deployment. Review all your GitHub repositories with fresh eyes — improve any thin READMEs, add architecture diagrams, ensure all projects actually run. Update your CV and LinkedIn. Start sending applications. At this stage, your profile — two certifications, three portfolio projects, and 17 months of consistent effort — is a strong candidate profile for cloud support engineer and junior cloud engineer roles.

How to pick up where you left off after a break

Over 18 to 24 months, you will have at least one break. A period of work pressure that takes over your evenings. An illness. A family situation that demands all your attention for two or three weeks. This is not a failure of discipline — it is the reality of studying alongside a full life. The question is not how to prevent breaks, but how to restart effectively after one.

The biggest risk after a break is not that you have forgotten everything — most of it will come back quickly. The biggest risk is the activation energy required to start again. Coming back after three weeks away and trying to resume exactly where you left off often feels overwhelming. A better approach:

Plan a review session before resuming forward progress. When you come back after a break, spend your first session reviewing your notes and the last thing you deployed, rather than trying to learn something new. This re-establishes your mental model of where you are without the pressure of new material. One review session is usually enough to feel ready to move forward.

Lower the re-entry bar deliberately. After a break, set your goal for the first week back to 50% of your normal hours. Two sessions instead of three. An hour instead of ninety minutes. The goal is to rebuild the habit, not to make up for lost time. Trying to make up lost time by doubling your hours in the first week back is a reliable way to feel overwhelmed and take another break.

Write a short note to your future self at the end of each session. Three sentences: what you covered, what you were going to do next, and one thing that confused you. When you come back after two weeks away and open your notes, that note is worth far more than re-reading everything you wrote. It puts you back in the context immediately.

Why slow learners often start their first job better prepared

There is a genuine advantage to the slow path that is rarely discussed, because most content about cloud careers is implicitly optimising for speed. But slow learners, when they arrive at their first cloud role, are often better prepared than fast-track peers — and here is why.

Over 18 months of consistent study, you have revisited the same concepts many times from different angles. You have built something, come back to it three months later with new knowledge, and understood it differently. You have had the experience of a Terraform concept from month 9 clicking into place when you used it again in a real project in month 14. That kind of multi-pass learning produces durable knowledge — not just exam-passing knowledge.

You have also had more time to develop the troubleshooting mindset that is central to cloud engineering. When something broke in your Saturday morning session, you had time to actually debug it rather than looking up the answer immediately. When a Terraform plan produced an unexpected result, you had the patience to read the error message carefully and understand what it was telling you. This patience and systematic debugging approach is something that experienced engineers look for in junior hires — and it is built over time, not crammed.

Fast-track learners often arrive at their first role with surface-level knowledge across many tools and genuine depth in very few. Slow-track learners who followed a disciplined sequence often have solid depth across their core stack. The first 90 days on the job tend to feel very different for each type. See the self-taught cloud engineer guide for more on how self-directed learners can position their background effectively when applying.

Managing the frustration of a long timeline

Eighteen months is a long time to stay motivated toward a single goal. Some things that genuinely help:

Track your hours, not just your milestones. Milestones like certifications and completed projects are months apart. Hours accumulate every week. Keeping a simple log of your study hours — a spreadsheet with a weekly total is enough — gives you a visible record of progress that you can look at when you feel like nothing is moving. Seeing 400 hours logged is motivating in a concrete way that “I’m on module 7 of a course” is not.

Build visible things. The slow path can sometimes feel abstract — you are accumulating knowledge, but it is not always clear where it is going. Counter this by building something real every month, even if it is small. A new Terraform module, a containerised version of a previous project, a monitoring configuration for your existing infrastructure. Commit it to GitHub. Having a public record of monthly progress is more motivating than private notes.

Connect your current situation to the skills you are building. If you work in IT support, start noticing when cloud concepts appear in your work — when a colleague asks about AWS, when a ticket involves a cloud service, when the company uses a service you studied last week. The connection between what you are learning and where you are going becomes more tangible when you can see it in your current environment.

For a broader view of what the full journey looks like, including the application phase that comes after the study phase, see the realistic cloud career timeline.