Northwind: Effective Permissions Across a Management Group Hierarchy
Northwind has three management groups - Platform, Workloads and Sandbox - all beneath the Tenant Root Group. Sub-Prod sits under Platform; Sub-App sits under Workloads. Priya is assigned Contributor at the Platform management group and Reader at Sub-App. A custom role, VM Operator, is also assigned to Priya at Sub-App and grants Microsoft.Compute/* plus Microsoft.Network/virtualNetworks/read. An Azure Policy assigned at the Tenant Root Group denies creation of public IP addresses. Last week Priya tried to create a VM with a public IP in Sub-App and received an authorization failure. Today she tried to create a new virtual network in Sub-App and was blocked again. She is the only engineer deploying VMs for the app team, and security will not relax the public IP policy.
1. Priya cannot create a virtual network in Sub-App. Identify the actual cause and the minimum change that unblocks her.
Read the worked answer
Effective permissions are the union of all assignments that apply at the resource's scope or above, then reduced by deny assignments and policy denies.
Build the list for Sub-App:
Contributoron the Platform management group - applies to Platform and its children (Sub-Prod). Management group scope does not reach a sibling branch, so this grants nothing in Sub-App.Readerat Sub-App - read-only.VM Operatorat Sub-App -Microsoft.Compute/*plusMicrosoft.Network/virtualNetworks/read.
No assignment supplies Microsoft.Network/virtualNetworks/write, so the create call fails with an authorization error. The wildcard on Compute does not spill into the Network namespace.
Minimum fix: assign Network Contributor at the Sub-App scope (or a custom role containing only Microsoft.Network/virtualNetworks/* and the subnet child actions) at that same scope. Do not widen VM Operator to Microsoft.Network/* - that would also grant publicIPAddresses/write and force a second fight with the policy.
Rule out the policy: the Root Group policy denies public IP creation, not VNet creation. A policy denial surfaces with a different message (denied by policy, with the assignment ID); Priya saw an RBAC authorization failure.
2. Explain why the VM creation failed even though VM Operator allows Microsoft.Compute/*. What is the correct remediation that keeps the security policy intact?
Read the worked answer
A VM deployment is a multi-resource deployment. The template/portal flow for a VM with a public IP also writes Microsoft.Network/networkInterfaces and Microsoft.Network/publicIPAddresses. VM Operator grants only virtualNetworks/read in the Network namespace, so the request fails at the NIC/public IP step.
Even if the role had included those actions, the outcome would not change:
- RBAC grants would allow it.
- The Azure Policy Deny at the Tenant Root Group removes the permission. Deny always wins over RBAC, and a deny assignment (from a managed application or blueprint) would also override.
Correct remediation: remove the public IP from the deployment pattern rather than loosening permissions. The app tier can still reach the internet through:
- a Standard Load Balancer with outbound rules, or
- a NAT Gateway on the subnet.
Both give deterministic outbound connectivity with no instance-level public IP, so the policy stays in force and the least-privilege model holds. Confirm the diagnosis in Activity Log: an RBAC failure names the missing action; a policy failure names the assignment and shows Deny.
3. Priya reports that she can view and modify resources in Sub-Prod as well as Sub-App. Is this expected, and what governance change would you recommend?
Read the worked answer
Expected - and a finding. Contributor on the Platform management group inherits to every child scope, including Sub-Prod (production). Priya therefore holds standing write access to production, while her Sub-App role is the only one that was intended.
Recommended change:
- Remove the standing Contributor assignment at Platform.
- Make the access eligible through Privileged Identity Management, scoped as tightly as possible (Sub-Prod resource group rather than the management group), with approval, MFA, justification and a bounded activation window.
- Add an access review on the management group and a recurring review of role assignments with a direct scope (not inherited).
- Audit for drift: list role assignments where
Properties.Scopeequals the management group, so future grants are deliberate rather than inherited.
Why not just keep it: inherited broad scope is invisible in day-to-day review - the assignment is recorded once at the management group but silently grants write on every future subscription added beneath it.