Cloud Portfolio for Junior Engineers: What Actually Matters

Junior cloud engineer portfolios get judged differently from mid-level or senior ones. Hiring managers know you have limited experience. What they are assessing is not the complexity of what you built — it is whether you approach engineering problems carefully, document your decisions, and show the ability to learn and grow. This guide is specifically about what matters at that level and what does not.

What hiring managers expect at junior level

When a hiring manager reviews a junior candidate’s portfolio, they are answering a different question than when they review a mid-level candidate. The mid-level question is “can this person handle production systems independently?” The junior question is “can this person learn, think carefully, and grow into this role?”

The implications:

You do not need to have built a distributed multi-region system. You need to have built something real and thought about it carefully.
You do not need five projects. You need two or three projects you can talk about confidently under questioning.
You are not expected to know everything. You are expected to be honest about what you do not know and show that you investigated it.

Junior hiring managers are looking for green flags, not the absence of all red flags. A project with a gap in knowledge but a README that says “I used a wildcard IAM policy here — in production I would scope this to the specific resource ARNs” shows more awareness than a project that does not mention IAM at all.

What a realistic junior portfolio looks like

A competitive junior cloud engineering portfolio typically has:

Two or three projects covering different skill areas
Infrastructure provisioned with code — Terraform, SAM, or similar. Not manually deployed through a console.
One project with a working CI/CD pipeline — even a basic GitHub Actions workflow that runs tests and builds a Docker image
READMEs that explain decisions — not just setup instructions, but why you made the choices you made
No credentials stored in the repository — and ideally a brief note in the README about how secrets are handled

You do not need Kubernetes, multi-region deployments, or distributed tracing at junior level. Those are impressive if you have them, but their absence is not a disqualifier.

The most common junior portfolio mistakes

Tutorial clones with no modification

Following a tutorial step-by-step and putting the result in a repository is not a portfolio project — it is homework. Hiring managers recognise tutorial projects. Even a small modification — adding an extra service, changing the IAM design, adding monitoring — is enough to make the project yours. But the bigger point is the README: your explanation of the decisions is what distinguishes your work from following instructions.

No README or a one-line README

A repository with a README that says “My cloud project” or “Terraform project for learning” tells a hiring manager nothing. They will close the tab. The README is the point of the portfolio project — it is where your thinking is visible. A project with a strong README but imperfect code is far better than a project with perfect code and no explanation.

Admin permissions on everything

Lambda functions with AdministratorAccess, EC2 instances with root credentials, IAM policies with */* — these are the fastest way to look like a beginner. You do not need to get IAM perfect at junior level. But you need to show that you know least-privilege exists and that you tried to apply it, even imperfectly.

Console-deployed infrastructure

If the infrastructure cannot be reproduced from the repository — if it requires logging into the console and clicking through steps — it is not portfolio-ready. Infrastructure as code is the baseline expectation for cloud engineering roles. Even if you clicked to build it first, write the Terraform or CloudFormation before calling it done.

Abandoned and half-finished repositories

A GitHub profile with ten repositories that are all partially complete and unpin sends a worse signal than three polished, complete projects. Archive or make private anything that is half-finished or tutorial-based. Pin only the work you want to be judged on.

What to build first as a junior

If you are starting from scratch, this is the recommended order:

A serverless API or static website — something achievable in a few days that proves you can deploy cloud resources and write infrastructure code. Not impressive, but foundational.
A CI/CD pipeline — attach a GitHub Actions pipeline to project 1. This is the single most expected build for junior cloud and DevOps roles.
A networking project — a two-tier VPC (public and private subnets) provisioned with Terraform. Covers the networking fundamentals that appear in every cloud interview.

These three are achievable in 30 days with consistent effort. They cover infrastructure, CI/CD, and networking — three of the four most expected skill areas for cloud engineering junior roles.

For a detailed 30-day plan, see how to build a cloud portfolio fast.

Making your portfolio interview-ready

A portfolio is interview-ready when you can answer these questions for each project:

What does the project do?
Why did you build it that way? (What alternatives did you consider?)
What was the hardest part to figure out?
What would you do differently if you were deploying this to production?
What did you learn from building it?

Practice saying the answers out loud. The first time you articulate “I chose DynamoDB here because I wanted a schemaless data store and the access pattern was simple key-value lookups” out loud will be awkward. The fifth time it will sound natural.

For more on technical interview preparation, see the junior cloud interview questions guide and entry-level cloud interview guide.

How to present your projects in applications

In your CV, list each project with:

A one-sentence description of what it is
The technologies used (Terraform, AWS Lambda, DynamoDB, GitHub Actions)
One specific decision or achievement — “used IAM least-privilege to scope Lambda permissions to specific DynamoDB table ARNs” rather than “learned AWS”
A link directly to the repository (not just to your GitHub profile)

The specific decision is the most important part. It is what distinguishes “I built a Lambda function” from “I built a Lambda function and thought carefully about its permissions.” The latter is what gets a technical hiring manager to click the link.

For the full CV projects section strategy, see how to write the projects section on your cloud CV.