How to Write the Projects Section on Your Cloud CV

For most junior cloud engineers and career changers, the projects section carries more weight than any other part of the CV. It is the place where you can demonstrate real capability without relying on a job title you haven’t yet held. This guide covers how to write it well, what to include, and the mistakes that turn genuinely good projects into weak CV entries.

Why the projects section matters so much

Certifications tell an employer what you know in theory. A GitHub project that deploys actual infrastructure and handles real-world concerns tells them something more valuable: that you can take a concept from documentation to a working implementation.

This distinction matters particularly for roles where the hiring manager is technical. They know what a certification means — it means you passed a multiple-choice exam. They also know what a clean Terraform deployment with a well-written README means: this person can think architecturally and follow through independently.

The projects section is not just for people without experience. Mid-level engineers with personal projects outside their day job often stand out too, especially if those projects demonstrate curiosity about tools or systems their employer doesn’t use.

What counts as a project worth listing

This is where many candidates get it wrong. Not every learning exercise belongs on your CV.

What qualifies

  • Something you designed and built yourself, even if the idea came from a tutorial
  • Something you can explain in full detail — architecture decisions, what went wrong, what you changed
  • Something that exists publicly on GitHub (or could with a cleanup)
  • Something that demonstrates at least one real engineering decision, not just resource creation

What doesn’t qualify

  • A tutorial you followed step-by-step — if someone else made all the decisions, it’s not your project
  • A course exercise that has a completed answer provided — these are learning materials, not portfolio work
  • A project you started but cannot demonstrate in its current state — an incomplete or broken project hurts more than it helps
  • Something you cannot explain beyond the surface level — if a question goes one step deeper than the tutorial and you cannot answer it, the project is not ready

The test is: could a technical interviewer ask you about any aspect of this project and get a real answer? If yes, list it. If no, build it further before listing it.

What to include in each project entry

Each project entry on your CV should cover four things:

  1. What you built — the type of system or application, at a high level
  2. What technologies and tools you used — specific enough to be scannable
  3. What it demonstrates — the engineering concern or skill it shows
  4. A link to the GitHub repository — if the code is public and the README is readable

Project entries should be one to four lines. Longer than that and it takes up too much space. Shorter than one line and it doesn’t provide enough context.

Weak vs strong project descriptions

Here are three examples of the same project written in different ways, with commentary on what works and what doesn’t.

Example 1 — Three-tier AWS application

Weak:

AWS Project — Deployed an application to AWS using various services.

Problem: Says nothing specific. “Various services” is meaningless. “Deployed an application” tells the hiring manager nothing about what you understood or decided.

Stronger:

Three-tier AWS web application | github.com/yourname/aws-three-tier
Deployed a Python Flask app to AWS using Terraform — VPC with public and private subnets, ALB, Auto Scaling Group of EC2 instances, and RDS PostgreSQL in a private subnet. GitHub Actions runs tests on pull requests and deploys to production on merge to main. Architecture diagram and teardown instructions in README.

Why it works: Specific services named. Architecture decision visible (private subnet for RDS). CI/CD mentioned. README signals someone thought about presentation. The GitHub link means the claim can be verified.

Example 2 — Kubernetes deployment

Weak:

Kubernetes — Deployed apps using Kubernetes and learned about containers.

Problem: Vague verb (deployed apps). The “learned about” phrase actively signals this is a learning exercise rather than a project. No specifics.

Stronger:

Kubernetes microservices deployment | github.com/yourname/k8s-microservices
Deployed a three-service application (API, worker, Postgres) to a local kind cluster. Wrote Kubernetes manifests for Deployments, Services, ConfigMaps, Secrets, and a HorizontalPodAutoscaler. Configured liveness and readiness probes; documented resource limits and why each was chosen.

Why it works: Shows you understand the components (not just “ran kubectl apply”). The note about documented resource limits signals you made engineering decisions rather than just following a guide.

Example 3 — Terraform infrastructure

Weak:

Terraform — Used Terraform to provision AWS resources as part of learning IaC.

Problem: “As part of learning IaC” positions it as a learning exercise. No specifics. No outcome.

Stronger:

Modular Terraform AWS infrastructure | github.com/yourname/terraform-aws-infra
Built a reusable Terraform module set for a standard AWS application stack: VPC, EC2 Auto Scaling Group, RDS, S3, and IAM roles with least-privilege policies. Uses remote state in S3 with DynamoDB locking. Tested with two different environments (dev and staging) using Terraform workspaces.

Why it works: Shows modular thinking. Remote state and workspace usage demonstrates awareness of production concerns. Least-privilege IAM is a security signal. This sounds like an engineer thinking about real-world use, not a tutorial.

How many projects to include

Two to four projects is the right range for most junior and self-taught candidates.

Two strong projects are better than five weak ones. A long list of thin projects signals that you’ve been building quantity rather than depth. A hiring manager who sees ten projects will assume most of them are tutorials.

Prioritise variety. If all four of your projects deploy the same basic architecture to AWS with Terraform, that shows less than two projects covering different concerns — one infrastructure project, one CI/CD project, one Kubernetes project, for example.

For guidance on which specific projects to build and include, see which cloud projects to show on your CV and GitHub.

Where to place the projects section

For junior candidates and career changers: if your work experience is not in cloud or is thin, place the projects section before the work experience section. Let your strongest material appear early.

For mid-level candidates with relevant work history: place projects after the experience section. Your paid work is more credible and should come first.

The general rule: whatever tells the best story about your technical capability should be closest to the top of the page.

Adding a GitHub link to a project entry is only worthwhile if the repository is actually presentable. A hiring manager who clicks through to find an empty repo with no README and a single commit will think less of you, not more.

For each project you list on your CV, the GitHub repo should have:

  • A clear README that explains what the project does, how to run it, and any architectural decisions worth noting
  • Sensible commit history — not a single massive commit, but not hundreds of “fix” commits either
  • No exposed secrets, API keys, or credentials
  • Working code — or clearly documented notes explaining what is in progress and why

See the full guide to building a cloud engineering GitHub portfolio for how to present your GitHub profile as a whole.

Related topics to read next

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