The Cloud Resume Challenge on Azure: step by step for absolute beginners

The most recognised portfolio project in cloud, rebuilt for someone who has never opened the Azure portal. Seven chunks you can finish in an evening or a weekend each, the free-tier route through every one of them, and how to talk about the thing once it is built.

The Cloud Resume Challenge on Azure is a portfolio project where you write your resume in HTML and CSS, host it on Azure as a static site over HTTPS on your own domain, add a visitor counter built on Azure Functions and Cosmos DB, and automate the deploys with GitHub Actions. Done one chunk at a time, a beginner can finish it in four to six weeks without spending anything on Azure.

I get asked about this project more than any other, usually by someone who has read the official page, felt the sixteen steps land on them all at once, and closed the tab. The steps are fine. The problem is that they are written for people who already know what a storage account is. This is the same project, in the same order, but cut into chunks a true beginner can finish one at a time, with the class on this site that teaches each piece linked from the chunk that needs it, and with the free route marked at every fork, because the second most common reason people abandon it is a bill they did not expect.

What the Cloud Resume Challenge is, and why hiring managers know the name

Forrest Brazeal published the challenge in 2020 as a dare to people trying to break into cloud without experience: build your resume as a website, but make the website a real cloud application. A static front end, a serverless API, a database, a pipeline, infrastructure written as code, and a blog post at the end explaining what you learned. The original was AWS; the Azure version swaps the services and keeps the shape. Since then it has been done tens of thousands of times, and that is exactly why it works on a resume. When an interviewer sees "Cloud Resume Challenge" they know what you built, roughly how hard it was, and that you finished. It is a project with a reputation, and you borrow the reputation.

It also happens to be a near-perfect sample of a junior cloud job: a bit of hosting, a bit of serverless, a bit of database, a bit of DNS and certificates, and a pipeline that ties them together. If you can explain every piece of it, you can answer most of a first-round technical screen.

The seven chunks (your weekly plan)

Each of these is one sitting: an evening for the small ones, a weekend for the two in the middle. Do them in order, because each one depends on the last, and commit to GitHub at the end of every chunk even when it is ugly.

1. Write the resume in HTML and CSS. One page, one stylesheet, in a GitHub repository.
2. Host it as a static site on Azure. Azure Static Web Apps on the free tier, or a Storage account's static website feature.
3. Put it on your own domain over HTTPS. A custom domain and a managed certificate.
4. Build the counter API on Azure Functions. One HTTP-triggered function that increments and returns a number.
5. Store the count in Cosmos DB. A free-tier account the function reads from and writes to.
6. Call the API from the page. A few lines of JavaScript that fetch the number and display it.
7. Automate deploys with GitHub Actions. A workflow that tests and deploys on every push, signing in with OIDC.

Chunks 1 to 3: the front end

1. The resume itself

Write it as one index.html with a style.css beside it. Do not reach for a framework; the whole point of a static site is that it is files. If you have never written HTML, spend one evening with any beginner tutorial and copy the structure of a resume you like: a header with your name, sections for experience, projects and skills, and a footer where the visitor count will go later. Leave a placeholder there now: <span id="count">…</span> visits. Make a GitHub repository, push it, and open the file in a browser to check it looks like a resume. That is chunk one done, and you already have the thing that gets deployed by everything that follows.

2. Hosting it on Azure

The official challenge says "Azure Storage static website", and that works: you create a storage account, turn on the static website feature, and upload your files to the $web container it creates. Class 12 walks through storage accounts from nothing, and if you want the version of this project that has you touching a storage account directly, do it that way.

But I now point beginners at Azure Static Web Apps instead, for one reason that becomes obvious in the next chunk: its free tier includes a custom domain and a managed HTTPS certificate, and the storage route does not. You create a Static Web App in the portal, point it at your GitHub repository, tell it the app is in the root folder, and it generates a GitHub Actions workflow for you and deploys. You will replace that workflow with your own in chunk seven, so do not worry about understanding it yet. Within a few minutes you have a public URL that serves your resume.

3. Your own domain, over HTTPS

