The one project that makes a junior cloud resume worth reading
Most junior portfolios are a screenshot of a VM someone spun up once and a README that says "deployed a web app to Azure." This is the project that clears that bar in one line: a pipeline that deploys infrastructure to Azure on its own, with no password stored anywhere.
New to cloud? CAMPUX is a free, build-first course. Start here →
Here is the thing an interviewer is actually looking for when they open your GitHub. They want evidence that you deploy the way a working team deploys — from a repository, through automation, with a review step — and not by clicking around in the portal and hoping you can remember what you did. A CI/CD pipeline that stands up Azure infrastructure gives them that evidence in the first thirty seconds. You do not have to explain it. They read the repo and they know. That is why this one project pulls more weight than five tutorials-followed-along projects stacked together.
The project, in plain terms: a GitHub repository holding your infrastructure as code, plus a GitHub Actions workflow that logs into Azure using OpenID Connect — with no client secret stored in the repo — previews every change, and then applies it to more than one environment. Let me walk through what belongs in it and why each piece is the part a hiring manager quietly checks for.
Infrastructure as code, sitting in the repo
The center of the project is a template that describes your Azure resources in text: a storage account, a web app, a resource group, whatever you like. Use Bicep (Azure's native domain-specific language) or Terraform — either is fine, and either signals the same thing. What matters is that the infrastructure lives as code you can read, diff, and review, not as a thing that exists only because someone once clicked "Create." A Bicep file that takes a parameter, like a three-to-eleven character storage prefix, and produces a storage account is enough to start. The employer is not grading the complexity of the resource. They are checking that you understand infrastructure belongs under version control.
OIDC federated auth, so there are no secrets
This is the part that separates a 2026 portfolio from a 2020 one, and it is worth getting exactly right. The old way to let GitHub deploy to Azure was to create a service principal, generate a client secret, and paste that secret into your repository. It works, and it is also a long-lived password sitting in your settings that you have to remember to rotate and that leaks if anyone ever gets into the repo.
The modern way uses OpenID Connect. You configure a federated identity credential on a Microsoft Entra application or a user-assigned managed identity, and that credential is set to trust tokens issued by GitHub Actions to your specific repository and branch. When the workflow runs, the azure/login action asks GitHub for a short-lived OIDC token, Entra ID checks that the token's issuer and subject match the federated credential you set up, and — if they do — hands back a temporary Azure access token that expires on its own. No client secret is ever stored. Nothing to rotate, nothing to leak.
Two small details make it work, and both are things an interviewer might ask you to explain. First, the workflow job needs permissions: id-token: write so it is allowed to request that OIDC token. Second, you still store three non-secret values as GitHub secrets — the client ID, tenant ID, and subscription ID — but those are identifiers, not passwords; knowing them does not let anyone into your account. Being able to say that sentence out loud is worth more than the whole rest of the project.
A short-lived token minted per run, not a password you paste in once and forget.
More than one environment, and a plan before the apply
A single deploy to a single environment reads like a demo. Two environments read like a system. Structure the repo so a change flows through a dev environment and a prod environment — typically triggered by different branches or a pull-request-to-merge flow, and often using GitHub Environments so prod can require an approval before anything ships. This shows you understand that you do not push straight to production, and that a human gate exists for the environment that matters.
The other half is the preview step. Before your pipeline applies anything, it should run a what-if operation (for Bicep) or a plan (for Terraform) that compares your template against what already exists and prints what would be created, changed, or deleted — without touching anything. Wire this to run on the pull request so a reviewer reads the plan before approving the merge. The difference between a pipeline that runs what-if and one that just deploys is the difference between a candidate who has been burned by a blind deploy and one who has not yet. Interviewers can tell which one you are.
The README is not an afterthought; it is the first thing a reviewer reads and often the only thing. Open with a two-sentence description of what the pipeline does. Add a small architecture diagram — boxes and arrows showing GitHub Actions requesting an OIDC token, Entra ID validating it, and the deploy landing in a resource group. List the resources the template creates, the environments, and the trigger for each. Then, in one honest paragraph, explain the OIDC trust relationship in your own words. A clear README on a modest project beats a bare repo on an ambitious one every time.
Why this is the strongest line on the resume
Screen a stack of junior cloud resumes and they blur together — the same certifications, the same "familiar with Azure," the same handful of click-ops projects. A working CI/CD pipeline breaks the pattern because it proves three separate competencies in a single artifact: you write infrastructure as code, you handle authentication the secretless modern way with OIDC, and you understand automated delivery across environments with a review gate. Each of those shows up on real job descriptions. Having all three demonstrated in one public, readable repository is rare at the junior level, and it moves you out of the "took some courses" pile and into the "has actually shipped" pile.
It also gives you something concrete to talk about. Half of interviewing is having a real thing you built that you can reason about under questioning. "Walk me through how your pipeline authenticates to Azure" is a gift of a question when the honest answer is a federated credential you configured yourself and can explain from memory. You are no longer describing a tutorial. You are describing your work.
The takeaway
Build the small version well rather than the big version halfway. One Bicep or Terraform template in a repo, a GitHub Actions workflow that logs into Azure with an OIDC federated credential so no secret is stored, a what-if step that previews the change on a pull request, two environments with prod behind an approval, and a README with a diagram that explains the trust relationship in your own words. That is a portfolio project a cloud team recognizes as one of their own, and it is the line on a junior resume that makes the rest of the page worth reading. If you want the deeper story on the auth model, the companion note on OIDC pipelines with no stored secrets goes further, and capstone project ideas has more builds in the same spirit.
Questions people also ask
What is a CI/CD pipeline in Azure?
It is an automated path that takes a code or infrastructure change from your repository to a running environment in Azure. Continuous integration builds and validates the change on every push; continuous delivery deploys it. For an infrastructure project, the pipeline authenticates to Azure, previews the change, and applies your Bicep or Terraform templates to a resource group, so nobody deploys by hand from a laptop.
How does GitHub Actions authenticate to Azure without a stored secret?
It uses OpenID Connect. You configure a federated identity credential on a Microsoft Entra application or a user-assigned managed identity that trusts tokens from your specific repository and branch. At run time the azure/login action requests a short-lived OIDC token from GitHub, Entra ID checks the issuer and subject match, and returns a temporary Azure access token. No client secret is ever stored in the repo.
What should an Azure CI/CD project include to impress an employer?
Infrastructure as code in the repo (Bicep or Terraform), OIDC federated authentication so there are no stored secrets, more than one environment such as dev and prod, a what-if or plan step that previews changes before they apply, and a clear README with an architecture diagram. Together these show you deploy the way a real team does, not by clicking in the portal.
What does the what-if step do in a Bicep pipeline?
The what-if operation compares your Bicep template against what already exists in Azure and prints what would be created, modified, or deleted, without changing anything. In a pipeline you run it on a pull request so a reviewer can read the plan before approving. Terraform's plan command does the same job. It is the difference between an informed deploy and a blind one.
Is a CI/CD pipeline a good portfolio project for a junior cloud engineer?
Yes. It is one of the strongest single lines a junior can put on a resume, because it demonstrates three things employers screen for at once: infrastructure as code, secretless authentication with OIDC, and an automated deployment workflow across environments. It is also public and readable, so an interviewer can open the repo and see exactly how you work before you have said a word.