"Before you design anything, you need to know who controls it and how Azure is organised. Identity and governance are not afterthoughts — they are the foundation every enterprise architecture sits on."
The Business Analogy
The Azure Governance Hierarchy — Why It Matters for AZ-305
Azure resources exist in a hierarchy: Management Groups → Subscriptions → Resource Groups → Resources. Understanding this hierarchy is the foundation of governance design because everything cascades downward.
AZURE GOVERNANCE HIERARCHY
Management Group <- Apply broad policies here (affects EVERYTHING below)
|
Subscription <- Billing boundary + isolation boundary
|
Resource Group <- Deployment unit. Delete the RG = delete everything in it
|
Resources <- VMs, storage accounts, databases, etc.
Key rule: A policy or RBAC assignment at a higher scope
automatically applies to everything below it.
The AZ-305 design question is: at which scope do I apply this governance control, and what is the blast radius if I get it wrong?
A policy applied at the Management Group level cascades to all subscriptions, all resource groups, and all resources. That is powerful for broad enforcement — and risky if the policy is wrong. A policy applied at a single Resource Group affects only that deployment. Architects choose scope deliberately.
Entra ID — Not the Same as Active Directory
The most common misconception when moving from on-premises to Azure: Entra ID (formerly Azure Active Directory) is NOT a cloud version of Windows Server Active Directory. They are fundamentally different technologies.
The four identity types in Entra ID
RBAC — Role-Based Access Control
RBAC controls what an identity can do at a given scope. Three concepts to understand completely:
RBAC = Security Principal + Role Definition + Scope
Security Principal: WHO (user, group, service principal, managed identity)
Role Definition: WHAT (list of allowed actions -- read, write, delete, etc.)
Scope: WHERE (management group, subscription, resource group, resource)
Built-in roles:
Owner = all actions + assign roles to others
Contributor = all actions EXCEPT assigning roles
Reader = read-only across the scope
Key rules:
Roles are ADDITIVE -- having two roles = union of both
DENY assignments ALWAYS WIN -- override any role assignment
Use Groups -> RBAC, never individual user -> RBAC at enterprise scale
The architect scenario: A development team of 50 engineers needs Contributor access on their subscription but must never be able to assign roles (no Owner). The correct design: create one Entra Group, assign the Contributor role at the Subscription scope, add all engineers to the group. Adding and removing team members is now a group membership change — not 50 individual RBAC assignments.
Azure Policy — The Building Code
RBAC controls what people can do. Azure Policy controls what the environment allows regardless of who is doing it. These are complementary — not alternatives.
Architect Scenario — Test Your Judgment
Your company has 3 business units, each with a separate Azure subscription. You need to enforce that all VMs must use Trusted Launch — across all subscriptions automatically. What is the correct design?
Show Answer + Reasoning
Apply an Azure Policy Initiative at the Management Group level.
Why not per-subscription? With 3 subscriptions today, per-subscription assignment works. But what happens when there are 30 subscriptions? Or when a new subscription is added — does someone remember to apply the policy? Management Group scope is the answer because it applies automatically to every subscription now and in the future. One assignment, universal enforcement, zero drift.
Why an Initiative rather than a single Policy? Trusted Launch actually has multiple configuration requirements — you would bundle them into an Initiative for a single assignment point.
🎯 Quick Check — Module 1
Q1: What is the key difference between RBAC and Azure Policy?
Show Answer
RBAC controls what an identity can do — it is permission-based and identity-scoped. Azure Policy controls what the environment allows — it applies regardless of who is taking the action. A user with Owner role can still be blocked by a Deny policy. They work together: RBAC for authorisation, Policy for compliance.
Q2: Your App Service needs to read secrets from Key Vault. What identity type should it use?
Show Answer
Managed Identity. The App Service is running in Azure, authenticating to another Azure service. Managed Identity is assigned automatically — no client ID, no secret, no rotation needed. In App Service: Settings → Identity → System assigned → On. Then in Key Vault: Access policies → add the App Service's identity with Get and List secret permissions.
Q3: You apply a Contributor RBAC role at the Subscription scope and a Deny assignment for storage account creation at the Resource Group scope. Can the user create a storage account in that resource group?
Show Answer
No. Deny assignments always override role assignments, regardless of scope. Even though the user has Contributor at a higher scope, the Deny assignment at the Resource Group scope blocks storage account creation within that group. This is the "Deny wins" rule of Azure RBAC.
Key Takeaways — Module 1
- Management Groups cascade — apply governance controls at the highest appropriate scope, not individually per subscription
- Entra ID is not cloud AD — it is HTTP-based (OAuth2/OIDC), not Kerberos/LDAP
- Managed Identity is the zero-credential pattern for Azure-to-Azure authentication — always prefer it over Service Principals for workloads running in Azure
- RBAC controls who can do what; Azure Policy controls what the environment permits — both are needed, neither replaces the other
- Deny assignments always win over role assignments regardless of scope
- Assign RBAC to Groups not individuals — scales to any team size