Buy a domain if you do not have one; that is the one thing on this list that costs money, and it is a cost you will keep using for the rest of your career. In the Static Web App, add the domain under custom domains, add the DNS record it asks for at your registrar (a CNAME for www, or a TXT record plus an ALIAS/ANAME for the bare domain, depending on the registrar), and wait. DNS changes take anywhere from minutes to a day to propagate, which is why this chunk is "an evening plus DNS wait". Azure issues and renews the certificate for you. When https://www.yourname.dev loads your resume with the padlock, you are done.

If you took the storage route in chunk two, this is where the cost appears. A storage account's static website cannot serve HTTPS on a custom domain by itself; you have to put Azure Front Door in front of it, and Front Door Standard has a monthly base fee that is not small for a one-page site. The full setup is in the Front Door note if you want it. It is a good thing to have done once, but not on a beginner's budget, and it is why the free route above is the default here.

Chunks 4 to 6: the visitor counter

This is the part that turns a website into a cloud application, and it is where most people learn the most. The counter is three things: an API that owns the number, a database that keeps it, and a line of JavaScript on the page that asks for it.

4. The API on Azure Functions

An Azure Function is a small piece of code that runs when something triggers it, and you pay only while it runs. Here the trigger is an HTTP request. Create a Function App on the consumption plan (that is the pay-per-run one, and it comes with a monthly free grant that a resume site will never exhaust), pick Python or JavaScript, whichever you can read, and write one function: on a request, read the current count, add one, save it, return the new number as JSON. Class 41 builds a function from scratch and explains the trigger and binding model, which is the concept that makes the next chunk almost free of code.

Test it locally with the Azure Functions Core Tools before you deploy; a function you can run on your laptop is a function you can debug. For the first version, keep the count in memory and just return it, so you can see the HTTP part working before you add the database.

5. Cosmos DB holds the number

Cosmos DB has a free tier: one account per subscription, with a monthly allowance of throughput and storage that a single counter document will never approach. Create the account with the free tier box ticked (you cannot add it afterwards), make a database and a container, and put one document in it: {"id": "1", "count": 0}. Then wire the function to it. This is where bindings earn their keep: an input binding hands your function the document, an output binding writes it back, and your code shrinks to reading a number, adding one, and returning it. Class 37 covers where Cosmos DB fits among Azure's databases and why a document store is the right shape for a value like this.

The official challenge lists Cosmos DB's Table API for this step. Either API works. I lean to the core (NoSQL) API because the binding support is the most straightforward and the free tier applies either way.

6. The page asks for the number

Back in index.html, a few lines 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, and the counter will not work. This is deliberate, and it is the most useful failure in the whole project: the browser blocks the request because your resume's domain and your function's domain are different, and the function has not said it trusts yours. Open the browser's developer tools, read the error, and learn the word CORS. Then go to the Function App's CORS settings, add your resume's domain (and http://localhost for testing), and reload. When the number appears and goes up when you refresh, stop and enjoy it. You have a static site talking to a serverless API backed by a database, and every one of those words now means something to you.

Chunk 7: the pipeline, with no secrets in it

Up to now you have been deploying by hand or with the workflow Azure generated. The last chunk replaces that with one you wrote and understand: on every push to main, GitHub Actions runs a test against the function, deploys the function, and deploys the site. Class 22 teaches the workflow file from the first line, and Class 23 teaches the one part of this that separates a beginner's pipeline from a professional's: signing in to Azure from GitHub with OIDC, so there is no long-lived password or service-principal secret stored in the repository. Older tutorials have you paste a client secret into a GitHub secret. Do not; a federated credential on an app registration does the same job with nothing to leak, and "why did you use OIDC instead of a secret" is an interview question you now answer from experience. The reasoning is in pipelines with no secrets.

The test can be tiny: call the function's URL and assert you get a 200 and a JSON body with a number in it. It is 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 the workflow is green, make a small change to the resume, push it, and watch it appear on your domain without you touching the portal. That moment is the end of the challenge as most people experience it, and it is the moment worth writing about.

The two steps I have left out, and whether to do them

The official list has sixteen steps; I have folded them into seven, and dropped two on purpose. The first is the certification: the challenge suggests passing AZ-900 first. It is a fine idea and a real credential, but it is not a prerequisite for any chunk above, so do not let it delay the build; do the build, then decide whether the exam is worth the fee for you. The second is infrastructure as code: writing the storage, function and database as a Bicep or Terraform file instead of clicking them into being. This one I would do, as an eighth chunk, after everything works, because rebuilding something you already understand as code is the best way to learn IaC there is, and it is the skill that most reliably gets a junior past a screen. Class 20 is the place to start, and the IaC pillar explains why it matters to an employer.

