I flew helicopters for a living. If I had to break into Azure again, I'd start with the Cloud Resume Challenge

Quick bit of background so you know who's talking. I didn't do computer science. I flew helicopters for a living for a few years, and at some point I realised the thing I actually wanted to do was build systems, not fly them. So I taught myself, got a foot in the door in enterprise IT, and kept going. That was about nine years ago. The last six have been all Azure, and these days I do cloud and DevSecOps work for a living and run a free bootcamp on the side. I still fly, just for fun now.

People message me fairly often asking what to build first when they've got no degree and nothing on their resume. My answer is nearly always the Cloud Resume Challenge, but with a warning I wish someone had given me: most of the Azure walkthroughs out there will quietly cost you about $35 a month the moment you want HTTPS on your own domain. Nobody mentions it. You find out when the bill turns up.

That, plus the fact that the official page hits you with sixteen steps at once, is why I think so many people open it, feel their stomach drop, and close the tab. So this is my version. Same project, same order, but chopped into seven pieces you can do one at a time, and I've marked the free option at every point where there's a paid one.

Why it's worth doing at all

Forrest Brazeal put the challenge out in 2020. The idea is simple: build your resume as a website, but make the website a proper cloud app underneath. Static site, serverless API, database, pipeline, the lot. Tens of thousands of people have done it since, and that's actually the point. When a hiring manager sees "Cloud Resume Challenge" on your resume they already know roughly what you built, how hard it was, and that you finished it. You're borrowing the project's reputation, which is a fair trade when you don't have one of your own yet.

It's also, almost by accident, a decent sample of what a junior cloud job actually involves. Some hosting, some serverless, a database, DNS and certificates, and a pipeline gluing it together. If you can explain every piece of it you'll get through most first-round technical screens.

Before anything else

Make the free account, then go straight to Cost Management and set a budget of $1 with alerts at 50, 80 and 100 percent. Do this before you create a single resource. If you stick to the free options below, nothing in this project should cost anything, and the alert is how you find out early if you've wandered off the path.

The seven chunks

Each one is a sitting. The small ones are an evening, the two in the middle are a weekend. Push to GitHub at the end of every chunk, even when it's a mess.

1. Write the resume

One index.html, one style.css next to it. Don't reach for a framework. The whole reason a static site is nice is that it's just files. If you've never written HTML, spend one evening on any beginner tutorial and copy the shape of a resume you like. Leave a spot in the footer for the visitor count, something like <span id="count">…</span> visits. Make a GitHub repo, push it, open the file in your browser and check it looks like a resume. Done. Everything after this is about getting that file onto Azure in progressively fancier ways.

2. Get it hosted

The official challenge says to use a Storage account's static website feature, and that does work. But I've started pointing beginners at Azure Static Web Apps instead, and the reason becomes obvious in the next chunk: the free tier includes a custom domain and a managed HTTPS certificate. The storage route doesn't. You create a Static Web App in the portal, point it at your GitHub repo, tell it the app lives in the root folder, and it deploys. A few minutes later you've got a public URL serving your resume. It also generates a GitHub Actions workflow for you; ignore that for now, you'll replace it in chunk 7.

3. Put it on your own domain, with HTTPS

Buy a domain if you don't have one. It's the only thing on this list that costs money, and you'll be using it for the rest of your career anyway. In the Static Web App, go to custom domains, add yours, add whatever DNS record it asks for at your registrar, and then wait. DNS can take anywhere from a few minutes to a day, which is why this chunk is "an evening plus waiting". Azure sorts the certificate out for you. When your domain loads with the padlock, you're done.

Now, the trap. If you went with the Storage account in chunk 2, this is where it bites. A Storage static site can't serve HTTPS on a custom domain on its own. The old answer was to put Azure CDN in front of it with a free managed cert, and that's what most of the Azure CRC guides still tell you to do. Except classic CDN stopped issuing those certs in 2025 and the whole product is being retired. The current answer is Azure Front Door, and Front Door Standard has a base fee of around $35 per profile per month before you've served a single request. For a one-page resume, that's the entire cost of the project, every month, for as long as you leave it up. Static Web Apps gives you the same domain and certificate for free. By all means do the Front Door version later so you can talk about it in an interview. Just don't start there.

4. Build the counter API

An Azure Function is a small bit of code that runs when something pokes it, and you only pay while it's running. Here the poke is an HTTP request. Create a Function App on the consumption plan (that's the pay-per-run one, and it comes with a monthly free grant that a resume site will never get near), pick Python or JavaScript depending on which you can read, and write one function: take a request, read the current count, add one, save it, send the new number back as JSON.

