Azure administration becomes easier when resource groups, management groups, subscriptions, and locks are treated as management boundaries instead of as folders. A resource group organizes resources that share a management lifecycle. Subscriptions provide billing, quota, and governance boundaries. Management groups sit above subscriptions for enterprise policy and access. Resource locks can then protect a subscription, resource group, or resource from accidental change or deletion.
The current AZ-104 scope expects administrators to work with these governance controls. The practical challenge is not memorizing the hierarchy. It is placing resources at scopes that make deployment, access, policy, cost, and deletion behavior predictable for the people who operate the environment.
Resource groups should reflect a shared management lifecycle
A resource group is a logical container for Azure resources. Microsoft’s guidance emphasizes grouping resources that share a lifecycle so they can be deployed, updated, and deleted together. That is more useful than organizing purely by technology. Putting every virtual network in one group, every VM in another, and every storage account in a third can scatter one application across administrative boundaries that no longer match how it is operated.
Application-oriented resource groups often work well because ownership and lifecycle are clearer. A workload’s compute, networking components, storage, and monitoring resources can be grouped where their deployment and retirement are coordinated. Shared platform services such as central DNS, firewalls, or monitoring workspaces may belong in separate platform-owned groups because their lifecycle is independent of any one application.
The resource group itself has a location, but that location stores resource-group metadata; resources inside the group can exist in different Azure regions. This is a frequent source of confusion. A group created in East US does not force every member resource into East US. Regional architecture should be determined by each service’s placement requirements, not by the resource group metadata location.
A useful test is deletion intent: if the application is retired, should every resource in this group normally be retired with it? If the answer is no for several important members, the group is probably mixing lifecycles. Shared Key Vaults, network hubs, monitoring workspaces, and DNS services are common examples that deserve separate ownership when many applications depend on them.
That deletion test is also useful during audits because it reveals resources that were placed together only for convenience, not because they share ownership or change cadence.
Azure scope is a hierarchy, not a flat collection
For core governance, the useful hierarchy is management group, subscription, resource group, and resource. Permissions and policies assigned higher in the hierarchy can affect lower scopes. That inheritance is what makes centralized governance possible, but it can also surprise workload teams that inspect only the resource group and miss a policy or role inherited from above.
Scope design should follow organizational responsibility. Enterprise security may apply policy at a management group. A platform team may manage network resources at subscription or resource-group scope. An application team may receive access only to its workload group. The same hierarchy can therefore express both central guardrails and delegated operations.
The architecture responsibilities associated with AZ-305 often depend on the same hierarchy. Designing a service in Azure is not only choosing compute and storage; it includes deciding which subscription, governance scope, and operational boundary will own those resources over time.
Subscription boundaries deserve equal attention because they carry quotas, billing relationships, policy inheritance, and access assignments. Creating a new subscription can be the right way to isolate an environment or business unit, but excessive subscription fragmentation shifts complexity into networking, governance, and reporting. Use a subscription when the boundary is operationally meaningful, not simply because a new project has begun.
Management groups provide governance above subscriptions
Management groups are containers for subscriptions. They let large organizations apply governance conditions at a scope higher than a single subscription, so access and policy can be inherited by many subscriptions at once. This is especially useful when the organization has separate subscriptions for production, development, regions, business units, or regulatory environments.
A management-group hierarchy should be intentionally shallow and based on durable governance differences. Mirroring every line of the corporate org chart can create constant restructuring when teams change. Better boundaries are often stable concerns such as production versus nonproduction, geographic regulation, business ownership, or platform policy.
Inheritance is the main advantage, so it should be used carefully. A policy or role assignment placed high in the tree can have a very large blast radius. Before changing a management-group-level control, understand which subscriptions sit beneath it and whether exceptions are required. Enterprise scope is powerful precisely because it reduces the need to configure each subscription independently.
Changes to the hierarchy should be controlled because moving a subscription between management groups can change inherited policy and access. Before a move, compare the source and target ancestry and identify controls that will appear or disappear. The resource payload does not move, but the governance context can change immediately, which is enough to break deployments or expose capabilities that were previously restricted.
Azure Policy and RBAC use scope for different purposes
Azure RBAC answers who can perform allowed actions. Azure Policy evaluates whether resources comply with configuration rules and can audit, deny, modify, or deploy related settings depending on the policy effect. Both can be assigned at scopes in the Azure hierarchy, but they solve different problems.
For example, an application team might have Contributor on a resource group through RBAC while an inherited policy prevents creation of public IP addresses. The user has permission to create resources, but the policy still enforces the organization’s configuration rule. Seeing only the role assignment would not explain the failed deployment.
Administrators should diagnose authorization and compliance separately. When a deployment fails, determine whether the message is an RBAC denial, a policy denial, a resource lock, a quota issue, or a service constraint. Broadening the user’s role does not fix a policy that intentionally blocks the resource and only increases privilege.
Policy exemptions should be visible and specific. If one application has a justified reason to violate a policy, scope the exemption narrowly and give it an owner and expiration or review date. Broad exemptions at subscription or management-group scope can quietly neutralize the guardrail for unrelated workloads. The exception process should preserve the intent of central governance rather than become an alternate deployment path.
Resource locks protect against accidental deletion and modification
Azure Resource Manager supports two common lock levels. A Delete, or CanNotDelete, lock allows authorized users to read and modify a resource but prevents deletion. A ReadOnly lock prevents both deletion and modification, making the resource behave much more like it is restricted to read operations. Locks can be applied at subscription, resource-group, or individual resource scope.
A lock overrides user permissions. Even an identity with broad RBAC rights cannot simply ignore a lock. That makes locks useful for protecting critical shared infrastructure, but it also means they can interrupt automation, maintenance, and service operations if applied without understanding what the resource provider needs to change.
Locks are not a security boundary against malicious administrators who are allowed to remove the lock. They are mainly a protection against accidental or unintended operations. Use them where an extra deliberate step is valuable, such as a critical production resource group or shared network service, and control who has permission to manage locks.
Lock management itself is a privileged operation. Users need appropriate permissions on the authorization lock resource provider to create or remove locks, so organizations can separate normal resource administration from lock control. That separation is useful for critical resources: an operator can perform routine work while a smaller set of administrators controls whether the final deletion safeguard can be removed.
Lock inheritance can protect more than the object you clicked
A lock applied to a resource group is inherited by resources in the group. A lock at subscription scope can affect resources throughout the subscription. This is convenient when a whole production boundary needs protection, but it can create unexpected behavior for child resources and for operations that touch related objects.
ReadOnly is particularly disruptive because many Azure services need to perform write operations even when an administrator thinks of the service as “running normally.” A lock that prevents configuration changes can block scaling, key rotation, diagnostic changes, or resource-provider operations. Test lock behavior against the actual service before applying it broadly.
Deletion also has dependency effects. Removing a resource group triggers deletion of resources inside it, which is one reason group-level locks can be valuable. But resources can reference objects outside their own group, and shared dependencies may have different lifecycles. A lifecycle-oriented grouping model makes those relationships easier to reason about.
Always test how a lock affects the management operations of the specific resource provider. A ReadOnly lock on a storage account, for example, can block operations that depend on retrieving or changing account configuration. The visible application may continue serving data while administrative tasks fail. This is why a lock should be introduced with a validation plan, not as a last-minute checkbox before an audit.
Naming and tagging help humans navigate the hierarchy
Resource groups are not a substitute for a complete inventory model. Names and tags should expose useful operational context such as application, environment, owner, cost center, recovery tier, or data classification. Tags can help with reporting and automation, while a consistent naming convention helps operators recognize scope quickly in the portal, scripts, and logs.
Do not use tags as if they automatically create security boundaries. A resource tagged “production” is not protected unless RBAC, Policy, network controls, and operational processes enforce the intended treatment. Tags are metadata that can drive those controls; they are not controls by themselves.
Regional tags should also be based on the resource rather than inferred from the resource group location. An explanation of Azure regions and availability zones reinforces why workload placement needs explicit metadata when a single resource group can contain resources from multiple regions.
Tag governance should define which tags are authoritative and who maintains them. Cost-center and owner tags lose value quickly if application teams can leave them blank or stale. Azure Policy can help append or require metadata, but the organization still needs a source of truth for values such as business owner. Automation should update tags when ownership changes instead of relying on annual manual cleanup.
Infrastructure as code should target the intended management boundary
ARM templates, Bicep, Terraform, and deployment pipelines all operate against scopes. A deployment can target a resource group, subscription, management group, or tenant when the resource type and tooling support it. Choosing the correct deployment scope keeps resource ownership aligned with the hierarchy rather than creating manual objects outside the automated model.
Resource-group deployments are common for application stacks because the resources share a lifecycle. Subscription-level deployments can create resource groups and certain subscription-scoped resources. Management-group deployments can establish higher-level governance. Understanding those scopes helps separate platform bootstrap from workload deployment.
The difference between automation and orchestration in infrastructure as code becomes practical here. Automation can create a resource; orchestration coordinates dependencies and scopes so the whole environment is created in a controlled order. Scope design should make that automation safer, not force scripts to bypass governance.
Deployment identity matters at each scope. A pipeline that deploys into one resource group should not automatically receive subscription-wide Contributor. Separate platform bootstrap from application deployment so that the higher-privilege identity creates subscriptions, groups, policies, or shared infrastructure, while lower-privilege workload pipelines operate inside their approved boundary. This reduces both accidental blast radius and the value of a compromised pipeline credential.
A durable scope model makes administration boring in the best way
The best Azure hierarchy is one that administrators do not have to reinterpret every time they deploy or troubleshoot. Resources with a shared lifecycle belong together. Shared services have clear ownership. Management groups express durable enterprise governance. RBAC and Policy are applied at the highest scope that is both necessary and safe. Locks protect genuinely critical objects without blocking normal operations.
Review the model when resources accumulate exceptions. If every deployment requires a policy exemption, the policy scope may be wrong. If teams need subscription Owner simply to operate one application, RBAC scope may be too broad. If resource groups contain unrelated systems that cannot be deleted together, lifecycle grouping may have drifted.
Azure administrators are responsible for making cloud resources manageable over years, not just deployable today. Understanding the role of the administrator across identity, governance, storage, compute, and networking helps explain why scope design matters. Clear boundaries reduce accidental changes, simplify access reviews, and make automation and recovery more predictable.
Document a small number of standard patterns and use exceptions sparingly. For example, a platform subscription can host shared connectivity, application subscriptions can contain workload resource groups, and inherited policy can establish common security requirements. When every team invents its own hierarchy, the Azure estate becomes difficult to automate. Consistency lets administrators predict behavior before they open the portal.
Run periodic hierarchy reviews with both platform and workload owners. Look for empty subscriptions, orphaned resource groups, inconsistent naming, duplicate policy exemptions, and locks that no longer protect a critical dependency. Governance decays gradually as projects move and teams change. A short recurring review prevents the management hierarchy from becoming an archaeological record of old organizational structures.