DEV Community: Victor

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

Victor — Mon, 21 Sep 2026 03:20:45 +0000

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.

Chunk	What you're using	How long	Cost if you take the free route
1. Resume in HTML/CSS	nothing on Azure yet	an evening	$0
2. Hosting	Static Web Apps (or a Storage account)	an evening	$0
3. Your domain + HTTPS	Static Web Apps custom domain	an evening, plus waiting on DNS	$0 (the domain itself is extra)
4. The counter API	Azure Functions, consumption plan	a weekend	$0
5. Storing the count	Cosmos DB free tier	an evening	$0
6. Page talks to API	a bit of JavaScript, and CORS	an evening	$0
7. CI/CD	GitHub Actions with OIDC	a weekend	$0

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.

Azure ExpressRoute vs VPN Gateway: the honest comparison

Victor — Thu, 27 Aug 2026 00:24:06 +0000

Your datacenter needs to talk to Azure. You can send that traffic through an encrypted tunnel over the public internet, or over a private circuit that never touches it. That single choice — shared road or private rail — decides cost, speed, and reliability.

Almost every organization moving to Azure keeps something on-premises, and those two worlds have to connect privately. Azure gives you two hybrid-connectivity options, and they take opposite routes to the same destination: VPN Gateway and ExpressRoute. Understanding them is really understanding one question — does your traffic ride the public internet, protected by encryption, or a dedicated line that bypasses it entirely?

VPN Gateway: an encrypted tunnel over the internet

Microsoft's description is exact: Azure VPN Gateway "can be used to send encrypted traffic between an Azure virtual network and on-premises locations over the public Internet." Your traffic still travels the ordinary internet, but inside an IPsec/IKE tunnel, so it is private even though the road is shared. It comes in a few shapes: site-to-site (your datacenter's VPN device to Azure), point-to-site (an individual remote worker to the VNet), and VNet-to-VNet. It is quick to stand up, needs no third party, and is inexpensive — the pragmatic default for dev/test and small-to-medium production links.

ExpressRoute: a private, dedicated circuit

ExpressRoute takes the other road entirely. It "lets you extend your on-premises networks into the Microsoft cloud over a private connection with the help of a connectivity provider." The defining fact: because ExpressRoute connections do not go over the public internet, they offer "more reliability, faster speeds, consistent latencies, and higher security than typical connections over the internet." You are not tunnelling through shared roads; you have a private rail line into Microsoft's network, arranged through a connectivity provider. That extra reliability and consistency costs more and takes longer to provision — but for a bank, a hospital, or a latency-sensitive enterprise workload, it is the answer.

	VPN Gateway	ExpressRoute
Path	Public internet (encrypted tunnel)	Private dedicated circuit
Reliability & latency	Best-effort internet	More reliable, consistent latency
Setup	Fast, self-service	Via a connectivity provider
Cost	Lower	Higher
Best for	Dev/test, small-medium prod, remote users	Enterprise, regulated, latency-sensitive

A VPN tunnels privately through the public road. ExpressRoute gives you a private road of your own. Same destination, very different guarantees.

They are not mutually exclusive. The grown-up pattern often uses both: ExpressRoute as the primary private connection, with a site-to-site VPN as a secure failover path if the circuit goes down. Microsoft supports this coexistence directly. So the question is not always "which one" — sometimes it is "ExpressRoute with a VPN safety net."

How to choose

Getting started, dev/test, or a small-to-medium workload where good-enough internet connectivity is fine? VPN Gateway. Fast, cheap, no provider to involve.
Remote individual users needing into the VNet? A point-to-site VPN.
Enterprise scale, strict reliability or latency needs, regulated industry, or heavy sustained data transfer? ExpressRoute — the private, consistent circuit is worth the cost and the lead time.
Mission-critical link that cannot go dark? ExpressRoute primary, VPN failover.

The mistake is treating them as "cheap one vs expensive one." They are "shared road with a lock" versus "your own private line," and the right pick follows from how much reliability, consistency, and privacy the workload genuinely demands. Say "a site-to-site VPN for now, and ExpressRoute when we need consistent latency and an SLA on the connection — with the VPN kept as failover" and you are talking hybrid networking like an architect.

