The fundamental difference
Azure RBAC (Role-Based Access Control) and Azure Policy both appear in AZ-104 governance questions. They are often presented in the same answer choices. Choosing the wrong one costs marks that should be straightforward.
Azure RBAC: Controls actions. Who can create, read, update, or delete which resources. A user with the Reader role can view resources but cannot create or delete them. A user with Contributor can create and manage resources but cannot assign access to others. RBAC is about identity and authorisation.
Azure Policy: Controls configurations. What resource configurations are allowed, denied, audited, or automatically remediated. A policy can prevent any resource being created without a required tag. A policy can audit all storage accounts and report which ones have public access enabled. Azure Policy is about resource state and compliance.
An easy way to remember the difference: RBAC answers "can this person do this action?" Policy answers "is this resource configuration allowed?"
When to use RBAC — exam scenarios
A question describes a junior developer who should be able to deploy resources in a resource group but should not be able to assign permissions to others. The correct answer is to assign the Contributor role scoped to that resource group. Contributor grants create, read, update, and delete on resources but explicitly excludes permission management (which requires Owner or User Access Administrator).
Another common scenario: a security team needs read-only access to all resources across a subscription for auditing. Assign the Reader role at the subscription scope. Scope determines where the role applies — management group, subscription, resource group, or individual resource. Roles at a higher scope inherit down.
When to use Azure Policy — exam scenarios
A question states that the organisation must ensure all new virtual machines are created in the UK South or UK West regions only. No VM should be deployable in other regions. The correct answer is to create an Azure Policy with a Deny effect that blocks deployment outside the allowed regions.
RBAC cannot do this. You could prevent a user from creating VMs entirely (by removing the Contributor role), but you cannot use RBAC to restrict which region they deploy into while still allowing VM creation.
Another scenario: the organisation wants a report of all storage accounts with public blob access enabled, without blocking deployment. The correct answer is a policy with Audit effect. Audit reports non-compliant resources without denying them.
Policy effects — the exam tests all five
Deny: Blocks the operation that would create a non-compliant resource. The request fails. Audit: Allows the operation but marks the resource as non-compliant in the compliance dashboard. Append: Adds fields to the resource request before deployment (for example, adding a tag automatically). Modify: Used to add, update, or remove tags on resources after deployment. DeployIfNotExists / AuditIfNotExists: Checks for related resources (like a diagnostic setting) and deploys or audits if missing.
The exam distinguishes between Deny (prevent) and Audit (report). When the requirement says "ensure no resource can be created without a tag," the answer is Deny. When the requirement says "generate a report of resources missing a tag," the answer is Audit.
Built-in roles — the ones the exam tests
Owner: Full access including permission management. Can assign roles to other users. Contributor: Full access except permission management. Cannot assign roles. Reader: Read-only. Cannot make changes. User Access Administrator: Can manage access (assign roles) but has no other resource management permissions.
These four are the most-tested built-in roles. The exam also references service-specific roles (Virtual Machine Contributor, Storage Blob Data Reader, etc.) in context-specific questions.
The trap: using RBAC to enforce configuration
A question describes a requirement to ensure VMs always have a specific SKU size. An administrator assigns a custom RBAC role that restricts VM creation. This is technically possible but it is the wrong tool. Azure Policy with a Deny effect on non-compliant VM SKUs is the correct approach.
RBAC scoped to resource types blocks actions on that resource type entirely. You cannot use RBAC to allow VM creation with SKU A but block VM creation with SKU B. Policy can.
Practice AZ-104 governance questions
AZ-104 practice questions on Courseiva include RBAC, Azure Policy, and management group scenarios. The Azure Resource Manager topic guide covers scope, resource groups, and management hierarchy. For a full AZ-104 session, see the AZ-104 practice test.
Frequently asked questions
Can a user be blocked by both RBAC and Azure Policy? Yes. Both apply independently. A user without Contributor access cannot create resources because RBAC blocks the action. A user with Contributor access still cannot create a non-compliant resource if a Deny policy applies. Both must allow the operation for it to succeed.
What is a management group? A management group is a container above subscriptions. Policies and RBAC assignments at the management group scope apply to all subscriptions within it. Large organisations use management groups to enforce governance across hundreds of subscriptions from a single point.
Does Azure Policy automatically fix existing non-compliant resources? Only with the DeployIfNotExists or Modify effects, and only when a remediation task is triggered. Deny and Audit policies do not change existing resources. A remediation task can be run manually or triggered automatically for supported policy types.
Built-In Role Details — The Four Classic Roles
AZ-104 tests the four classic built-in roles constantly, and the exam is precise about their boundaries:
Owner — Full access to all resources plus the ability to manage RBAC (assign roles to others). This is the only built-in role that can grant other users access. Subscription Owners can assign any role, including Owner, at any scope within the subscription.
Contributor — Full access to create and manage all resources but cannot manage RBAC. A Contributor cannot grant access to other users. This is the most commonly misunderstood boundary — Contributor can do everything except change who has access.
Reader — Read-only access to all resources. Cannot make any changes. Can view configurations, read data, but cannot create, update, or delete anything.
User Access Administrator — Can manage RBAC (assign and remove role assignments) but has no permissions to actually manage Azure resources. Used for administrators whose only job is managing access, not operating resources.
Custom roles are created when built-in roles are too broad or too narrow. Example: a team needs to start and stop VMs but not delete them or change their configuration. No built-in role fits exactly — you create a custom role with only the specific actions needed (Microsoft.Compute/virtualMachines/start/action and stop/action).
Exam trap: "A user needs to create virtual machines and deploy applications, but should not be able to give other users access to resources. Which role?" → Contributor (not Owner).
RBAC Scope Hierarchy — What Inherits Downward
RBAC assignments propagate downward through the scope hierarchy:
Management Group → Subscription → Resource Group → Resource
A role assigned at the management group level applies to all subscriptions within that management group, all resource groups in those subscriptions, and all resources in those resource groups. A role assigned at the resource group level applies only to resources within that resource group.
There is no "deny at a lower scope to override an allow at a higher scope" in standard RBAC — that's a common misconception. If a user has Contributor at the subscription level, they have Contributor access to every resource group and resource in that subscription. You cannot remove this by assigning Reader at a resource group level — RBAC grants are additive, not subtractive.
The exception: Azure Deny Assignments. These are created by Azure Blueprints or Managed Applications (not by administrators directly) and explicitly block actions even if a role assignment would permit them. They're rare and the exam tests them conceptually rather than requiring configuration knowledge.
Azure Policy Initiatives — Grouping Policies
An initiative (also called a policy set definition) is a collection of individual policy definitions that are grouped together and assigned as a unit.
Benefits: instead of assigning 12 individual policies for NIST 800-53 compliance, you assign one initiative that contains all 12. When you view compliance, you see compliance at the initiative level with drill-down to individual policies.
Built-in initiatives include:
- Azure Security Benchmark (formerly Azure CIS benchmark)
- NIST SP 800-53
- PCI DSS
- ISO 27001
Creating a custom initiative: Policy → Definitions → + Initiative definition → Add policy definitions → assign scope.
Exam pattern: "A company needs to enforce 15 related security policies across all subscriptions. What is the most efficient approach?" → Create a custom initiative containing all 15 policies, assign the initiative at the management group level.
The exam distinguishes: assigning individual policies vs assigning an initiative. The initiative approach is always the correct answer for "efficiently apply multiple related policies."
Policy Remediation — Making Existing Resources Compliant
New resources are evaluated at creation time. But what about existing resources that were created before a policy was assigned?
Audit effect — only reports non-compliance, doesn't change anything.
DeployIfNotExists (DINE) — If a resource doesn't have the required associated resource (e.g., a VM without a Log Analytics agent extension), the policy deploys it. Requires a managed identity on the policy assignment to perform the deployment. After assignment, non-compliant existing resources require a remediation task to be created and run.
Modify effect — changes properties on existing resources (tags, SKU settings). Also requires managed identity and remediation task for existing resources.
The remediation task workflow:
- Assign policy with DINE or Modify effect.
- Azure evaluates existing resources — marks non-compliant ones.
- Create a remediation task: Policy → Remediation → New remediation task → select the policy assignment.
- The remediation task runs the policy's deployment against non-compliant resources.
Exam pattern: "A policy with DeployIfNotExists effect is assigned to a subscription. Existing VMs are non-compliant. What must be done to bring existing VMs into compliance?" → Create and run a remediation task.
The Lock vs Policy vs RBAC Triangle — When to Use Which
These three mechanisms all control what can happen to Azure resources, but they're not interchangeable:
Resource Lock (CanNotDelete or ReadOnly) — Prevents specific operations regardless of RBAC permissions. Even a subscription Owner cannot delete a resource with a CanNotDelete lock without first removing the lock. Locks are set at resource, resource group, or subscription scope and inherited downward. Locks override RBAC — they apply to everyone, including Owners.
Azure Policy — Enforces organizational standards on new and existing resources. Prevents creation of resources that don't meet standards (Deny effect), reports on non-compliance (Audit), or remediates automatically (DeployIfNotExists, Modify). Policy is about configuration standards, not access control.
RBAC — Controls who can perform what actions on resources. Grants permissions to specific users, groups, or service principals.
Exam scenario mapping:
- "Prevent anyone from deleting a critical storage account, even subscription owners" → Resource Lock (CanNotDelete)
- "Prevent anyone from creating VMs without an approved tag" → Azure Policy (Deny effect)
- "Allow a developer to create VMs but not delete resource groups" → RBAC (custom role or built-in without delete permissions)
Management Lock Types — ReadOnly vs CanNotDelete
CanNotDelete — Users can read and modify the resource but cannot delete it. This is the less restrictive lock. Most write operations still work. Commonly applied to production resources.
ReadOnly — Users can read the resource but cannot modify or delete it. This is more restrictive than it sounds — some "read" operations in Azure actually trigger state changes. For example, listing storage account keys is a POST operation internally, so ReadOnly locks on storage accounts prevent key listing. This can break applications that rely on listing keys at startup.
ReadOnly on a resource group prevents adding resources to it, because creating a resource in a resource group is a write operation on the resource group.
The exam tests: "A ReadOnly lock is applied to a resource group. A user with Contributor role tries to create a new virtual machine in that resource group. What happens?" → The operation fails. The ReadOnly lock blocks all write operations, including resource creation, regardless of RBAC role.
Portal path: Resource or Resource Group → Settings → Locks → Add lock.