Get the Azure Functions Core Tools and test it on your laptop before you deploy anything. A function you can run locally is a function you can actually debug. For the first go, just keep the count in memory. You want to see the HTTP bit working before you bring a database into it.

5. Put the count in Cosmos DB

Cosmos DB has a free tier. One per subscription, with a monthly allowance that a single counter document is never going to trouble. Tick the free tier box when you create the account (you can't add it afterwards, I've watched people learn that the expensive way), make a database and a container, and drop one document in: {"id": "1", "count": 0}.

Then wire the function up to it. This is where Functions bindings earn their keep. An input binding hands your function the document, an output binding writes it back, and your code shrinks to: read a number, add one, return it. The official challenge mentions the Table API for this; either works, I just find the NoSQL API's bindings more straightforward and the free tier applies to both.

6. Make the page ask for the number

Back in index.html, at the bottom:

<script>
fetch("https://YOUR-FUNCTION-APP.azurewebsites.net/api/counter")
  .then(r => r.json())
  .then(d => { document.getElementById("count").textContent = d.count; })
  .catch(() => { document.getElementById("count").textContent = "–"; });
</script>

Push it. It won't work. I promise this is the most useful thing that happens in the whole project. Your resume is on one domain and your function is on another, and the browser refuses to let the page call it because the function hasn't said it trusts your domain. Open the browser dev tools, read the error, and go and learn what CORS is. Then go to the Function App's CORS settings, add your resume's domain (and http://localhost for testing), reload, and watch the number go up when you refresh. Take a minute there. A static site talking to a serverless API backed by a database, and every one of those words now means something to you.

One thing to be honest about: this isn't a real visitor counter. Every refresh adds one and a bot will add a thousand. Doesn't matter. The plumbing is the exercise. If an interviewer asks how you'd make it honest, that's a good conversation to have (dedupe by a hashed IP for a window, count only the first load, that kind of thing), but don't build any of that before chunk 7.

7. The pipeline, and why there are no secrets in it

Up to now you've been deploying by hand or with the workflow Azure generated. Replace it with one you wrote and understand: on every push to main, run a test against the function, deploy the function, deploy the site.

The part that separates a beginner's pipeline from a proper one is how it signs in to Azure. Older tutorials have you paste a client secret into GitHub secrets. Don't. Use OIDC: a federated credential on an app registration does exactly the same job with nothing stored that could leak. And "why did you use OIDC instead of a secret" is a question you'll now be able to answer from having done it, which is worth more than most certs.

The test can be tiny. Call the function's URL, check you get a 200 and a JSON body with a number in it. It's there so you can say the pipeline has a test in it, and so that the day you break the function, the pipeline tells you before your resume does.

Once it's green, change one word on your resume, push, and watch it show up on your domain without you touching the portal. That's the moment most people mean when they say they finished the challenge.

Two things I left off the list

The certification. The official challenge suggests passing AZ-900 first. It's a fine cert and a real credential, but it isn't a prerequisite for anything above, so don't let it hold up the build. Build first, then decide if the exam fee is worth it for you.

Infrastructure as code. Writing the storage, function and database as Bicep or Terraform instead of clicking them into existence. This one I would actually do, as an eighth chunk, once everything works. Rebuilding something you already understand as code is the best way I know to learn IaC, and it's the skill that most reliably gets a junior through a screen.

Keeping the bill at zero

• Static Web Apps free tier, Functions on consumption, Cosmos DB free tier ticked at creation. Those three choices are basically it.
• The one paid fork is HTTPS on a custom domain in front of a Storage account. That means Front Door, and Front Door means the monthly fee.
• Only one Cosmos DB free tier account per subscription. If you've already got one, reuse it.
• When you create the Function App it'll offer to set up Application Insights. It's useful, but Log Analytics ingestion is the meter that quietly bills people who thought everything was free. Cap it or turn it off if you're not reading it.
• Put everything in one resource group so that stopping is one delete.
• Service names drift. This is accurate as of September 2026. The classic CDN thing is exactly why so many older Azure CRC guides no longer work as written.

If you've done the Azure version

I'd genuinely like to know what your first month's bill was and which chunk you got stuck on. My guess is it's chunk 3 or chunk 6 for nearly everyone, and I'd rather fix the walkthrough than be right about that. And if you finished it and it got you the interview, say so in the comments. The people reading this from where I was nine years ago need to hear that a lot more than they need another tutorial.

The longer version, with each chunk linked to the free class that teaches that piece from nothing, is on CAMPUX.

Originally published on CAMPUX, a free Azure cloud engineering bootcamp.