How Many Cloud Portfolio Projects Do You Actually Need?

Why “how many?” is the wrong question

The number of projects matters far less than the quality and relevance of those projects. A portfolio of ten projects where each one is shallow, undocumented, or tutorial-based will impress no one. A portfolio of two projects where each one demonstrates clear architectural decisions, proper IAM, infrastructure as code, and a strong README will get you interviews.

The right question is not “how many projects do I need?” It is: “Can I talk confidently about the projects I have, and do they cover the skills the roles I am applying for require?”

If the answer to both is yes: stop building and start applying.

How many projects at each career stage

Entry-level and junior roles (0–1 years experience)

The minimum: two projects. The target: two to three projects.

At this stage, the goal is to demonstrate that you can build something real, provision infrastructure as code, and document your decisions. You are not expected to have a sophisticated multi-service distributed system. You are expected to have evidence that you have put what you have learned into practice.

Two projects is enough to interview with. Three projects — if they cover different skill areas — is enough to look well-rounded. Beyond three at this stage, you are almost certainly over-building.

Mid-level roles (1–3 years experience)

The minimum: two or three strong projects. The target: three to four projects spanning different skill areas.

At mid-level, breadth starts to matter. If all four of your projects are serverless APIs, that looks narrow for a cloud engineering or DevOps role. Two or three projects that span infrastructure, CI/CD, Kubernetes or containerisation, and optionally monitoring or security gives a broader signal.

But three solid, well-documented projects covering different areas will compete well against five shallow ones every time.

Senior roles (3+ years experience)

At senior level, your work history carries more weight than your portfolio. Employers hiring at senior level are more interested in what you have built in real jobs than in portfolio side projects. If you are applying for senior roles, two or three portfolio projects that are genuinely advanced (multi-region, platform engineering, cost engineering) are worth more than a large portfolio of standard builds.

If you have a strong work history, your portfolio might be less important than your ability to discuss the systems you built at your previous jobs.

Think coverage, not count

Instead of counting projects, think about skill area coverage. For most cloud engineering and DevOps roles, you want evidence in:

You do not need one project per row. A Kubernetes project provisioned with Terraform and deployed via a GitHub Actions pipeline covers three rows at once. Two or three projects can cover the full table if designed deliberately.

Before starting a new project, ask: what skill area does this cover that my existing projects do not? If the answer is “none — it is another serverless API,” spend that time improving an existing project’s documentation or preparing for interviews instead.

Signs you have enough and should start applying

• You can answer “tell me about a project you built” with a confident, specific, 2-minute answer for each project
• Your projects cover at least two or three different skill areas from the table above
• Every project has a README that explains the architecture decisions, not just the setup instructions
• The infrastructure in every project is provisioned with code — nothing is console-only
• You have no stored credentials in any repository

If all five bullets are true: your portfolio is ready. Start applying.

Signs you are using projects to avoid applying

Portfolio over-building is a real pattern. Watch for these signals in yourself:

• You have been building for more than three months without a single job application
• You start new projects instead of finishing existing ones
• You tell yourself the portfolio needs “one more project” before it is ready
• You add features to existing projects instead of documenting them and moving on
• You are researching what projects to build rather than applying for jobs with what you have

The job search is uncomfortable. Building projects is not. Recognising this dynamic in yourself is the first step to breaking out of it.

A useful rule: once you have two projects that satisfy all five bullets in the previous section, every hour of project building should be matched by an hour of job applications. This ratio pushes you toward applying without forcing you to stop learning entirely.

A concrete quality vs quantity comparison

Consider two candidates applying for the same junior cloud engineer role:

Candidate A has eight GitHub repositories. Two are tutorial clones with no modification. Three are half-finished projects with no README. Two have one-line READMEs (“This is my Terraform project”). One has a proper README but uses console-deployed infrastructure.

Candidate B has two GitHub repositories. Both are fully documented with architecture decisions, IAM design explanations, and deployment instructions. Both use Terraform for infrastructure. One includes a working CI/CD pipeline.

Candidate B will almost always get further in the process. The number “two” does not look impressive until a hiring manager actually reads the repositories.