Questions people also ask

Is ExpressRoute more secure than VPN Gateway?

ExpressRoute keeps traffic off the public internet, which removes a whole class of exposure a VPN carries by design. But an ExpressRoute circuit is not encrypted by default. For data that must be encrypted in transit, add MACsec on the circuit or run an IPsec VPN over ExpressRoute. VPN Gateway is encrypted from the start, just over a shared path.

Can you use ExpressRoute and VPN Gateway together?

Yes, and Azure supports the coexistence directly. The common pattern runs ExpressRoute as the primary private circuit and a site-to-site VPN as the failover path, so if the circuit drops, traffic falls back to an encrypted tunnel over the internet instead of going dark.

How much does ExpressRoute cost compared to a VPN Gateway?

ExpressRoute costs more. Its tiers run from a metered Local option up to Standard around $300 a month for 1 Gbps, plus a Premium add-on, before you add the connectivity provider's own charges. A VPN Gateway has a much lower flat cost since it rides the internet you already pay for and needs no third-party provider.

What is the difference between ExpressRoute and a site-to-site VPN?

A site-to-site VPN connects your on-premises network to Azure through an encrypted tunnel over the public internet. ExpressRoute connects the same two networks through a private circuit arranged with a connectivity provider, bypassing the internet entirely for more consistent latency and reliability.

Which is faster, ExpressRoute or VPN Gateway?

ExpressRoute is faster and more consistent. Because it does not share the public internet's congestion and routing variability, it delivers predictable latency and higher throughput. A VPN Gateway's speed depends on internet conditions between your site and Azure, which vary and can degrade under load.

Azure Front Door vs Traffic Manager: which to use, and when

Victor — Tue, 25 Aug 2026 15:46:12 +0000

Both promise to route users to the closest healthy copy of your app anywhere on earth. But one stands in the traffic path and does real work to every request, and the other just answers a DNS question and vanishes. Confuse them and you will either pay for power you do not use or reach for caching that a DNS router cannot give you.

Azure Traffic Manager is DNS-based global routing: it hands clients an endpoint address for any protocol, then steps out of the path, so its failover is only as fast as DNS TTL. Azure Front Door is an application-layer (L7) global entry point with caching, a WAF, and instant failover for HTTP/S. When an app goes global, you need something in front that sends each user to a nearby, healthy backend. Azure offers two very different answers — Azure Front Door and Azure Traffic Manager — and the single fact that explains everything else is where each one sits. Front Door sits in the path of every request. Traffic Manager sits outside the path, in DNS. Get that distinction and the rest of the comparison writes itself.

	Front Door	Traffic Manager
Layer	Layer 7 (HTTP/HTTPS)	DNS (Layer 4, any protocol)
Sits	In the request path, at the edge	Outside the path — answers DNS, then gone
Caching / TLS offload	Yes	No
WAF	Yes	No
Failover speed	Instant (in-path)	Waits for DNS TTL to expire
Best for	Global web apps & APIs wanting edge caching + WAF	Routing any endpoint (VMs, non-Azure, whole regions) by DNS

Two more names round out the family, and the split is by scope and layer: Load Balancer is L4 regional (spreads raw TCP/UDP across VMs in one region), Application Gateway is L7 regional (HTTP routing and WAF inside one region), Traffic Manager is DNS global (picks a region), and Front Door is L7 global (picks a region and does edge work in the path). The two on this page are the global tier; the other two work inside a region. This is exactly the stack drilled in Class 13 — Load Balancing & Traffic.

Front Door: a layer-7 front line at the edge

Microsoft calls Azure Front Door "an advanced content delivery network (CDN) for the cloud" that gives "fast, reliable, and secure access to your applications' static and dynamic web content globally." It is a layer-7 service, which means it understands HTTP and terminates each connection at one of Microsoft's edge locations close to the user. Because it sits in the traffic path, it can do things to the request: cache static content at the edge, offload TLS, accelerate dynamic requests over Microsoft's private backbone, route by URL path, and — the big one — sit a Web Application Firewall in front of your app to inspect and block malicious traffic. Front Door is not just a router; it is a working front line.

