Azure governance works when several controls cooperate without being confused with one another. Management groups organize scope, Azure Policy evaluates resource state, and Azure role-based access control determines who can perform actions. Each solves a different problem. Architects preparing around AZ-305<\/a> need to design those controls as one operating system for the cloud estate instead of treating them as three independent portal features.<\/p>\n The most important design question is not \u201cWhich policy should we assign?\u201d It is \u201cWhere should this rule live, who should be able to change it, and how will exceptions be handled?\u201d A good hierarchy turns organizational intent into inheritance. A poor hierarchy creates hundreds of special cases, overbroad permissions, and policy assignments that teams learn to work around rather than trust.<\/p>\n Azure Resource Manager has a hierarchy: management groups can contain other management groups and subscriptions; subscriptions contain resource groups; resource groups contain resources. Governance controls can be applied at different levels of that hierarchy, and child scopes inherit many controls from their parents. The architecture of the hierarchy therefore determines how widely a decision travels.<\/p>\n Management groups are most useful when several subscriptions share the same governance requirements. A platform team might have a top-level structure for production, nonproduction, regulated workloads, or business divisions. The exact labels vary by organization, but the structure should represent durable differences in policy and ownership rather than a temporary project chart.<\/p>\n A common mistake is to mirror the company org chart too literally. Reorganizations then force governance redesigns. Prefer hierarchy boundaries that reflect stable control requirements: data residency, internet exposure, security baseline, workload criticality, or operating model. That gives the cloud estate a structure that can survive changes in reporting lines.<\/p>\n Scope design should also anticipate acquisition and divestiture. A business unit that may require separate billing or compliance later is easier to move if its subscriptions already form a clean branch. By contrast, mixing unrelated workloads in one subscription can make future separation difficult because RBAC, quotas, policy, and cost reporting are all intertwined. Governance architecture should keep today\u2019s simplicity without creating unnecessary coupling.<\/p>\n Azure Policy evaluates resources against business rules. It can audit, deny, modify, or deploy supporting configuration depending on the policy effect. Examples include restricting locations, requiring tags, limiting VM SKUs, or ensuring diagnostic settings are present. The important distinction is that Policy asks whether the resulting resource state is allowed or compliant.<\/p>\n That is different from Azure RBAC. A user may have permission to create a virtual machine, but a Policy assignment can still deny the deployment if the requested region or SKU violates the organization\u2019s rules. Conversely, a perfectly compliant resource cannot be changed by someone who lacks RBAC permission. The two control planes intersect without replacing each other.<\/p>\n Policy definitions and initiatives should be managed like code. Start new controls in audit mode where practical, observe impact, remediate existing resources, and then move to enforcement when the organization understands the effect. A sudden deny policy at a broad scope can break deployment pipelines even when the rule itself is reasonable.<\/p>\n An Azure role assignment joins three elements: a security principal, a role definition, and a scope. The principal can be a user, group, service principal, or managed identity. The role defines allowed actions, and the scope determines where those permissions apply. Azure supports role assignment at management group, subscription, resource group, and resource level.<\/p>\n The design principle is to use the smallest scope that satisfies the requirement. A deployment identity that needs to write to one storage account should not automatically receive Contributor at the subscription. Broad permissions simplify the first day of implementation and complicate every audit after that.<\/p>\n Groups are usually better assignment targets than individual users because group membership can be managed through an identity lifecycle. The concepts covered by SC-300<\/a> become relevant because Azure resource authorization depends on the quality of Microsoft Entra identity governance. Joiner, mover, and leaver processes are part of cloud governance even when the resources themselves live in Azure.<\/p>\n Remember that RBAC permissions are additive across assignments. A user who is Reader at one scope and Contributor through another inherited scope effectively receives the union of those permissions. Troubleshooting must therefore consider direct assignments, group membership, and inheritance. Removing one visible assignment may not remove access if another path still grants the same capability.<\/p>\n Similarly, deny assignments are a separate mechanism used by some Azure managed services and deployment patterns. They should not be confused with Azure Policy deny effects. The governance model is easier to operate when teams understand whether an action is blocked by authorization, a deny assignment, or resource-state policy.<\/p>\n A governance model is incomplete if it only constrains resources or only constrains identities. Consider a networking subscription. Azure Policy might require approved regions, block public IP creation outside designated resource groups, and ensure logging is enabled. RBAC might reserve network configuration for a central platform team while allowing application teams to read network state.<\/p>\n The result is stronger than either control alone. Policy prevents noncompliant state regardless of which authorized identity submits the change. RBAC prevents unauthorized identities from making changes even if the requested result would be compliant. Together they provide both action control and state control.<\/p>\n That separation is useful during incident review. If an unwanted resource exists, you can ask two different questions: \u201cWhich identity had permission to create it?\u201d and \u201cWhy did governance allow this state?\u201d The answers lead to different fixes. One may require RBAC reduction; the other may require a Policy rule or scope correction.<\/p>\n Policy remediation needs identity and operational planning. Effects such as deployIfNotExists or modify can require a managed identity with permission to change resources. Existing noncompliant resources may need remediation tasks rather than becoming compliant automatically. That means a policy baseline includes both rules and an operating process for correcting the estate.<\/p>\n An Azure Policy initiative groups policy definitions around a common objective. Instead of assigning dozens of independent rules, a platform team can create a baseline initiative for security, operations, or regulatory requirements and assign it at the appropriate scope. This makes the intent easier to understand and gives compliance reporting a coherent frame.<\/p>\n Parameterization is important. The same policy definition can allow different region lists or values when assigned to different scopes. Avoid cloning definitions for every business unit unless the rule itself is truly different. Excessive duplication makes it hard to know which version is authoritative.<\/p>\n Exceptions should also be deliberate. Policy supports exclusions and exemptions, but they should not become a hidden bypass system. Record the owner, reason, duration, and compensating control for every exception. A temporary exemption with no expiry process tends to become permanent architecture.<\/p>\n Azure provides many built-in roles, and using them reduces maintenance. Custom roles are appropriate when built-in roles grant too much or fail to include an essential action. The goal is not to create a custom role for every team. The goal is to create a small, understandable permission model that maps to real responsibilities.<\/p>\n Start by documenting tasks rather than permissions. For example, \u201crestart virtual machines and view monitoring data\u201d is clearer than a list of provider operations. Then map the tasks to built-in roles. Only if the mapping consistently overgrants should a custom role be considered. This keeps the authorization model readable to reviewers who were not involved in its creation.<\/p>\n The same principle appears in dynamic access control<\/a>: useful authorization follows context and responsibility, not convenience. Azure implements the details differently, but the architectural objective is the same\u2014grant enough access for the job while limiting unrelated privilege.<\/p>\n Custom roles should be version-controlled and reviewed for wildcard actions. Resource providers add capabilities over time, and an overly broad wildcard can grant more than the original author expected. Prefer explicit operations for sensitive roles, document the role owner, and periodically compare the definition with the tasks it is supposed to support.<\/p>\n Subscriptions are not only billing containers. They are strong management boundaries for quota, policy, RBAC, cost allocation, and lifecycle. Workloads with materially different security or governance needs often deserve separate subscriptions even when they belong to the same business application.<\/p>\n Use management groups to apply common controls above those subscriptions and keep workload-specific policy below. This creates a layered model: organization-wide requirements at higher scopes, platform requirements at intermediate scopes, and workload-specific rules nearer the application. The hierarchy should avoid both extremes\u2014one giant subscription with no isolation and hundreds of tiny subscriptions with no operating standard.<\/p>\nManagement groups create the inheritance structure<\/h3>\n
Azure Policy controls resource state, not user identity<\/h3>\n
RBAC answers who can do what at which scope<\/h3>\n
Policy and RBAC should be designed together<\/h3>\n
Use initiatives to express a governance baseline<\/h3>\n
Design custom roles only when built-in roles are too broad<\/h3>\n
Subscription design is part of governance architecture<\/h3>\n