My long-term goal is clear: start as a Cloud Engineer and, over the years, grow into a Cloud Architect role. A goal like that stays vague until it becomes a calendar.
So I wrote a detailed 12-week plan, at about 10 hours a week, for roughly 120 hours in total. It starts from basic computer skills and ends with a first cloud deployment and a project I can show.
One project: CloudOps Lab
The most important rule in the plan is also the simplest: build one project. Instead of opening ten repositories and abandoning them halfway, every week I’ll improve the same one.
The project is called CloudOps Lab: a small Python API built with FastAPI that reports the status of a service. Week by week it will gain a database, automated tests, a Docker container, a cloud deployment, a CI/CD pipeline, logs and health checks. At the end I’ll document the architecture, the choices, the problems I ran into and the potential costs.
It isn’t meant to be a commercial product and it won’t handle real data: it’s a lab, and I’ll present it as one.
The 12 weeks
The order isn’t random. Each topic builds on the previous one, and the cloud only comes after I understand how an application works locally.
| Week | Topic | What I want to achieve |
|---|---|---|
| 1 | Linux and the terminal | Files, permissions, processes and environment variables |
| 2 | Networking and Git | IP, DNS, ports, HTTP and the first repository |
| 3 | Docker and Compose | Images, containers, ports and volumes |
| 4 | FastAPI and databases | An API with validation, SQLite and tests |
| 5 | AWS fundamentals | IAM, EC2, S3, VPC, regions and costs |
| 6 | First AWS deployment | A minimal version reachable from outside |
| 7 | CI/CD | Automated tests on every push with GitHub Actions |
| 8 | Logging, monitoring and security | Health checks, logs and secrets management |
| 9 | Terraform | Infrastructure described in versioned files |
| 10 | Reliability and costs | Backups, failures, scaling and budgets |
| 11 | AWS Cloud Practitioner | Structured review and practice exams |
| 12 | Portfolio | README, diagram, demo, article and CV |
All the resources I’ll use, week by week, are collected on the Resources page.
What a week looks like
Every week has the same structure: a goal, what to study, a hands-on lab, a concrete deliverable and an end-of-week checklist.
The checklist is my favourite part, because it forces me to be honest. It doesn’t ask “did you read the chapter?” but things like:
- can I tell a permissions error from a missing file?
- can I explain the difference between
git addandgit commit? - do I know why you review the
planbefore runningapply?
The 10 hours are split roughly like this:
- 2–3 hours of study and documentation, with short notes;
- 5–6 hours of lab work: I follow a tutorial once, then redo it without copying step by step;
- 1 hour of debugging and testing, noting what broke and how I fixed it;
- 1 hour of review, updating the README, the checklist and the project log.
The rules I set myself
Don’t rush. The 12 weeks are a guide, not a hard deadline. If I can’t explain a topic in my own words, I stay on it until I can.
Watch the costs. The Free Tier doesn’t mean everything is free. Before creating any AWS resource I write down what I’ll create, what it might cost and how to delete it. Much of the work, from Linux to Docker to testing, can be done locally: I’ll move to AWS once I know what I want to deploy and how to shut it down.
No secrets in the repository. Passwords, tokens, keys and .env files stay out of Git, out of the logs and out of Docker images.
Certification is an option, not an obligation. Week 11 is about finding out whether I’m ready for AWS Cloud Practitioner. If I’m not, I won’t book the exam just because the calendar says “week 11”.
Claude as a copilot, not the pilot
Along the way I’ll use Claude to clarify errors, review code and suggest tests. The risk is getting code that works without understanding why.
To avoid that I set a few rules:
- before asking for code, I write the requirement myself in a few lines, along with what I expect to happen;
- I ask for the reasoning and which files will change, not just the solution;
- I make one change at a time, then run the tests and read the diff;
- if I can’t explain a function, I ask for a line-by-line explanation and try rewriting it myself;
- I never paste API keys, passwords or sensitive data.
What this plan is not
This plan won’t make me a Cloud Engineer in 12 weeks, and it doesn’t replace a certification or work experience. It’s meant to build verifiable foundations and a project I can demonstrate and explain.
At the end I’ll choose the next step based on what I can actually do: go deeper into AWS, consolidate Docker, Linux and networking, or extend CloudOps Lab with a managed database, more serious monitoring and more Terraform.
Next steps
It starts with week 1: the terminal, files and permissions. I’ll document my progress here on mycloudrise.com, including the mistakes and the things that break, because those are often what you learn the most from.