Figure — Front Door sits in the request path at Microsoft's edge and does real work to every request — caching, TLS, a WAF, fast failover. Traffic Manager only answers a DNS query with an address; the client then connects straight to the backend and Traffic Manager is gone. In-path edge work versus DNS-level routing.

Traffic Manager: a router that lives in DNS

Traffic Manager is a DNS-based traffic load balancer. When a client resolves your name, Traffic Manager answers the DNS query with the address of the endpoint it has chosen, whether by performance, priority, geography, or weighted split, and then it is done. The client connects directly to that endpoint; Traffic Manager is never in the data path. That has two consequences worth internalizing. First, it works for anything with a DNS name (VMs, non-Azure endpoints, whole regions), not just HTTP. Second, because it only ever hands out DNS answers, it cannot cache, cannot inspect requests, and cannot offer a WAF. It is a brilliant traffic director that never touches the cargo.

Front Door stands in the road and works on every car that passes. Traffic Manager just points at the right road and lets the cars drive themselves.

The consequences you feel in production

Failover speed. Front Door reacts fast because it is live in the path — a dead backend is skipped on the next request. Traffic Manager relies on DNS, and DNS answers get cached by resolvers for the record's TTL, so failover is only as quick as clients re-resolving the name. For sub-minute failover of a web app, that difference matters.
What it can protect. Only Front Door can cache content, terminate TLS at the edge, and put a WAF in front of your app. Traffic Manager, living in DNS, offers none of that.
What it can route. Traffic Manager routes any endpoint reachable by DNS, including non-HTTP and on-premises. Front Door is for HTTP/HTTPS web applications and APIs.

A quick way to pick. Ask two questions. Is it a web app or API (HTTP/HTTPS)? If no — you are routing raw TCP endpoints, non-Azure services, or whole regions by DNS — Traffic Manager. If yes, ask: do you want edge caching, TLS offload, or a WAF, and fast in-path failover? If yes, Front Door. If you genuinely only need "send web users to the nearest healthy region" with nothing at the edge, Traffic Manager can still do it more cheaply — but most modern global web apps want what Front Door adds. And they are not mutually exclusive: some large designs use Traffic Manager to steer between multiple Front Door profiles or across services Front Door does not cover.

Where Load Balancer and Application Gateway fit

To keep the whole family straight: Front Door and Traffic Manager are the global tier — they choose which region a user lands in. Inside a region, Azure Load Balancer (layer 4) and Application Gateway (layer 7) spread traffic across the VMs or pods in that region. A common full-stack shape is Front Door globally out front, then a regional load balancer or gateway behind it in each region. Global service picks the region; regional service picks the instance. If your decision is really between those two regional tools, see Load Balancer or Application Gateway.

The takeaway

Front Door and Traffic Manager both route users globally, but Front Door lives in the request path as a layer-7 edge service — caching, TLS offload, WAF, fast failover — while Traffic Manager lives outside it, answering DNS queries and letting clients connect directly, which makes it protocol-agnostic but unable to cache or protect. "Front Door for a global web app that wants a WAF and edge caching; Traffic Manager when I just need DNS-level routing across any endpoints, including non-HTTP ones" is the call you make once you stop weighing the names against each other and start asking where in the request path the work has to happen.

Questions people also ask

What is the difference between Azure Traffic Manager and Front Door?

Traffic Manager is a DNS-based global router: it answers a DNS query with the address of a chosen endpoint, works for any protocol, then leaves the request path, so failover waits for the record's DNS TTL to expire. Front Door is a layer-7 global entry point that stays in the request path at Microsoft's edge, adding caching, TLS offload, a WAF, and near-instant failover, but only for HTTP and HTTPS.

Is Azure Front Door better than Traffic Manager?

Neither is better in general; they solve different problems. Front Door is better when you need caching, TLS offload, a WAF, or sub-minute failover for a web app. Traffic Manager is better when you need cheap DNS-level routing across any endpoint, including non-HTTP ones, or across regions outside Azure.

Can you use Azure Front Door and Traffic Manager together?

