Design identity, governance, and monitoring solutions
Management Hierarchy, Compliance, and Identity Governance
CoreDesign resource hierarchy, policy, tagging, and identity-governance controls around organizational boundaries and delegated accountability.
Aligned to the current AZ-305 study guide, skills measured as of April 17, 2026, verified August 25, 2026.
Why this matters
Governance succeeds when hierarchy reflects durable responsibilities and automated controls produce evidence without blocking legitimate delivery paths.
Must Know
- Build the management-group, subscription, and resource-group hierarchy around durable policy, access, billing, quota, and lifecycle boundaries.
- Use Azure Policy to evaluate or enforce resource compliance, while Azure RBAC determines which principals may act.
- Treat tags as ownership, cost, or classification metadata and use enforcement when consistent tagging is required.
- Match entitlement management, access reviews, and Privileged Identity Management to access packaging, revalidation, and privileged activation needs.
Compare and Distinguish
- Management groups organize subscriptions for inherited policy and access; subscriptions remain billing, quota, and management boundaries; resource groups are lifecycle containers.
- Azure Policy evaluates resource state and can deny, audit, deploy, or modify supported properties; Azure RBAC controls who can perform actions.
- Entitlement management packages access for populations; access reviews periodically revalidate continued need; Privileged Identity Management governs privileged activation.
Scenario examples
- Scenario: Regulated workloads need a distinct policy and access boundary. Think: use a dedicated subscription under the appropriate management group.
- Scenario: Vendors need time-limited access to an application and group. Think: entitlement management with approval and expiration.
- Scenario: Production changes require eligible rather than permanent administration. Think: Privileged Identity Management with activation controls.
Exam traps
- Resource groups cannot contain resources from multiple subscriptions.
- A tag is metadata, not an access-control mechanism.
- An audit policy records noncompliance but does not prevent deployment.
Key takeaways
- Model durable boundaries before applying controls.
- Choose Policy for resource compliance and identity governance for access lifecycle.
- Design exception, remediation, evidence, and ownership paths.
How it works
- Azure Resource Manager forms a parent-child hierarchy, so policy and role assignments at a management group, subscription, or resource group flow to descendant scopes unless an applicable exclusion changes the policy assignment.
- Azure Policy compares resource properties and resource actions with a definition during evaluation; the selected effect can record, reject, alter, or deploy supporting configuration when its prerequisites are met.
- Entitlement workflows grant packaged access, access reviews ask designated decision makers to revalidate it, and Privileged Identity Management turns eligible privileged assignments into controlled activations.
Objects and administrative surfaces
- Policy and role assignments inherit down the Azure resource hierarchy.
- Tags support ownership, cost, and classification metadata but do not automatically inherit without an enforcing mechanism.
- Identity-governance scope is driven by catalogs, packages, privileged roles, groups, applications, and review populations.
When to use it
- Use a dedicated subscription under the appropriate management group when regulation, access, or quota needs a durable boundary.
- Use Policy initiatives with owned exemptions and remediation when resource configurations must converge on a standard.
- Use entitlement management, access reviews, and PIM for approved packages, recertification, and controlled privileged activation respectively.
Security and governance implications
- Place high-impact role and policy assignments at scopes that match durable accountability, and review inherited effects before hierarchy moves.
- Give policy remediation identities only the permissions needed for the deployment or modification effect and time-bound every exemption.
How to validate and revise the design
- When an assignment behaves unexpectedly, inspect hierarchy, exclusions, inherited assignments, definition parameters, effect, and evaluation state.
- When access persists, check nested groups, broader-scope roles, entitlement expiration, access-review decisions, and active PIM assignments.
More detail
- Moving a subscription or resource under a different parent can change inherited policy and access without changing the resource itself, so hierarchy moves require an effective-assignment review.
- A deny effect can block a new noncompliant request without repairing existing resources; remediation for modify or deploy effects is a separate operation with the required identity and permissions.
- Tag standards need explicit inheritance or modification policy because parent tags do not flow automatically, and exemptions should preserve a named owner, reason, and expiry rather than silently weakening an initiative.
Ready for the quiz?
- Which policy, access, billing, quota, or lifecycle boundary belongs at management group, subscription, or resource-group scope?
- Does the control need to audit, deny, modify, deploy supporting configuration, or remediate existing resources?
- Is the access-lifecycle requirement packaging, periodic recertification, or eligible privileged activation?
Related objectives
- D1.3.S1 — Recommend a structure for management groups, subscriptions, and resource groups, and a strategy for resource tagging
- D1.3.S2 — Recommend a solution for managing compliance
- D1.3.S3 — Recommend a solution for identity governance