The line of descent
A postal address is a hierarchy pretending to be a line of text. Country, region, city, street, house number — each level is administered by someone different, and a decision made high up (a country closes a border) reaches every level below it, while a decision made low down (you repaint your door) reaches nothing above. Azure is organised exactly this way, and almost everything about permissions, billing and blame follows from where a thing sits in the descent.
There are five levels, from broadest to narrowest, and you should be able to recite them in your sleep. At the top is the tenant — your organisation's identity boundary, which is Microsoft Entra ID. Beneath it, management groups gather subscriptions so a policy can be set once for many. Then the subscription, the unit of billing and the wall a mistake struggles to cross. Inside it, resource groups, each holding resources that live and die together. And finally the resources themselves — the virtual machine, the database, the storage account.
- Scope
- The level in the hierarchy at which a permission, a policy or a cost applies. Set something at a scope and it flows downward to everything beneath — which is the whole reason the hierarchy exists, and the whole reason a mistake at the wrong scope is expensive.
Entra ID is not your old domain controller
The tenant is Microsoft Entra ID, and it carries a history you must get straight, because interviewers probe it and juniors trip on it. Entra ID was called Azure Active Directory until 2023.1 The name changed; the more important fact is that it was never the same thing as the Active Directory running in a company's server room, despite sharing two-thirds of a name.
- Entra ID
- Microsoft's cloud identity service — the directory of users, groups and applications you sign in to, speaking modern web protocols. It is what a tenant is.
The distinction is real and worth stating cleanly. On-premises Active Directory Domain Services is about machines on a corporate network: domain-joined computers, Kerberos tickets, group policy pushing settings to desktops, LDAP queries. Entra ID is about identity on the open internet: it authenticates people and applications to cloud services using protocols like OpenID Connect and SAML, and it does not domain-join machines the classic way — no Kerberos tickets, no group policy pushed to desktops. (Windows devices can be Entra-joined, but that is a different mechanism, managed through tools like Intune rather than group policy.) The two can be connected so staff use one set of credentials, but they are different systems solving different problems, and calling Entra ID "AD in the cloud" is the sentence that tells an interviewer you learned the poster, not the product.
Why it matters beyond trivia: identity is the top of Class One's stack, the layer that never leaves you. Entra ID is where that responsibility physically lives on Azure — every user, every group, every application that will ever hold a permission is an object here. Get comfortable; you will spend the rest of the bootcamp handing things identities and deciding what those identities may touch.
Subscriptions: where the bill and the blast stop
A subscription is doing three jobs at once, and naming all three is what separates a considered design from a pile of resources. It is a billing boundary — one invoice, one place to see and control spend. It is a limit boundary — quotas on how many of a given resource you can create apply here. And it is a blast-radius boundary — the wall that contains a permission granted too widely or a policy set too broadly.
The last of these is why serious organisations do not run everything in one subscription. Separate subscriptions for production and non-production mean a developer experimenting in the non-prod subscription cannot, by any slip of the hand, reach production — the wall is structural, not a matter of everyone being careful. It also means the two invoices are separate, so the cost of experimentation is visible rather than smeared across the thing that earns money. Management groups then sit above, letting you apply one policy — "only these regions," "these tags are mandatory" — across every subscription at once, so governance is set in one place and inherited down the descent.
This is the first genuinely architectural decision in the bootcamp. How you divide subscriptions decides what can break what, who sees which bill, and where governance attaches. It is not an administrative afterthought; it is the floor plan, drawn before a single wall goes up.
Resource groups: lifecycle, not alphabet
A resource group is a container, and the instinct of every newcomer is to fill it like a filing cabinet — all the virtual machines here, all the databases there, sorted tidily by type or by first letter. That instinct is wrong, and the correct principle is one sentence long.
A resource group is a lifecycle, not a folder.
Group together the things that are created together, deployed together, and — the acid test — deleted together. An application's web tier, its database, its storage and its networking belong in one resource group because when that application is retired, you want to delete the group and have the whole application vanish cleanly, leaving no orphaned disk billing quietly at three in the morning.2 Sort by resource type instead and decommissioning becomes an archaeological dig: which of these forty virtual machines belonged to the app we just killed?
Two facts pin the principle down. Deleting a resource group deletes everything inside it — that is the feature, not a hazard, once your groups follow lifecycle. And a resource lives in exactly one resource group, though it can be moved; the group is a home, not a tag you sprinkle. Design groups around the question "what dies together," and both cost hygiene and disaster recovery get easier for free.
Names and tags are a letter to the future
Everything you create will be read, years from now, by someone who was not in the room — quite possibly you, having forgotten. Naming conventions and tags are the letter you leave that person. Written well, they answer "what is this, whose is it, and can I delete it" without a meeting. Written badly, or not at all, they are the reason a company pays for a mystery virtual machine for three years because nobody dares turn it off.
A workable naming convention is boring and consistent: workload-environment-type, so store-prod-vm reads itself. Tags are the metadata layer on top — key-value pairs like owner, env and cost-center — and they are what turns a chaotic invoice into a report finance can act on. But two facts trip people, and both are exam material and real-world scars.
- Tags do not inherit
- A tag on a subscription or resource group does not flow down to the resources inside it. You apply tags per resource, or you use Azure Policy to require and add them automatically. Assuming inheritance is how half your resources end up untagged.
- The limits are finite
- Up to 50 tags per resource, resource group or subscription, and management groups cannot be tagged at all. A few services cap lower. Plenty of room for a sane schema; not room for tagging as a dumping ground.3
Tagging feels like paperwork until the first time an invoice triples and Cost Analysis can group the damage by owner and cost-center in one click — the autopsy Class One promised you would run in Class Thirty-Two. The tags you apply today are the difference between that click and a fortnight of guessing. Write the letter now; the future reader is on your side only if you were.
Laying out Campux's tenant
You design the floor plan before building. One Entra ID tenant — Campux already has it, carrying the Microsoft 365 identities from Class Six. Beneath a small management group, two subscriptions: prod and non-prod, so experimentation can never reach the storefront and the two bills stay honest about what costs what. Resource groups follow lifecycle, one per workload per environment — store-prod, store-nonprod — so retiring anything is one clean deletion.
The governance is set once, high up: mandatory tags of owner, env and cost-center, and an allowed-regions rule — both enforced by policy at the management group in Class Eight, because you already know tags will not apply themselves. Six people, a floor plan a stranger could read, and a blast radius drawn on purpose. Nothing here is clever. All of it is deliberate, which is better.
The official module, and a CAMPUX overview
Control and organize Azure resources with Azure Resource Manager
learn.microsoft.com/training/modules/control-and-organize-with-azure-resource-manager/
Governance depth: Describe features and tools in Azure for governance and compliance
learn.microsoft.com/training/modules/describe-features-tools-azure-for-governance-compliance/
A short walkthrough of the tenant-to-resource hierarchy and tagging will live here. Video to be added.
Build a slice of the hierarchy the CLI way
The hierarchy is easiest to feel when you make a piece of it yourself. You will create a resource group with the three tags from this class, create a management group to see the governance scope above subscriptions, and prove — in one command — that tags do not inherit.
Open Cloud Shell — the >_ icon in the top bar — and choose Bash. (Locally: install the Azure CLI and run az login.)On screen: Cloud Shell is already signed in as you, scoped to your subscription, with az ready — nothing to install.
Create a resource group and tag it in the same command:
az group create --name rg-campux-lab --location westeurope \ --tags owner=you env=lab cost-center=training
What just happened: a lifecycle container now exists inside your subscription, carrying the three tags this class insists on — set at creation, not bolted on later.Create a management group — the governance scope that sits above subscriptions:
az account management-group create \ --name campux-lab-mg --display-name "Campux Lab"
On screen: note there is no --tags option here — management groups cannot be tagged. That is the one exception from the class, met at the command line.Read the tags back, and confirm they belong to the group, not to anything inside it:
az group show --name rg-campux-lab --query tags
The lesson: the tags are on the resource group. Anything you create inside it starts untagged — tags do not inherit, which is exactly why Class Eight will enforce them with policy.Tear down so nothing lingers:
az group delete --name rg-campux-lab --yes --no-wait az account management-group delete --name campux-lab-mg
Create and tag a resource group by hand
Now do it by clicking, because the Create blade's own tabs name the pieces. Use a throwaway group you delete at the end.
Go to portal.azure.com and sign in.On screen: the search bar runs across the very top of every page. Almost everything in Azure starts there.
In the search bar at the top, type Resource groups, select it, then click + Create.On screen: the Resource groups page lists any that exist and offers Create — launching a short guided flow with Basics, Tags, and Review + create tabs.
Basics tab: choose your subscription, name the group rg-campux-lab, and pick a region.On screen: the region here is only where the group's metadata lives — resources inside it can sit in other regions. It is a label on a folder, not a wall.
Tags tab: add three tags — owner, env, cost-center — with values of your choosing.On screen: this is the tag step the class kept insisting on. These tags land on the group; a resource created inside will not inherit them — you would tag it, or a policy would.
Review + create, then Create. Open the new group when it is ready.
Optional — see the scope above: in the top search bar type Management groups and open it.On screen: a tree that sits above your subscriptions, and — tellingly — no Tags tab anywhere on it. The hierarchy and the no-tag rule, both visible at once.
Tear down: open rg-campux-lab and choose Delete resource group so it and anything in it go together.
Portal wording drifts over time; if a label here does not match your screen, the concept is the anchor — subscription, resource group, region, and the Tags tab.
Read the descent on its own blades
Open each level of Figure 4 in the portal and let the blade explain what kind of boundary it is.
Open Management groups and expand the tree from the root.On screen: the governance scope above subscriptions. A policy or role set here would cascade to every subscription beneath — inheritance, made visible.
Open your subscription and read three blades: Overview, Access control (IAM), and Cost analysis.On screen: one place shows the billing, one shows who can act, one shows the spend. That is the subscription being a billing boundary and an access/blast-radius boundary at once.
Open a resource group and read Overview, then Tags, then Deployments.On screen: the group is a lifecycle folder — its Tags blade holds what you set, and Deployments records every change made to it, the archaeology the class promised.
Go back to the management group and look for a Tags blade.The point: there isn't one. Seeing the absence is the fastest way to remember that management groups cannot be tagged.
Somewhere that will not become a landfill
A new team spins up and needs somewhere to build that will not turn into a landfill. You give them a subscription under the right management group, so policy and access flow down automatically, and you organize resources by lifecycle from day one. Six months later, when someone asks "what does this team spend and own?", the answer is one clean view instead of an archaeology dig.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B. Management groups sit above subscriptions — that is their entire purpose, to govern many subscriptions at once — then resource groups, then resources. A and D put the subscription on top, which is the most common muddle, and it matters because it inverts where policy attaches: set a rule at a management group and it covers every subscription beneath; set it at a subscription and the sibling subscriptions never hear about it. Get the order wrong and you govern the wrong blast radius.
C. Entra ID — Azure AD until 2023 — is cloud identity, speaking OpenID Connect and SAML, not a rehosted domain controller. A and B describe Active Directory Domain Services, the on-premises system of Kerberos and group policy; the two connect but are not the same, and conflating them is the classic tell. D describes a subscription grouped under a management group, a different level of the hierarchy entirely. Identity is the top of the stack, and this is the service that holds it.
One group per resource, deletion cascades, and tags do not inherit on their own. The two false statements are the expensive beliefs: assuming subscription tags flow down leaves half your estate untagged and invisible on the cost report, and management groups in fact cannot be tagged at all. If you believed inheritance was automatic, you have just found the reason a future invoice will be unreadable — and why Campux enforces tags with policy rather than hope.
NAMING & TAGGING STANDARD — Campux
1. Resource names: workload-environment-type, e.g. store-prod-vm.
2. One resource group per workload per environment.
3. Required tags: owner, env, cost-center.
4. Apply the three tags once at the subscription; every resource
inside will inherit them automatically.
Line four. Tags do not inherit. A tag set on the subscription stays on the subscription; the resources inside receive nothing unless each is tagged directly or Azure Policy is configured to apply and enforce the tags on creation. Lines one to three are sound — lifecycle groups, a readable name, three sensible tags.
Consider the consequence. Trusting line four, the team tags the subscription, ticks the box, and moves on — while every virtual machine, disk and database is created bare. Months later the invoice triples and Cost Analysis cannot group it by owner or cost-center, because those tags were never actually on the things that cost money. The fix is one line: enforce the tags with policy. Catching this before it ships is the difference between a governance standard and a comforting fiction.
The request is for the widest blast radius in the building, for the narrowest of reasons. Owner on the production subscription is total control over everything that earns money — every resource, and the power to hand that control to others. "It's just easier" is true and is exactly why it is dangerous: convenience at the top of the descent is how one fat-fingered command or one phished account takes down production.
Solve the real problem, which is friction, not scope. Find out which walls they are actually hitting and grant the least that clears them — most often Contributor on the specific resource group they are working in, where they can build freely and reach nothing else. The developer wanted to move fast; scoped-but-sufficient access lets them, without betting the storefront on it.
If they genuinely need higher privileges occasionally, make it temporary. Just-in-time access — Privileged Identity Management — grants a role for a few hours against an approval and a reason, then revokes it. Standing Owner is a permanent risk to solve a momentary need. Name the scope, grant the minimum, time-box the rest — and you have said yes to the work while saying no to the blast radius.
First, do no harm — because deletion cascades. With everything in one group, you cannot delete "rg1" to retire the app without taking everything else with it. So the first move is reconstruction, not deletion: inventory what is there, work out from configuration and dependencies which resources belong to the retiring app, and tag as you go so the knowledge stops living only in your head.
Separate by lifecycle before you remove anything. Move the retiring app's resources into their own resource group so it becomes a clean unit that can be deleted on its own. This is the class's principle applied in reverse — you are retrofitting the lifecycle grouping the contractor never drew, and only once the app stands alone is it safe to decommission it.
Then fill in the hole. Establish the standard from §4 and §5 — lifecycle-based groups, a naming convention, mandatory tags — and enforce it with Azure Policy so the next person physically cannot create an untagged resource or repeat "rg1". The dig is the symptom; the absent standard was the disease, and leaving without treating it just hands the next engineer your afternoon.
Five things worth carrying out of this class
- The hierarchy, broad to narrow: tenant, management group, subscription, resource group, resource. Scope set high flows down.
- Entra ID is cloud identity (formerly Azure AD), not on-premises Active Directory rehosted. They connect; they are not the same system.
- A subscription is a billing boundary, a limit boundary, and a blast-radius boundary. Split prod from non-prod for the third reason.
- A resource group is a lifecycle, not a folder. Group what is created, deployed and deleted together.
- Names and tags are a letter to whoever inherits this. Tags do not inherit on their own — enforce them with policy.
- The rename from Azure Active Directory to Microsoft Entra ID landed in 2023, and older documentation, blog posts and even some portal corners still say "Azure AD". Treat the two names as the same product; the capability did not change with the label. As ever, learn the thing and expect the name to drift. ↩
- The orphaned resources — a disk outliving its virtual machine, a public IP nobody released — are the same "pay-for-what-you-forget" leak from Class One, and lifecycle-based resource groups are the structural defence against them. Delete the group, delete the whole application, leave nothing billing in the dark. ↩
- The current limits — 50 tags per resource, resource group or subscription, and no tags on management groups — are generous for any sane schema but are not infinite, and a handful of services cap lower. Check the current service limits before you design a scheme that leans on the ceiling; the ceiling occasionally moves. ↩