Yes. Traffic Manager can sit above multiple Front Door profiles, routing DNS queries between them or providing a fallback path if Front Door itself has an outage. This layered design is uncommon, reserved for teams who need failover across Front Door instances, not the default choice for most apps.

Why does Traffic Manager fail over slower than Front Door?

Traffic Manager only answers DNS queries; it never touches the request itself. When an endpoint dies, clients keep using the last DNS answer until their resolver's cache expires at the record's TTL. Front Door sits in the request path and can route the very next request away from a dead backend, so its failover runs in seconds, not minutes.

Is Traffic Manager cheaper than Front Door?

Yes, generally. Traffic Manager only answers DNS queries and bills for that, with no edge compute, caching, or WAF involved. Front Door does real work at the edge, so it costs more. Pick Front Door for what it adds, not because it is the newer name, or you will pay for capability you never use.

Does Traffic Manager work with non-HTTP traffic?

Yes. Traffic Manager only ever hands out a DNS answer, so it routes anything reachable by a DNS name: VMs, databases, on-premises endpoints, and non-Azure services, not just web traffic. Front Door is restricted to HTTP and HTTPS, because it has to actually understand the request to do its edge work.

Azure RBAC: Owner vs Contributor vs Reader (and when to use each)

Victor — Mon, 24 Aug 2026 13:55:18 +0000

There are hundreds of built-in Azure roles, but three cover most of what you do — and the difference between two of them is the single most common access mistake in the cloud. Here is the model, and the trap.

Azure Owner vs Contributor: an Owner has full access including the right to grant access and assign roles to other people, while a Contributor can create, manage, and delete every resource except assigning roles or changing who has access. That single capability — role assignment — is the only difference between the two. Everything below is that idea, drawn out.

Azure role-based access control (RBAC) is how you answer "who can do what, where." It sounds like it should require a spreadsheet, but the everyday reality runs on three fundamental roles: Owner, Contributor, and Reader. Learn exactly what separates them and you can grant access confidently — and stop handing out Owner because you were not sure.

The short answer: Contributor can do everything Owner can — create, change, and delete every resource in scope — except one thing: assign roles to other people. That single capability is the only difference. Reader can view everything and change nothing.

The three roles, in Microsoft's own words

Role	What it grants	Can assign roles?
Owner	Full access to manage all resources	Yes — and can manage others' access
Contributor	Full access to manage all resources	No
Reader	View all resources; make no changes	No
User Access Administrator	Manage access only — assign roles, but not the resources themselves	Yes — access only

Microsoft's definitions are precise. Owner "grants full access to manage all resources, including the ability to assign roles in Azure RBAC." Contributor "grants full access to manage all resources, but does not allow you to assign roles." Reader lets you "view all resources, but does not allow you to make any changes." Two of those descriptions are almost identical — and that near-identical pair is where the trap lives.

The three built-in roles nest: Owner ⊃ Contributor ⊃ Reader. Reader can look; Contributor can also create and change resources but cannot hand out access; Owner can do everything Contributor can and also grant access to others. Give the innermost role that still lets the person do their job.

The one difference that matters

Owner and Contributor can both do essentially everything to the resources — create, change, delete VMs, databases, networks, all of it. The single distinction is access management. Owner can grant and revoke other people's access; Contributor cannot. Contributor can build the entire environment but cannot hand out a single role.

That gap is the whole point, and it is the security control people accidentally throw away. If a team needs to deploy and manage workloads, they need Contributor — not Owner. Giving them Owner "to be safe" hands them the power to grant themselves and anyone else more access, quietly, forever. The instinct that Owner is the helpful, generous choice is exactly backwards: Owner is the role you give almost no one.

Contributor builds everything and grants nothing. That gap is a feature, not a limitation.

The role for "manage access, nothing else": What if someone genuinely needs to manage access but should not touch the resources? That is a specific built-in role — User Access Administrator — which grants role assignment and nothing more. Splitting "who can change things" from "who can grant access" is how mature organizations avoid Owner sprawl. If your only tool is Owner, you cannot make that split.

Scope: where the role applies

