Which Cloud Projects to Show on Your GitHub and CV

The selection problem

Many people who have been learning cloud for six months to a year have completed a lot of exercises, labs, and tutorial projects. The question is not whether you have built things — the question is whether what you have built is worth showing.

The distinction matters because hiring managers who look at your GitHub or CV projects section are making a judgment call in a short amount of time. Too many thin projects reads as quantity over depth. Too few projects reads as insufficient evidence. One or two exceptional projects reads as someone who builds with intention.

Most people learning cloud end up with too many tutorial completions and not enough independently built projects. This page helps you identify which of what you have is worth showing, and what to build next if the answer is “not much.”

The selection criteria framework

Before deciding whether a project belongs on your CV or pinned GitHub repos, run it through these questions:

1. Did you make the architecture decisions yourself?

A project where you followed someone else’s step-by-step instructions and reproduced their decisions is a tutorial completion, not a portfolio project. A project where you looked at a goal — “deploy a web application to AWS with a proper network design” — and made the decisions about subnets, IAM roles, instance types, and load balancing is a portfolio project.

The line is not always clean. Some tutorials teach well enough that you genuinely internalised the decisions and could modify them. But if you cannot explain why the project is built the way it is — why a specific VPC CIDR was chosen, why the database is in a private subnet, why you used an ALB versus an NLB — it’s not ready to show.

2. Can you explain it in an interview?

Every project you list will be asked about. An interviewer will typically ask: “Tell me about this project.” They may then follow up with: “Why did you choose X?” or “What would you do differently now?”

If you can answer those questions in depth, it belongs on your CV. If you would struggle beyond a surface description, work on it more before listing it.

3. Does it demonstrate a real engineering concern?

A project that deploys an EC2 instance and creates an S3 bucket demonstrates almost nothing. A project that deploys a complete application environment with security controls, a functioning CI/CD pipeline, and documented operational runbook demonstrates a lot.

Engineering concerns that make projects worth showing:

• Security: IAM least-privilege, network segmentation, secrets management, encryption at rest and in transit
• Reliability: health checks, auto-scaling, failover, error handling
• Automation: CI/CD pipelines, infrastructure as code rather than console clicks
• Observability: metrics, logging, alerting
• Cost awareness: resource sizing, cleanup procedures, tagged resources for cost allocation

A project that covers even two or three of these concerns is significantly more impressive than one that covers none.

4. Would you be comfortable if a senior engineer read the code?

This is the hardest filter. Not because the code needs to be perfect — it doesn’t — but because there are certain things that would actively embarrass you: hardcoded credentials, *:* IAM permissions, no .gitignore, a README that says “TODO”, a single commit called “initial”.

If you would be uncomfortable explaining specific choices to a senior engineer, clean those choices up before sharing the repository.

What to build if your current projects don’t qualify

If you run your existing projects through the criteria above and find most of them are tutorials or shallow exercises, here are the projects that provide the best return on effort for a cloud engineering portfolio.

Project 1: A real application infrastructure deployment

Pick a simple web application (it doesn’t need to be your own code — a public open-source app is fine) and deploy it properly to AWS or GCP using Terraform. Proper means:

• VPC with public and private subnets
• Load balancer in public subnets
• Application servers in private subnets
• Database in a separate private subnet with no public access
• IAM roles with specific permissions, not broad admin access
• S3 bucket for static assets or logs, with appropriate permissions
• README explaining the architecture with a diagram

This project demonstrates networking, IAM, infrastructure as code, and basic security thinking. It is the single most useful project for a junior cloud engineer’s portfolio.

Project 2: A CI/CD pipeline

Build a GitHub Actions pipeline that automatically tests, builds, and deploys a containerised application when you push to main. The application can be simple — even a basic “hello world” API — but the pipeline should:

• Run automated tests
• Build and push a Docker image to a registry (ECR, Docker Hub, or similar)
• Deploy to a cloud environment (could be the environment from Project 1)
• Use secrets management properly — no credentials hardcoded in the pipeline

Project 3: A Kubernetes deployment

Write Kubernetes manifests (not just follow a tutorial) for a multi-container application. Include Deployments, Services, ConfigMaps, Secrets, liveness and readiness probes, resource limits, and a Horizontal Pod Autoscaler. Document why you chose specific configuration values.

Running on a local cluster (kind, minikube) is fine for this project. The value is in the manifest quality and documentation, not in having a cloud-hosted Kubernetes cluster.

What about adding to an existing project?

Sometimes the best approach is not a new project but a significant improvement to an existing one. Adding a proper monitoring setup to your infrastructure deployment, building a CI/CD pipeline for your Kubernetes project, or extracting reusable Terraform modules from your existing code all qualify as meaningful portfolio improvements. The key is that the result demonstrates something new.

Real project vs tutorial: the honest test

Here is a useful test to distinguish between a real project and a tutorial completion, beyond the architecture-decisions question:

Ask yourself: If I started this project from scratch right now with no notes and no guide, could I build it?

If yes — you understood the project well enough to own it. List it.

If no — you followed steps but haven’t fully internalised them. Build it again from scratch (or modify it significantly) before listing it.

This matters because interviews explore exactly this. An interviewer who says “Imagine you needed to rebuild this project from scratch, how would you approach it?” is checking whether you own the knowledge or just completed the exercise.

How many projects is the right number

On your CV: two to four projects for junior and self-taught engineers. This is the range where breadth is visible without implying that quantity is compensating for quality.

On GitHub (pinned): up to six repositories. These don’t all need to be listed on your CV — some GitHub projects can demonstrate curiosity and experimentation without needing to be central to your application narrative.

For more on how to present each project in your CV’s projects section, see how to write the projects section on your cloud CV. For how to structure your GitHub profile to support these projects, see how to build a cloud engineering GitHub portfolio.