LEARN. PRACTICE. GROW.1. Organize around control needs
A hierarchy should make policy and access application predictable. In a fictional program, production and experimentation have different restrictions but applications share teams. Do not automatically copy the organization chart into management groups: first identify subscription sets needing the same controls. A policy or role assignment at a group flows to descendants. A root assignment needs impact analysis because it reaches a broad scope. Each subscription has one parent, so cross-cutting classification can need tags or another view without duplicating the subscription in the tree. Document each boundary’s rationale: responsibility, lifecycle, access and constraints. The hierarchy should not change merely because someone reports to another director. Assess what an inherited control achieves before choosing its placement.
2. Treat reparenting as a control change
Moving a subscription between management groups can change inherited policies and access. Before execution, compare effective controls at source and destination, including who retains administrative capability. In the fictional case, a team is Owner only through inheritance from the previous group. The change plan must check required permissions and administrative continuity instead of assuming old inheritance follows the subscription. A custom role can also depend on an assignable scope no longer present in the hierarchy path. Analyze that relationship before the change window. Afterwards, check effective results and account for delayed view updates. A diagram showing the new parent does not prove every consumer already observes the new state. Keep a clear record of expected grants and controls for the post-change checks. Rollback must also inventory effects already applied to resources: restoring the previous parent does not establish that those configuration changes automatically reverse.
3. Calculate access from every grant
A role definition describes permissions; an assignment links principal, role and scope. Making a custom role available in an assignable scope does not automatically assign it to users. Do not treat NotActions as a global denial either. If one assignment subtracts an action from its own set, another can still grant it. In the local exercise, the first role permits reading but excludes deletion; a second permits deletion. The union still includes deletion. The model uses fictional action names and an explicit denial list rather than simulating the Azure evaluator. In practice, inventory direct, inherited and group assignments, applicable conditions and the control or data plane. A check must use the intended identity, correct resource and relevant operation. Reviewing one role in isolation can miss the access actually available.
4. Attribute costs without confusing tags and budgets
Tags help identify service, owner and cost center, but they are neither a general security boundary nor automatically inherited by resources. If the design requires propagation from a resource group, define the mechanism and treatment of existing resources. Avoid secrets and personal information in values. A budget, meanwhile, tracks cost and triggers notifications; it does not itself order every resource to stop at an exact currency amount. In the fictional project, the sponsor wants early warning and a human decision before suspending environments. Define recipients, acceptable data delay and authorized actions. Shutdown automation must account for dependencies, continuity and recovery instead of being treated as an invisible consequence of the budget amount. Cost accountability needs both attribution and a response that the service owner can execute.
5. Make privilege available for the period of need
PIM distinguishes eligibility from activation. An eligible engineer can still need activation requirements such as justification, authentication or approval. Eligibility duration and individual activation duration are separate decisions. In the fictional example, a supplier joins a three-month project but needs resource administration only during approved changes. Select the narrowest suitable scope and rehearse the path with the supplier’s identity. Recording approval in a ticket does not establish that Azure already authorizes the operation. Also prepare approvers available outside working hours and handling for denied or expired requests. The aim is to enable the needed task with limited exposure and evidence without turning the approval team into a single blocking dependency. Track both entitlement to request access and the privilege actually active during the operation. Also distinguish Entra-role administration from Azure resource-role administration. Being Privileged Role Administrator in the directory does not by default grant administration of a subscription’s Azure assignments.
6. Close reviews with confirmed effects
An access-review decision and its application to the resource are separate stages. Confirm whether results apply automatically or require a pending manual action. Source type also limits what can change: groups synchronized from on-premises need source-side handling, dynamic membership follows rules and nested-group paths can retain access. In the fictional case, a consultant was denied in a review but can still enter through another assignment. The report should distinguish decision made, application completed and identified residual access. Assign correction ownership, a deadline and outcome evidence. Do not declare complete revocation from one denied row when remaining paths have not been assessed. This distinction makes the review operationally meaningful instead of a completed form disconnected from the resource’s actual permissions.
7. Bundle project access with a lifecycle
Entitlement management organizes resources in an access package with request, approval and duration policies. In a fictional international project, an external team needs a group, an application and a collaboration space. The package makes the approved bundle explicit, but should not include broad access merely because it might be convenient on another project. Define who can request it, who approves, when it ends and how need is reviewed. When an assignment expires, also inspect grants outside the package: direct authorization can remain. Package removal is not universal proof that the external identity was deleted. Handover should show resources, owners and alternate paths so supplier offboarding does not depend on individual memory or an email list. The package is one governed access route within the wider identity lifecycle. Catalog delegation has boundaries: a nonadministrator creator does not acquire ownership of other teams’ resources merely by creating the catalog.
8. Prepare emergency access without normalizing its use
Emergency access must remain usable when normal administration dependencies fail. Current recommendations include cloud-only accounts, phishing-resistant authentication, protected credentials, monitoring and regular rehearsals. Do not turn a Conditional Access exclusion into a recommendation to remove strong authentication: the account still needs appropriate protection. In the fictional scenario, every administrator depends on approval and the same unavailable service. A prepared path avoids improvised excessive grants during the incident. After each use, review authorization, actions and corrective needs. The final lesson artifact is a matrix distinguishing permanent, eligible, active, project and emergency access, with owners and ways to prove withdrawal when the need ends. Keep emergency procedures visible to authorized operators while ensuring their exceptional purpose and every actual use remain accountable.
def granted(assignments, denied=):
# Explicit fictional action sets only; not Azure RBAC evaluation.
allowed = set
for actions, excluded in assignments:
allowed |= set(actions) - set(excluded)
return allowed - set(denied)
limited = ({"read", "delete"}, {"delete"})
extra = ({"delete"}, set)
assert granted([limited]) == {"read"}
assert granted([limited, extra]) == {"read", "delete"}
assert granted([limited, extra], {"delete"}) == {"read"}
assert granted([]) == set
assert granted([extra, limited]) == granted([limited, extra])
assert granted([limited, limited]) == {"read"}
print("six fictional grant-set checks passed; no Azure authorization evaluated")
Fictional case: a subscription moves groups to standardize policies, but RUN loses an inherited assignment. Acceptance follows validation of new least-privilege access, applied controls and support ownership.
Common pitfalls
Treating NotActions as global deny; confusing eligibility with activation; counting a completed review as effective revocation; treating tags or budgets as control boundaries they do not provide.
Related topics: Azure Policy and RBAC · Supplier onboarding and offboarding · FinOps and accountability
Governance is verifiable when each grant, inheritance and exception has scope, duration, ownership and evidence of its actual effect.
Reference: What are Azure management groups? · AZ-305 objectives 2026-04-17