A role is only half of a role assignment; the other half is scope — the level at which it applies. You assign a role at a management group, a subscription, a resource group, or a single resource, and it inherits downward: Reader at the subscription means Reader on every resource group and resource inside it. This is why you think about scope as carefully as role. "Contributor on this one resource group" is a tight, sensible grant; "Owner on the subscription" is handing someone the keys to everything beneath it.

The principle underneath: least privilege

All of this serves one idea — give each identity the least access it needs to do its job, at the smallest scope that works. Concretely:

Someone who only needs to look — auditors, dashboards, on-call read access — gets Reader.
Someone who builds and operates workloads gets Contributor, scoped to the resource groups they own.
Owner is reserved for the few who must also manage access — and even then, prefer scoping it as narrowly as the job allows.

Get comfortable saying "Contributor on that resource group, not Owner on the subscription" and you are speaking the language of every security review. The three roles are simple; the discipline is choosing the smallest one that still lets the work happen — and remembering that the gap between Contributor and Owner is a wall you put up on purpose.

Questions people also ask

What is the difference between Azure Owner and Contributor?

Both can create, change, and delete every resource in scope. The only difference is access management: Owner can assign roles to other people, Contributor cannot. If a person only needs to build and operate workloads, Contributor covers it — Owner adds nothing except the power to grant access.

Can a Contributor assign roles in Azure?

No. Contributor grants full access to manage resources but explicitly excludes role assignment. To hand out access to others, an identity needs Owner, User Access Administrator, or the newer Role Based Access Control Administrator role instead.

What can a Reader do in Azure?

View. A Reader assigned at a subscription can see every resource group and resource beneath it — configuration, metadata, monitoring data — but cannot create, change, or delete anything, and cannot assign roles. It is the right fit for auditors and on-call visibility.

Does Owner include Contributor permissions?

Yes. Owner is Contributor plus one thing: the ability to assign roles in Azure RBAC. There is no resource-management action Contributor can take that Owner cannot; the roles differ only in whether access management is included.

Do Azure RBAC roles inherit down through scope?

Yes. Assign a role at a management group, subscription, or resource group and it applies to everything beneath that scope. Reader at the subscription means Reader on every resource group and resource inside it, which is why picking the smallest correct scope matters as much as picking the smallest correct role.

DEV Community: Victor

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

Why it's worth doing at all

Before anything else

The seven chunks

1. Write the resume

2. Get it hosted

3. Put it on your own domain, with HTTPS

4. Build the counter API

5. Put the count in Cosmos DB

6. Make the page ask for the number

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

Two things I left off the list

Keeping the bill at zero

If you've done the Azure version

Azure ExpressRoute vs VPN Gateway: the honest comparison

VPN Gateway: an encrypted tunnel over the internet

ExpressRoute: a private, dedicated circuit

How to choose

Questions people also ask

Is ExpressRoute more secure than VPN Gateway?

Can you use ExpressRoute and VPN Gateway together?

How much does ExpressRoute cost compared to a VPN Gateway?

What is the difference between ExpressRoute and a site-to-site VPN?

Which is faster, ExpressRoute or VPN Gateway?

Further reading — the Microsoft docs

Azure Front Door vs Traffic Manager: which to use, and when

Front Door: a layer-7 front line at the edge

Traffic Manager: a router that lives in DNS

The consequences you feel in production

Where Load Balancer and Application Gateway fit

The takeaway

Questions people also ask

What is the difference between Azure Traffic Manager and Front Door?

Is Azure Front Door better than Traffic Manager?

Can you use Azure Front Door and Traffic Manager together?

Why does Traffic Manager fail over slower than Front Door?

Is Traffic Manager cheaper than Front Door?

Does Traffic Manager work with non-HTTP traffic?

Further reading — the Microsoft docs

Azure RBAC: Owner vs Contributor vs Reader (and when to use each)

The three roles, in Microsoft's own words

The one difference that matters

Scope: where the role applies

The principle underneath: least privilege

Questions people also ask

What is the difference between Azure Owner and Contributor?

Can a Contributor assign roles in Azure?

What can a Reader do in Azure?

Does Owner include Contributor permissions?

Do Azure RBAC roles inherit down through scope?

Further reading — the Microsoft docs