How to Build a Cloud Engineering GitHub Portfolio That Gets Noticed

What a hiring manager sees in the first 30 seconds

When a hiring manager or senior engineer clicks your GitHub link, they land on your profile page. In the first 30 seconds they are forming an impression based on a few things:

• Your pinned repositories — what do you choose to highlight?
• The README files on those repositories — do they explain what the project is and what decisions were made?
• The recency of your commits — is this someone who builds things consistently or someone who started repositories years ago and never returned?
• The quality of your commits — are they meaningful commits with clear messages or is it one massive “initial commit” followed by nothing?

They are not reading every line of your Terraform. They are asking: “Does this person’s GitHub suggest they think carefully about what they build?”

A GitHub with three well-maintained, documented projects is significantly more impressive than one with twenty repositories that are all variations of “hello world” or incomplete tutorials.

Your GitHub profile page

Profile README

GitHub allows you to create a profile README — a special repository named after your username that displays on your profile homepage. This is worth setting up. It doesn’t need to be long, but a short paragraph explaining who you are and what your repositories focus on gives context to anyone landing on your page.

A profile README for a cloud engineer might include:

Cloud infrastructure engineer, primarily working with AWS, Terraform, and Kubernetes.
This profile mostly contains infrastructure projects — automation, deployment pipelines, and home lab experiments.
Currently studying for the CKA. Open to discussing cloud engineering roles.

Keep it brief. A long profile README with badges, animated graphs, and emoji decoration tends to look more like a hobby project than a professional portfolio.

Pinned repositories

Pin up to six repositories. Choose projects that together demonstrate breadth across the cloud engineering skill set: infrastructure provisioning, CI/CD automation, container orchestration, monitoring, security.

Do not pin repositories that are empty, tutorial clones, or work in progress with no README. These actively harm the impression you make.

Profile photo and bio

A professional or neutral profile photo (not necessarily a formal headshot — just a clear face photo) and a short bio (your current role and focus) adds a small but real signal that this is a professional profile.

What makes a good cloud engineering repository

A repository that stands up to scrutiny by a technical hiring manager has several characteristics:

A clear, substantive README

The README is the first thing read when someone opens a repository. It should cover:

• What the project does — one or two sentences explaining the architecture or automation
• What technologies and tools it uses — and ideally why those were chosen
• How to deploy or run it — step-by-step instructions if applicable
• Architecture overview — even a brief text description of the components and how they connect is valuable; a diagram is better
• What you learned or what would you change — this signals reflective engineering, not just code completion

A repository with no README or a README that says only “This is my Terraform project” is not ready to be on your CV.

Evidence of real engineering decisions

Good cloud repositories show that you made choices rather than just followed a tutorial. Signs of real decisions:

• IAM policies with least-privilege permissions rather than */*
• Network segmentation — private subnets for databases, controlled egress
• Modules or reusable components rather than one flat file
• Comments explaining why something is configured a specific way
• State management in Terraform (remote state, locking)
• Working CI/CD pipeline using GitHub Actions

Sensible commit history

Commit history reveals how you work. A few patterns to aim for:

• Commits that represent coherent units of work — not one massive dump
• Commit messages that explain what changed (“Add RDS module with multi-AZ configuration” rather than “fix stuff” or “WIP”)
• Consistent progress over time rather than a burst of activity followed by months of silence

No secrets or credentials

Never commit AWS access keys, API tokens, passwords, or any other credentials. This is non-negotiable — hiring managers who spot credentials in a repository will not proceed with the application, and the security community will flag it publicly. Use environment variables, .env files in .gitignore, AWS Secrets Manager, or HashiCorp Vault to handle secrets. Keep a .gitignore file and check it applies correctly before committing.

What types of projects to have

A well-rounded cloud engineering GitHub portfolio typically contains a small number of projects that together cover the core skill set. You do not need one of everything — you need a few good ones that demonstrate the areas you want to be hired for.

Consider having at least one project from each of the following categories if they are relevant to your target roles:

• Infrastructure deployment: A Terraform or similar project that provisions a real application environment — compute, networking, IAM, storage, database
• CI/CD automation: A pipeline that tests, builds, and deploys something automatically — GitHub Actions is the most common and accessible choice
• Containerisation and orchestration: A Docker + Kubernetes project — even a local kind or minikube cluster with proper manifests is meaningful
• Monitoring and observability: A project showing Prometheus, Grafana, or CloudWatch dashboards and alerting configuration

Two or three strong projects in these areas outweigh ten shallow ones. For guidance on selecting which specific projects to build, see which cloud projects to show on your CV and GitHub.

Improving repositories you already have

If you have repositories that are half-finished, poorly documented, or tutorial-based, you have two options: improve them or unpin them (and ideally make them private or archive them).

The most impactful improvement you can make to an existing repository is writing a proper README. A well-written README can transform a mediocre repository into an impressive one by explaining the thinking behind the work. It is often faster than building a new project.

Other impactful improvements:

• Add a .gitignore if one is missing
• Refactor the Terraform (or similar) into modules if it is currently one flat file
• Add a CI/CD pipeline even if it just runs terraform validate and a linting tool
• Clean up commit history on branches before merging (squash commits) — the main branch should tell a readable story

Using GitHub effectively on your CV

Your GitHub URL belongs in the header of your CV, but only if the profile is presentable. If your profile has only empty repositories and tutorial clones, the link adds nothing and might subtract credibility.

Each project you list in your CV’s projects section should link directly to the specific repository, not just to your GitHub homepage. A direct link means the hiring manager can evaluate that specific project without having to navigate your whole profile.

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