How to Build a Cloud Portfolio Fast: A 30-Day Action Plan

Who benefits from a speed approach

Moving fast makes sense when:

• You have an interview coming up and nothing to show yet
• You have been studying for months and have no practical evidence of your skills
• You have certification(s) but no projects — recruiters want to see both
• You are applying for jobs now and keep getting asked for a GitHub link you do not have

Speed does not mean low quality. It means focus. The biggest time trap is building more projects than you need, or spending weeks perfecting one project when “good enough to interview with” would have got you to an interview two weeks earlier.

What “fast” does not mean

These are the wrong ways to build a portfolio quickly:

• Cloning tutorial projects without modification. A portfolio of tutorial clones with generic READMEs is not a portfolio — it is evidence that you followed instructions, nothing more. Hiring managers recognise tutorial projects instantly.
• Deploying things without documenting decisions. A project is not done when it deploys. It is done when the README explains why it was built the way it was. The README is not optional — it is the point.
• Building five shallow projects. Two well-documented, thoughtful projects outperform five projects with no README and console-deployed infrastructure.

Week 1: Foundation and first project

Day 1–2: Set up your environment

• Create a cloud provider account (AWS, GCP, or Azure) with billing alerts configured before you touch anything else
• Install the CLI tools you will need: AWS CLI or gcloud, Terraform, Docker, kubectl
• Create a GitHub account if you do not have one and set up your profile README — a three-sentence bio explaining what you are building
• Create a repository for your first project with a placeholder README

Day 3–7: Build your first project

Start with a serverless API or a static website with CDN — something achievable in a weekend. The point of the first project is not to be impressive. It is to prove to yourself that you can complete and document a cloud build.

By the end of week 1 you should have:

• One project deployed and working
• Infrastructure provisioned with Terraform or SAM — not through the console
• A README that explains what the project is and what decisions were made
• The repository pinned on your GitHub profile

Week 2: CI/CD pipeline

The CI/CD pipeline project is the single most expected portfolio piece for junior cloud and DevOps roles. Build it second because it can wrap around your first project — your pipeline deploys the serverless API or static site you built in week 1.

Day 8–10: Design and write the pipeline

• Create a GitHub Actions workflow that triggers on pull requests
• Add lint and test stages (even basic ones — a project with no tests is better than a project with no pipeline)
• Build and push a Docker image to a container registry on merge to main
• Use OIDC for cloud provider authentication instead of stored credentials

Day 11–14: Extend and document

• Add a staging deployment step
• Write the README section explaining how the pipeline works and why you used OIDC
• Make a test fail to prove the pipeline actually blocks bad code
• Screenshot the failing pipeline for your README

Week 3: Networking or Kubernetes project

Choose based on your target role:

• Cloud engineer or SRE: Build the VPC networking project — two-tier network with public and private subnets, provisioned with Terraform
• DevOps engineer: Build the Kubernetes project — multi-service deployment with resource limits, probes, and a Helm chart

Week 3 is when fatigue sets in. The remedy is keeping scope tight. You do not need to build the advanced version of this project — you need to build a clean, well-documented version.

By day 21 you should have three projects:

• A serverless API or static website
• A CI/CD pipeline (ideally deploying project 1)
• A networking or Kubernetes project

Three well-documented projects is enough to interview with at junior and many mid-level roles. If you have an interview lined up, stop building and start preparing your talking points for each project.

Week 4: Polish and prepare to apply

Day 22–25: Portfolio polish

• Review all three READMEs — can someone unfamiliar with your work understand each project from the README alone?
• Check for any credentials in the repositories (use git log --all --grep="key\|secret\|password" as a quick check)
• Pin all three repositories on your GitHub profile
• Update your profile README to reflect the projects you now have

Day 26–28: Prepare your interview talking points

For each project, prepare answers to:

• What does this project do and why did you build it?
• What was the most difficult decision you made while building it?
• What would you change if you were deploying this to production?
• What did you learn from building it?

Day 29–30: Update your CV and start applying

Add the three projects to your CV’s projects section with links to the repositories. Start applying. The portfolio is done enough.

For guidance on presenting your projects on your CV, see how to write the projects section on your cloud CV.

The biggest time traps to avoid

• Restarting instead of finishing. If a project is 80% done and you are bored, finish it and document it. Starting a new project feels more exciting but leaves you with multiple half-finished builds.
• Waiting until the project is “perfect.” A working project with good documentation is ready to share. A perfect project that does not exist is not.
• Adding features instead of documenting. Every hour spent adding a feature to a project should be weighed against an hour spent writing the README or preparing your interview talking points.
• Choosing the wrong project first. Starting with the most complex project you can think of and spending three weeks on it is a common mistake. Start small and complete something.