Four projects that together cover most of what a mid-level cloud or DevOps posting asks for: a deployed web application, the same environment built in Terraform, a CI/CD pipeline that ships it, and a Kubernetes deployment. Each section has the architecture, the tools, and a lab to build it in. Build them in order - they stack into one system rather than four unrelated demos.
🎯 Why these four, and why in this order
The most useful thing I can tell you about portfolio projects is that four connected projects beat eight disconnected ones. Hiring managers are not counting repositories. They are looking for evidence you can take something from nothing to running, and then keep it running.
So these four are deliberately the same application, four times over, each pass adding a layer:
Project 1 → App running in the cloud (you clicked to deploy it)
Project 2 → Same app, defined in Terraform (now it is reproducible)
Project 3 → Same app, shipped by a pipeline (now it is automated)
Project 4 → Same app, on Kubernetes (now it is orchestrated)
That final repository tells a story. Four separate tutorial clones do not.
Set a budget alert on your subscription on day one. Five dollars is plenty. Then tear resources down at the end of each session. Every one of these projects fits comfortably inside a free tier if you are disciplined about cleanup.
1️⃣ Project 1: A Real Cloud Web App
Deploy an actual application with networking, a database, and monitoring. Not a static page.
The bar here is higher than a hello-world site. What makes this project count is the supporting cast: the app talks to a database, secrets live somewhere sensible, and you can answer "how would you know if this went down?"
🏗️ Architecture
| Layer | Azure | AWS |
|---|---|---|
| Compute | App Service | Elastic Beanstalk or ECS |
| Database | Azure SQL or Cosmos DB | RDS or DynamoDB |
| Secrets | Key Vault + managed identity | Secrets Manager + IAM role |
| Networking | VNet integration, private endpoint | VPC, security groups |
| Monitoring | Application Insights | CloudWatch |
✅ What makes it resume-worthy
- The database is reachable from the app and not from the public internet
- No connection strings in app settings - managed identity or a vault reference
- Application Insights is wired up and you can show a real request trace
- The README explains the architecture and one thing that broke
Create a Web App on Azure App Service
The compute layer, start to finish. Add the database, private networking, and monitoring on top of this as your own work.
Want a version with a working backend already? The serverless contact form lab gives you a real app with a Functions backend and storage, which is a good base to extend.
2️⃣ Project 2: The Whole Thing in Terraform
Rebuild Project 1 entirely in code. Destroy it. Rebuild it from scratch in one command.
This is the project that changes how interviewers read your resume. Anyone can click through a portal once. Reproducing an environment from code, with remote state and modules, is the day-job skill.
🏗️ What to build
| Component | What it demonstrates |
|---|---|
| Remote state backend | You understand state is shared and must not live on your laptop |
| Variables and tfvars | Same code, multiple environments |
| Modules | Networking as a module, app as a module |
| Outputs | Passing values between layers cleanly |
| A dev and prod workspace | Environment separation |
✅ What makes it resume-worthy
The test is simple and you should actually run it: terraform destroy, then terraform apply, and the whole environment comes back working. If you can say that in an interview and mean it, that is the project doing its job.
Configure the remote backend before your first apply, not after. Migrating state later is fiddly, and local state files routinely end up committed to public repos with secrets inside. Do it first.
🧪 Labs, in order
| Lab | Covers |
|---|---|
| Intro to Azure Terraform | Syntax and your first apply |
| Terraform Azure Backend | Remote state, do this second |
| Terraform Modules Intro | Structure and reuse |
Terraform Azure Backend: Remote State
The step that turns a Terraform demo into something a team could actually use. Remote state, locking, and why it matters.
3️⃣ Project 3: A CI/CD Pipeline That Ships It
Every commit builds, tests, and deploys automatically. No manual steps.
The clearest signal of the four, because a pipeline either works or it does not, and a green run history is evidence nobody can argue with.
🏗️ Pipeline stages
| Stage | What happens |
|---|---|
| Trigger | Push to main, or a pull request |
| Build | Compile or package the application |
| Test | Run tests, and actually fail the build when they fail |
| Security scan | Dependency and secret scanning |
| Deploy to dev | Automatic |
| Deploy to prod | Behind a manual approval gate |
✅ What makes it resume-worthy
- Authentication uses OIDC federated credentials, not a stored service principal secret
- There is a real approval gate between dev and prod
- The run history shows genuine failures that you then fixed
- The pipeline deploys the Terraform from Project 2, not portal-created resources
This is the detail interviewers probe. If your pipeline authenticates with a long-lived client secret in a repository variable, expect to be asked why. Workload identity federation is the current expected answer, and setting it up is itself a talking point.
Deploy Containerized Applications to Azure with GitHub Actions
A complete build-and-deploy pipeline. This is also the natural bridge into Project 4, since you are already producing container images here.
4️⃣ Project 4: Kubernetes
Containerize the application and run it on Kubernetes with scaling and monitoring.
The most demanding of the four and the one that most separates candidates, precisely because most people stop at three.
Be honest with yourself about sequencing though. If Projects 1 to 3 are not solid, Kubernetes will be an exercise in copying manifests you do not understand, and that shows in an interview immediately.
🏗️ What to build
| Component | What it demonstrates |
|---|---|
| Dockerfile | Multi-stage build, small image, no secrets baked in |
| Registry | Images pushed to a private registry |
| Deployment and Service | The core Kubernetes objects |
| Ingress | External traffic routing with TLS |
| ConfigMaps and Secrets | Configuration kept out of the image |
| Health probes | Readiness and liveness, configured properly |
| HPA | Horizontal autoscaling that you have actually triggered |
| Monitoring | Metrics and logs you can show |
✅ What makes it resume-worthy
Being able to explain a failure. "I set the readiness probe wrong and the deployment never became ready, here is how I diagnosed it" is worth more than a manifest that has always worked.
🧪 Labs, in order
| Lab | Covers |
|---|---|
| Write Dockerfiles and Build Custom Images | Get the image right before the cluster |
| Azure Container Registry | Somewhere private to push it |
| Create and Debug Your First Pod | Pods, kubectl, and reading failures |
| Imperative vs Declarative Pod Creation | Why manifests beat commands |
| Cluster DNS and Service Discovery | Services and how pods find each other |
Create, Inspect and Debug Your First Pod with kubectl
Do this before you touch a managed cluster. Understanding pods and kubectl is what separates deploying Kubernetes from copying manifests you cannot debug.
An AKS cluster is the one thing here that will genuinely cost money if you leave it running. Create it, work on it, and delete it the same day. Keep your manifests in git so recreating takes minutes.
📝 The README is part of the project
A brilliant project with a three-line README reads as a tutorial you followed. Every one of these four should have:
| Section | Why |
|---|---|
| The problem | What this system does and for whom |
| Architecture diagram | One image. Draw.io is fine |
| Tech and why | Justify a choice or two, briefly |
| How to run it | Someone else should be able to deploy it |
| What broke | The single most under-used section, and the most convincing |
| What I would change | Shows judgment beyond the tutorial |
That "what broke" section is the one hiring managers remember. It is the difference between someone who followed steps and someone who debugged something.
📋 All four on one page
| Project | Core skill | First lab | Realistic time |
|---|---|---|---|
| 1. Cloud Web App | Architecture, networking, monitoring | App Service | 1 to 2 weeks |
| 2. Terraform | Infrastructure as code, state | Terraform backend | 2 weeks |
| 3. CI/CD Pipeline | Automation, OIDC, gates | GitHub Actions | 1 to 2 weeks |
| 4. Kubernetes | Containers, orchestration, scaling | First pod with kubectl | 3 to 4 weeks |
Roughly two to three months at a steady part-time pace. Not a weekend.
CloudLearn: practise before you build
The labs behind each project are on CloudLearn, plus the supporting ones on storage, identity, and monitoring you will want along the way. Real Azure environments in the browser, which means no surprise bill while you are learning the pieces.
🔗 Where to go next
- 4 Azure Projects That Cost Under $1 to Build - a cost-focused set if budget is the main constraint
- 4 Cloud Skills That Actually Get You Hired in 2027 - the skills these projects are demonstrating
- 5 AI Jobs You'll See More of in 2027 - where to go after the four
Want feedback on your build before an interview?
Reviewing a portfolio project and rehearsing how you talk about it is one of the highest-leverage things you can do before interviewing. That is a big part of what I do in coaching. Send me what you have built.
