How Azure Subscriptions, Policy, and Locks Work Together
Azure governance becomes confusing when every control is treated as another way to “lock things down.” Subscriptions, management groups, Azure Policy, role assignments, resource groups, tags, and management locks all influence how an environment is organized, but they solve different problems. Good administration depends on putting each control at the scope where its behavior is predictable.
This distinction matters directly to AZ-104 because Microsoft’s current blueprint includes identities and governance as a major part of the administrator role. The practical challenge is not just knowing that Azure Policy and locks exist. It is understanding what they can prevent, what they inherit, and what they cannot replace.
A useful mental model is to separate four questions. Where does a workload live? Who is allowed to act? What configurations are permitted? Which critical resources should resist deletion or modification even when an authorized person makes a mistake? Subscriptions, RBAC, Policy, and locks answer those questions in different ways.
The Azure resource hierarchy sets the scope of everything else
Azure Resource Manager organizes resources into a hierarchy. Management groups sit above subscriptions. Subscriptions contain resource groups. Resource groups contain most workload resources. Assignments made high in that hierarchy can affect many descendants, so scope is not merely an organizational preference; it determines blast radius.
Management groups are useful when an organization has multiple subscriptions that need common governance. A policy or role assignment at a management group can inherit to child subscriptions and resources. A subscription is a stronger boundary for billing, quotas, and administrative organization. A resource group is usually a lifecycle boundary for related resources that should be managed together.
This hierarchy explains why a rule that looks harmless in a single resource group can become dangerous at the root management group. The same definition can have radically different consequences depending on where it is assigned.
Architectural planning at the AZ-305 level often deals with these boundaries deliberately, but day-to-day administrators need the same scope awareness before they assign policy or permissions.
Subscriptions are containers, not security policies
A subscription groups Azure resources under a billing and management boundary and provides a scope for RBAC, Policy, quotas, and resource organization. It is tempting to say that a subscription “enforces” governance, but the subscription itself is primarily the boundary on which other controls operate.
Organizations often separate production from development, isolate business units, or create platform subscriptions for shared networking and identity services. Those choices can reduce blast radius and make cost ownership clearer. They also create more objects to govern consistently.
A subscription boundary does not automatically prevent someone with sufficient permission from deploying an unapproved resource type or deleting a critical resource. Azure Policy, RBAC, and locks still have jobs to do inside the boundary.
For small environments, too many subscriptions can become administrative overhead. For large environments, too few can create an enormous shared failure domain. The right design follows ownership, compliance, billing, platform architecture, and operational independence rather than a universal number.
RBAC answers who can do what at a scope
Azure role-based access control governs authorization. A role assignment connects a security principal, a role definition, and a scope. If a user receives a role at a management group, subscription, or resource group, the permissions can inherit downward unless another mechanism changes the effective result.
RBAC should therefore be the first tool for limiting administrative authority. If a team only needs to restart VMs, it should not receive subscription Owner merely because that is easy. If a deployment pipeline needs to create resources in one resource group, its permissions should not casually extend across the subscription.
Governance problems occur when Policy is used to compensate for over-broad access. Policy can deny certain configurations, but it is not a replacement for least privilege. A person with unnecessary authority can still perform many actions that happen to be outside the policy rule.
The operational perspective of an Azure Administrator is to make authorization and configuration governance reinforce each other rather than asking one control to do the other’s job.
Azure Policy controls resource compliance and request behavior
Azure Policy evaluates resources against definitions. Depending on the effect, a policy can audit a configuration, deny a request, modify certain properties or tags, append data, deploy related resources, or record compliance state. Initiatives group multiple policy definitions around a common objective.
The important word is definition. Policy should express a rule that the organization can explain: allowed regions, required diagnostic settings, permitted resource types, mandatory tags, secure network settings, or other measurable resource properties. A policy that no one can explain becomes a source of mysterious deployment failures.
Policy is also scope-sensitive. An assignment at a management group can flow to many subscriptions; an assignment at a resource group is narrow. Definitions themselves have locations that determine where they can be assigned. Exceptions and exemptions should therefore be deliberate, documented, and as narrow as practical.
A broader discussion of Azure governance becomes useful here because Policy works best as part of an operating model with ownership, cost controls, security baselines, and change management rather than as a pile of deny rules.
Audit first when you do not yet understand the impact
Deny can be satisfying because it stops noncompliant changes immediately. It can also break deployment pipelines and emergency work if the rule was written or scoped poorly. Microsoft’s guidance around Azure Policy emphasizes evaluating impact before broad enforcement, and the platform supports audit-style effects precisely so teams can observe what would be noncompliant.
A safe rollout normally begins with a defined requirement, a narrow test scope, compliance observation, and remediation planning. Only then should a preventative effect be expanded. This is especially important with older environments where existing resources may not match a new standard.
The objective is predictable governance, not maximum strictness. A control that is routinely bypassed because it blocks legitimate work is weaker than a narrower control that teams understand and trust.
Management locks protect against destructive operations, not bad design
Azure management locks add a separate safety mechanism. A Delete, or CanNotDelete, lock prevents deletion while still allowing authorized modification. A Read-only, or ReadOnly, lock blocks updates and deletions, making the resource effectively read-only through the control plane.
Locks can be applied at subscription, resource-group, or resource scope, and they inherit downward. The most restrictive lock in the inheritance chain takes precedence. That makes a subscription-level ReadOnly lock extraordinarily powerful and potentially disruptive.
Locks override user permissions for the protected operation. An Owner does not bypass a Delete lock simply by being Owner. Someone with permission to manage the lock must remove or change the lock before the protected action can succeed.
This is why locks are ideal for protection against accidental deletion of a critical shared component, but poor as a substitute for authorization design. They do not decide who should administer a service, and they do not evaluate whether the configuration is secure.
Locks can break legitimate operations in surprising ways
A lock acts at the Azure control plane, and some services perform control-plane writes behind operations that look routine. A ReadOnly lock can therefore block more than an administrator expects. Extension resources can inherit locks from their parent resources. Diagnostic settings, networking changes, backup operations, and service-specific maintenance can be affected depending on the resource type.
Before locking a production scope, understand how that service is operated and updated. A Delete lock is often less disruptive than ReadOnly because it protects the resource’s existence while permitting normal configuration changes.
The same principle applies to resource groups. Locking a resource inside a group can prevent deletion of the whole resource group because Azure cannot perform a partial group deletion when a locked child remains.
A lock should have an owner, a reason, and an expected removal process. Otherwise it becomes a future incident waiting for the day an authorized change fails at the worst possible moment.
Policy and locks solve different failure modes
Consider a production storage account. Policy can require secure transfer, restrict public access configurations, enforce approved regions, or audit diagnostic settings. RBAC can limit which teams can administer the account. A Delete lock can reduce the chance that an authorized operator accidentally deletes it.
None of those controls makes the others redundant. The lock does not validate configuration. Policy does not identify every human who should have access. RBAC does not stop an Owner from deleting a resource if deletion is within that person’s authorization and no lock exists.
Thinking in failure modes makes governance easier. Unauthorized action is an access-control problem. Noncompliant configuration is a policy problem. Accidental destructive action by an authorized identity is where a management lock may help.
Good governance is layered but still understandable
The goal is not to maximize the number of controls. It is to make the environment explainable. A platform team should be able to answer which management group owns the subscription, which baseline policies inherit into it, which exceptions exist, who has privileged roles, which resources are locked, and why.
That clarity is one reason the Microsoft certifications landscape separates administration, networking, security, and architecture skills: large Azure environments are governed by interacting disciplines. Administrators do not need to own every discipline, but they do need to recognize which control belongs to which problem.
A mature design also treats exceptions as scoped decisions rather than permanent escapes. A policy exemption at one resource group should have an owner, a reason, and an expected end state; otherwise the exception quietly becomes the real standard. The same principle applies to privileged RBAC assignments and locks. Put the control at the narrowest scope that still expresses the intended rule, then verify what inherits below it. That discipline matters because a management-group decision can affect many subscriptions, while a resource-level lock may protect only one critical object. Administrators should be able to trace a surprising deny, audit result, or failed delete upward through the hierarchy and identify the control responsible. Governance is easier to operate when scope is explicit, exceptions are visible, and every inherited control has a reason to exist.
When subscriptions, Policy, RBAC, and locks are used for the jobs they actually perform, governance becomes less mysterious. Scope organizes the environment, RBAC limits authority, Policy evaluates or enforces configuration standards, and locks add protection against destructive control-plane changes. The stack works because the layers are different, not because they all do the same thing.