An Azure administrator wants developers to deploy resources into a subscription, but the company requires approved regions, specific tags, and no public IP addresses on certain workloads. Giving or withholding a role does not fully solve that problem. The developers may legitimately need permission to create resources; the organization still needs rules about the state of what they create.
That is the dividing line between Azure role-based access control and Azure Policy. For AZ-104, the most reusable decision framework is to ask whether the problem is about who may perform an action or what resource state is acceptable. RBAC primarily governs the former. Azure Policy primarily governs the latter.
Use RBAC when identity should change the answer
Azure RBAC connects a principal, role definition, and scope. It is appropriate when the authorization decision depends on who the caller is and what that identity is allowed to do. A storage operator may need data-plane permissions. A network team may need to modify virtual networks. An auditor may need read-only access across a subscription.
The design can narrow both actions and scope. A role can apply at management group, subscription, resource group, or resource level, with inheritance to child scopes. If the core question is “may this user, group, service principal, or managed identity perform this operation here?” RBAC is the natural control.
Role-based access control in Azure remains the authorization layer; Azure Policy should not be used as a substitute for basic identity-based access design.
Use Azure Policy when the resulting resource state should change the answer
Azure Policy evaluates resources and requests against organizational rules. It can audit noncompliance, deny certain noncompliant creates or updates, modify supported properties, or deploy related configuration depending on the definition and effect. The important point is that the resource state matters even when the caller is otherwise authorized.
Suppose a developer has Contributor rights to create a storage account. RBAC says that identity may create the resource. A policy may still require particular network settings or tags, or may deny a configuration that violates the organization’s standards. The two controls therefore compose: authorization is necessary, but it is not sufficient to make the requested resource compliant.
This is why governance designs often use both instead of treating them as competing products.
Policy can express organization-wide guardrails more consistently than role design
Trying to enforce every configuration rule through RBAC leads to awkward roles. A custom role can remove specific actions, but it generally does not express rich requirements about resource properties such as location, SKU, tags, allowed types, diagnostic settings, or other configuration state.
Policy definitions and initiatives let organizations group those expectations and assign them at scopes that match governance boundaries. Compliance results then provide evidence about existing resources, including resources that became noncompliant through drift or were created before a stronger rule was assigned.
Cloud governance in Azure is broader than any one control. Policy contributes the rule-and-evidence layer, while RBAC contributes authorization and accountability for administrative actions.
Deny should be used where the organization is ready to block work
An audit policy can reveal noncompliance without stopping deployment. A deny policy changes the operational contract: a request that would create a noncompliant resource can fail before the resource provider performs the requested change. That can be valuable for high-confidence guardrails and disruptive when requirements are poorly tested.
Teams should therefore introduce policy deliberately. Start with clear outcomes, evaluate existing resources, understand exemptions, and test policy logic against legitimate deployment patterns. If a deny rule is too broad, developers may experience unexplained failures and create pressure for sweeping exemptions.
Some governance goals are better introduced in audit mode first so teams can measure impact and remediate before enforcement. The mature decision is not “deny everything possible”; it is to use enforcement where the rule is important, testable, and operationally supported.
RBAC cannot make a noncompliant resource compliant
A common anti-pattern is giving only senior administrators permission to create sensitive resources and assuming their expertise is the control. Skilled people still make mistakes, automation can carry old assumptions, and emergency work can bypass normal review. If the desired state is important enough to be consistent, encode it where practical.
Conversely, Policy cannot replace separation of duties. A perfectly compliant resource can still be created, modified, or deleted by the wrong person if RBAC is too broad. Policy does not answer every identity-specific question, and many policy definitions are visible broadly because the system is intended to make organizational rules transparent.
The controls protect different dimensions of the same environment.
Resource locks are a third tool with a narrower job
Delete and Read-only locks are useful when a specific resource, resource group, or subscription should resist accidental deletion or modification. A lock can override what an authorized user would otherwise be permitted to do, but it is not a full compliance engine and does not replace RBAC.
For example, a critical resource could have carefully scoped RBAC, be subject to policies requiring approved configuration, and carry a Delete lock to reduce accidental removal. Each control answers a different failure mode.
This layered design is especially important because locks mainly operate on Azure control-plane operations. Administrators still need data protection, backup, application authorization, and service-specific controls for the data inside a resource.
Exceptions and exemptions should preserve accountability
No governance rule fits every workload forever. Azure Policy supports exemption patterns so an organization can acknowledge that a resource is outside a rule for an approved reason. RBAC also needs exception handling for temporary elevated access.
The danger is allowing exceptions to become invisible permanent architecture. Every exemption should have an owner, rationale, scope, and review or expiration expectation. A large exemption population can indicate that the policy is poorly targeted or that teams are repeatedly choosing speed over the intended standard.
Good governance reports therefore distinguish compliant resources from exempt resources instead of treating both as equivalent success.
Three scenarios make the division of responsibility concrete
First, consider an application team that may deploy storage accounts but only in approved regions and with required tags. The team needs RBAC permission to create the resources. Azure Policy is the better place for the location and tag rules because those requirements should apply regardless of which authorized team member performs the deployment.
Second, consider a production resource that should rarely be deleted. RBAC can limit who is allowed to delete it. A Delete lock can add another layer of friction even for authorized administrators. Policy may be appropriate if the organization wants a scalable delete-prevention rule for a whole class of resources. The choice depends on whether the requirement is identity-specific, resource-specific, or an organization-wide state rule.
Third, consider a security team that wants every supported virtual machine to send diagnostic information to an approved destination. Restricting creation rights to a small administrator group does not ensure the setting remains present. Policy can audit or remediate supported configuration, while RBAC determines which identities may create and modify the machines and monitoring resources.
These examples also show why “Policy versus RBAC” is often the wrong final framing. The production design normally needs both. RBAC establishes the people and workload identities allowed to operate. Policy narrows the states those operations are permitted to produce and provides compliance evidence at scale.
Large environments rarely manage every rule as an isolated definition. Initiatives can group related policy definitions into a coherent set such as a baseline for networking, monitoring, tagging, or regulated workloads. Assignments can then apply the initiative at a management group, subscription, or resource-group scope that matches the governance boundary.
Some policy effects can modify or deploy supporting configuration, which introduces another identity and permission consideration: remediation may require a managed identity with sufficient rights. This is a useful reminder that automated governance itself has an authorization path. A policy can be correctly written yet fail to remediate if the supporting identity lacks the necessary permission.
Operations teams should monitor both compliance results and policy-assignment changes. A perfectly compliant dashboard means little if a broad exemption or assignment removal quietly disabled the rule for the most important scope.
Decide by asking what must remain true after the administrator leaves
A useful test is to imagine that the person performing today’s deployment changes teams tomorrow. The resource should still obey organizational configuration rules; that argues for Policy. The person should lose authorization no longer required by the job; that argues for RBAC. A particularly critical resource may still need a deletion barrier; that argues for a lock.
Within the Azure Administrator Associate path, Policy and RBAC are complementary governance tools. Use RBAC when identity and allowed actions are the deciding factors. Use Policy when resource state and organizational standards must hold regardless of which authorized identity made the change. Combine them when both questions matter—which, in production Azure, is most of the time.
The governance boundary should also be understandable to application teams. If a deployment is denied, the error should point toward a documented rule and an exception path rather than forcing engineers to discover policy by trial and error. Good platform teams publish the intent behind initiatives, the scopes where they apply, common remediation steps, and who can approve a legitimate exemption. That transparency reduces the temptation to bypass governance and turns policy failures into actionable engineering feedback.
Policy design also needs a lifecycle when Azure services evolve. New resource types and properties can fall outside an older definition, while a once-useful rule can become redundant after the platform changes. Initiative owners should review coverage, policy effects, exemptions, and remediation behavior periodically instead of assuming that an assignment made years ago still represents the organization’s current standard.
