Your GitHub is the interview before the interview
A certification proves you passed a timed exam. It cannot show anyone that you can design a system, stand it up, and keep it running. That is what a portfolio is for — and when you have no degree and no job title to point at, it may be the strongest thing on your entire application.
New to cloud? CAMPUX is a free, build-first course. Start here →
Here is the hard truth about breaking into cloud work without a degree: nobody who screens résumés owes you the benefit of the doubt. They have a stack of applicants and thirty seconds each. A cert on the page tells them you can pass a test. It does not tell them you can be handed a vague problem and produce something that works, monitors itself, and doesn't cost a fortune. The gap between "knows the material" and "can do the job" is exactly the gap a portfolio closes. Your GitHub is where you argue, in code and in prose, that you belong on the other side of that line.
What a portfolio is actually for
A portfolio is evidence. That is the whole idea, and it is worth holding onto because it changes what you build and how you present it. A hiring manager is not looking to be impressed by volume; they are looking to reduce their risk in hiring you. Every project in your repo either lowers that risk or wastes their time. The question a good project answers is the one they cannot ask a certificate: when this person hits something that isn't in the tutorial, what do they do?
So the target is not "look how much I know." It is "look how I think." A single project that shows you weighing two options, picking one for a stated reason, and living with the consequence does more than a shelf of badges ever will. You are not proving you memorized services. You are proving you can be trusted with a keyboard and a subscription that bills real money.
Nobody hires the certificate. They hire the person who can be handed a problem and not panic.
What belongs in it
Two or three real projects. Not ten. Depth is the signal that separates a candidate from a bootcamp graduate who did every lab once and remembers none of it. Each project should be something you could talk about for twenty minutes without notes, because in an interview that is exactly what happens.
Inside each one, a few things are non-negotiable:
- Infrastructure-as-code, committed to the repo. This is the single clearest signal you are past clicking around the portal. Bicep, Terraform, or ARM — the tool matters less than the fact that your environment is reproducible from a file. Click-ops leaves no trace and proves nothing. A committed Bicep file says "I can rebuild this from scratch and so can you."
- A README that explains the decisions, not just the steps. Anyone can write "run
az deployment group create." The valuable README says why — why a storage account over a database here, why this network layout, what you would change with a bigger budget. That reasoning is the part a reviewer cannot get from documentation, and it is the part that reads as senior. - An architecture diagram. One clear picture of how the pieces connect. It lets a busy reviewer understand your system in fifteen seconds instead of reading Terraform. A hand-drawn box-and-arrow diagram that is correct beats a glossy one that is vague.
- Evidence you can operate, not just deploy. Deployment is table stakes. What separates you is showing the day-two story: a CI/CD pipeline that ships changes, some monitoring or alerting, a note on cost, a paragraph on what broke and how you found it. Operating a system is most of the job, so show that you have thought about it.
Two projects that carry all of that will out-argue any wall of certificates. A good pairing to aim for: one project that stands up a real workload end to end, and one that automates the delivery of it. If you want concrete starting points, the capstone project ideas piece has several scoped for exactly this, and the CI/CD pipeline project walks through building the automation half from nothing.
Reviewers judge your repo by its README before they read a line of your code, and plenty never get past it. Open with one sentence on what the thing does and a diagram. Then the problem you set out to solve, the decisions you made and why, how to run it, and an honest "what I'd do differently." Write it for a tired engineer skimming on their phone between meetings. If the README is thin, the assumption is the work is thin — fair or not, that is how it goes.
Recruiters and engineers read it differently
Two very different people will look at your GitHub, and they are not looking for the same things. Knowing that lets you serve both.
The recruiter or HR screener usually goes first, and they are pattern-matching against a job description. They cannot read Terraform and they will not try. They scan for keywords, a tidy profile, activity that isn't a ghost town, and the sense that you are a real practitioner and not a risk. Your profile README, clear repo names, and a short pinned set of your best work do the work here. This is also where a cert earns its keep — it is the token that gets you past this filter.
The hiring engineer comes later, and they are the audience that decides. They will open your best repo, read the README, look at your commit history, and skim the actual code. They are asking whether they would trust you near production. They notice whether your commits tell a story or are one final final v2 dump. They notice whether the code is yours or lifted wholesale. They are, quietly, the person you write every README for.
The mistakes that quietly kill a portfolio
Most weak portfolios fail in the same few ways, and all of them are avoidable.
Tutorial clones with no decisions. A repo that is someone else's walkthrough, followed keystroke for keystroke, is worse than no repo — because the first interview question is "why did you build it this way," and there is no answer. If you start from a tutorial, and that is a fine place to start, change something. Break it on purpose and fix it. Add a piece the tutorial skipped. Make one real decision so you have something to defend.
A wall of certs and no code. A profile that is all badges and no builds reads as someone who studies but hasn't done. It invites the exact doubt you are trying to erase. Certs and projects are a pair, not substitutes for each other.
A repo with no README, or a lazy one. An unexplained repo asks the reviewer to reverse-engineer your intent, and they won't. A README that only lists commands is nearly as bad — it shows the steps and hides the thinking. The thinking is the point.
One more, less obvious: neglecting the GitHub hygiene. A profile picture and a two-line bio. Real repo names, not project-1. Your two or three strongest projects pinned to the top so nobody has to dig. A clean commit history with messages that mean something. None of it is hard, and its absence is read — correctly — as carelessness.
The takeaway
When you have no degree, the portfolio is not a nice-to-have that rounds out an application — it is the application. Build two or three real Azure projects, commit the infrastructure-as-code so they are reproducible, write READMEs that explain your decisions and carry a diagram, and show you can operate what you deploy and not merely stand it up. Serve the recruiter with a clean, keyword-legible profile and serve the engineer with code and reasoning that hold up to a close read. Do that, and your GitHub stops being a formality and becomes the thing that gets you the interview. When the résumé is thin, this is where you make your case — and it pairs naturally with the résumé templates that point straight at it.
Questions people also ask
What should a cloud engineer put on GitHub?
Two or three end-to-end projects, each built with infrastructure-as-code committed to the repo — Bicep, Terraform, or ARM — rather than click-ops you can't reproduce. Each project needs a README with an architecture diagram, the problem it solves, and why you made the choices you made. Show that you can operate the thing, not only deploy it: monitoring, a CI/CD pipeline, some cost or security thinking.
How many projects do I need in a cloud portfolio?
Two or three real ones beat ten shallow ones. A hiring engineer would rather read one repo that deploys a working system, explains its trade-offs, and shows you handling a failure than scroll a wall of half-finished tutorials. Depth is the signal. Each project should stand on its own and reward the ten minutes someone spends reading it.
Do you need a portfolio to get a cloud engineering job with no degree?
When you have no degree and no job title to point at, the portfolio is the evidence that replaces both. A certification proves you can pass a timed exam; it can't show you designing, deploying, and operating a system. The repo can. For a self-taught candidate it is often the single strongest thing on the application, so it is worth real effort.
Are certifications enough to get a cloud job without projects?
Rarely, on their own. A cert clears a screening filter and proves you know the vocabulary, but almost every hiring engineer has met someone certified who couldn't build anything. The pairing that works is a cert to get past the recruiter plus a portfolio to convince the engineer. One without the other leaves an obvious gap the interview will find.
What are common mistakes in a cloud engineering portfolio?
Three recur. Tutorial clones you followed step-by-step with no decisions of your own, so there is nothing to talk about in an interview. A wall of certificate badges and no actual code. And repos with no README, or a README that only says how to run it and never why you built it that way. Each one quietly tells a reviewer to move on.