Authorizing Access to Resources
RBAC, custom roles, Conditional Access, and on-premises access design — control exactly who can do what, where, and when across your Azure environment.
Why authorization design matters
Authentication proves WHO you are. Authorization decides WHAT you can do.
In Azure, authorization has two dimensions: Azure RBAC (who can manage Azure resources — VMs, storage, networks) and data plane access (who can read/write the actual data inside those resources).
The architect’s job is designing an authorization model that follows least privilege, scales across subscriptions, and doesn’t create bottlenecks.
Azure RBAC: the authorization engine
Scope hierarchy
RBAC assignments inherit downward through the scope hierarchy:
Management Group
└── Subscription
└── Resource Group
└── Resource| Design Decision | Guidance |
|---|---|
| Assign at the highest useful scope | Reduces duplicate assignments. “Reader on subscription” beats “Reader on 50 resource groups.” |
| Use resource groups as permission boundaries | Group resources by team/app/lifecycle — RG-level RBAC is the sweet spot. |
| Avoid resource-level assignments | Hard to audit and maintain at scale. Exception: sensitive resources (Key Vault, databases). |
| Never assign Owner at subscription scope to users | Owner can change RBAC itself. Use Contributor + separate User Access Administrator if needed. |
Built-in roles vs custom roles
| Factor | Built-in Roles | Custom Roles |
|---|---|---|
| Availability | 500+ roles ready to use | You define the exact permissions |
| Maintenance | Microsoft updates them as services evolve | You must update when new API actions are added |
| Scope | Available at all scopes | Defined at management group or subscription scope |
| Audit | Well-documented, widely understood | Custom — requires documentation for your org |
| When to use | First choice — check built-in before creating custom | When built-in grants too much or too little |
🏛️ David’s approach: CloudPath Advisory designed a custom role for government agency “App Deployers” who need to:
- Deploy App Services and Function Apps ✅
- Configure app settings and connection strings ✅
- NOT modify networking or access the data plane ❌
- NOT manage RBAC assignments ❌
No built-in role matched this exactly — Contributor grants too much (networking and full resource management), Website Contributor doesn’t include Functions.
Exam tip: Custom roles — know the JSON structure
The exam may show a JSON role definition and ask what it permits or how to fix it. Key properties:
Actions: Control plane operations allowed (e.g.,Microsoft.Web/sites/*)NotActions: Exceptions to Actions (e.g.,Microsoft.Web/sites/config/list/actionto block reading connection strings)DataActions: Data plane operations (e.g.,Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read)AssignableScopes: Where the role can be assigned (subscription or management group IDs)
Data plane vs control plane authorization
A critical distinction that the exam tests heavily:
| Plane | What It Controls | Example |
|---|---|---|
| Control plane | Managing the resource itself | Creating a storage account, configuring firewall rules |
| Data plane | Accessing data inside the resource | Reading/writing blobs, querying a database |
Why this matters: A user with Contributor on a storage account can manage it (control plane) but CANNOT read the blobs inside it. They need Storage Blob Data Reader for that (data plane).
🏦 Elena’s design principle: “Separate control plane and data plane access. Database administrators manage the SQL server infrastructure (Contributor role on the Azure resource), but data access uses Entra ID-authenticated SQL users and roles — not connection strings. No human accounts should have production data access outside of Entra-authenticated, audited sessions.”
Designing on-premises access
Azure Application Proxy
For publishing on-premises web apps to external users without VPN:
| Feature | Description |
|---|---|
| No inbound ports | Connector makes outbound connection — no DMZ or firewall changes |
| Single sign-on | Entra ID pre-authentication + Kerberos Constrained Delegation to on-prem app |
| Conditional Access | Apply cloud policies (MFA, device compliance) to on-prem apps |
| Best for | Legacy web apps that can’t be modernised yet |
Hybrid access patterns
| Pattern | Use Case | Technology |
|---|---|---|
| App Proxy | Publish individual on-prem web apps | Entra Application Proxy connector |
| VPN (P2S) | Remote workers accessing on-prem network | Azure VPN Gateway, Point-to-Site |
| VPN (S2S) | Site-to-site connectivity (office to Azure) | Azure VPN Gateway, Site-to-Site |
| ExpressRoute | High-bandwidth, low-latency private connection | ExpressRoute circuit + peering |
| Entra DS | Legacy apps needing LDAP/Kerberos in the cloud | Entra Domain Services |
🏗️ Priya’s hybrid design: During GlobalTech’s migration, some apps are on-prem and some are in Azure:
- App Proxy for the legacy HR portal (web-based, needs Kerberos SSO)
- S2S VPN for the transition period (Azure VMs talking to on-prem databases)
- ExpressRoute planned for post-migration (production traffic needs guaranteed bandwidth)
Knowledge check
🏦 Elena's development team needs to deploy and configure Azure App Services in their resource group, but they must NOT be able to modify network configurations or read application secrets. Which approach should Elena recommend?
🏗️ GlobalTech has a legacy timesheet web application running on-premises. Remote workers need to access it from home without a VPN, and Priya wants to enforce MFA and device compliance. Which solution should she recommend?
Next up: Resources are authorised — now let’s protect the secrets that make it all work — Secrets, Keys & Certificates.