Cost, gotchas, and how to keep it at $0

• Take the free route at each fork. Static Web Apps free tier, Functions on consumption, Cosmos DB free tier ticked at creation. Those three decisions are the whole cost story.
• The paid fork is HTTPS on a custom domain in front of Storage. That needs Front Door and a monthly fee. If you took the Storage route and see a Front Door line on the bill, that is why.
• Only one Cosmos DB free-tier account per subscription. If you already have one, a second account is billed. Reuse the first.
• Turn off Application Insights ingestion you are not reading, or cap it. The Function App offers to create one; it is useful, but Log Analytics ingestion is the meter that quietly bills people who thought everything was free.
• Keep everything in one resource group, so that if you ever need to stop, deleting the group deletes the lot.
• Service names drift. As of September 2026 the services above are the current ones; the classic Azure CDN that older Cloud Resume Challenge guides use for HTTPS has stopped issuing certificates and is retiring, which is why so many Azure walkthroughs of this project no longer work as written.

How to talk about it in an interview

Finishing is half the value. The other half is being able to describe it in a way that sounds like work rather than a tutorial. Prepare three stories, one sentence of setup and three or four of detail each, and rehearse them out loud:

• The thing that broke. "The counter didn't work the first time because of CORS. I read the browser error, found that the function wasn't allowing my domain, fixed it in the Function App's settings, and understood for the first time why the browser cares." Every interviewer has hit CORS. This story tells them you debug by reading errors, not by pasting them into a search box and copying the first answer.
• The decision you made. Why Static Web Apps over Storage plus Front Door (cost and a managed certificate), why OIDC over a stored secret (nothing to leak), why Cosmos DB's free tier over a SQL database (a single document does not need a relational engine). Junior candidates who can say "I chose X over Y because" are rare.
• What you would do next. Infrastructure as code if you have not done it, a staging slot, an honest visitor count, a WAF in front. Naming a sensible next step shows you know where the project stops and real production starts.

Put the live URL on your resume and the repository link next to it. Then go through the Azure cloud engineer interview questions and notice how many of them you can now answer with "when I built my resume site, I…". That sentence is the whole reason to do the challenge.

Questions people also ask

What is the Cloud Resume Challenge?

It is a well-known portfolio project, created by Forrest Brazeal, that has you build and deploy your own resume as a cloud application. On Azure that means an HTML and CSS resume hosted as a static site over HTTPS, a visitor counter powered by Azure Functions and Cosmos DB, and automated deployment with GitHub Actions. Finishing it shows real, end-to-end cloud skill rather than a list of services you have read about.

How do I do the Cloud Resume Challenge on Azure?

Break it into chunks. Write the resume in HTML and CSS, host it as a static site (Azure Static Web Apps on the free tier is the $0 route), put it on your own domain over HTTPS, add a visitor counter with an Azure Functions API backed by Cosmos DB, call that API from the page, then automate deploys with GitHub Actions. One chunk at a time keeps a beginner from being overwhelmed by the whole thing at once.

How long does the Cloud Resume Challenge take?

For an absolute beginner doing one chunk a week alongside a job, my estimate is four to six weeks. It goes faster if you already know some HTML or have touched the Azure portal, and slower if every service is new to you. Speed is not the point. Finishing something real, and understanding each piece well enough to explain it in an interview, is.

Is the Cloud Resume Challenge worth it in 2026?

Yes, for a job-seeker with a thin resume it is one of the highest-value projects you can do. Employers recognise the name, and more importantly it makes you touch hosting, serverless, a database and CI/CD in one connected build, which is the spread a junior role expects. It gives you a portfolio piece and a set of interview stories at the same time.

Does the Cloud Resume Challenge cost money?

It can be built inside Azure's free allowances if you choose the free route at each step: Static Web Apps on the free tier for the site, custom domain and certificate, a Functions app on the consumption plan, and Cosmos DB on its free tier. The one path that does cost money is HTTPS on a custom domain in front of a Storage account, which needs Azure Front Door and its monthly base fee. Set a budget alert first and delete what you are not using. The optional costs are the domain name itself and, if you add it, the AZ-900 exam fee.