AzureAZ-104

Azure Resource Manager (ARM) and Azure Governance Explained for AZ-104

Everything you do in Azure goes through Azure Resource Manager. When you create a VM from the portal, run an Azure CLI command, or deploy an ARM template, ARM is the layer that receives, authenticates, authorizes, and executes the request. Understanding ARM means understanding how Azure is organized, how deployments work, and how governance controls like Azure Policy and management groups enforce rules across your entire environment. The AZ-104 exam tests ARM and governance together because you cannot properly govern Azure without understanding the resource hierarchy it sits on top of.

7 min

3 sections · 6 exam key points

5 practice questions

The Azure resource hierarchy

Azure organizes resources in a four-level hierarchy: Management Groups at the top, then Subscriptions, then Resource Groups, then individual Resources. Policies, RBAC assignments, and cost tracking all flow down this hierarchy. Applying a policy at a management group level automatically applies it to all subscriptions, resource groups, and resources below it.

Subscriptions are billing boundaries and access control boundaries. Each subscription has its own spending limits, invoice, and set of Azure RBAC assignments. Separating environments (production, development, testing) into separate subscriptions gives you clean cost tracking and prevents a misconfiguration in one environment from affecting another.

Resource groups are the logical containers for related Azure resources. Every resource must belong to exactly one resource group. Resources in the same resource group can be in different Azure regions. Resource groups are useful for lifecycle management: deleting a resource group deletes all resources inside it. Apply tags to resource groups to organize cost reporting and automate management.

Azure RBAC, ARM templates, and Azure Policy

Azure RBAC (Role-Based Access Control) controls who can do what to which resources. RBAC assignments consist of three parts: a security principal (user, group, service principal, or managed identity), a role definition (what actions are allowed), and a scope (where the assignment applies). Roles are inherited downward through the hierarchy: a Contributor at the subscription level can modify any resource in that subscription.

ARM templates are JSON files that declare the desired state of your Azure infrastructure. Deploy the template and ARM creates, updates, or deletes resources to match the declaration. This is infrastructure as code. Incremental mode only changes what is different from the current state. Complete mode deletes any resource in the resource group not defined in the template, which can cause unintended deletions if used carelessly. Bicep is Microsoft's domain-specific language that compiles to ARM templates with cleaner, more readable syntax.

Azure Policy evaluates resources against rules you define: every storage account must have encryption enabled, every VM must use approved image types, no public IP addresses may be created. Policies can be in Audit mode (flag violations without blocking) or Deny mode (block the deployment entirely). Policy initiatives group related policies together for simpler assignment.

How to choose the correct answer

Scope for RBAC: assign at the highest scope that works. Owner at subscription = can manage all resources in that subscription. Reader at a specific resource group = read-only for that group only.

ARM template deployment modes: Incremental = safe, adds or updates, does not delete untracked resources. Complete = enforces exact template state, deletes resources not in the template.

Azure Policy vs RBAC: RBAC controls who can take actions. Policy controls what configurations are allowed. You can have permission to create a storage account (RBAC) but policy can prevent it from being created without encryption.

Management groups: apply policy and RBAC at scale across multiple subscriptions. Root management group applies to the entire tenant.

Locks: ReadOnly lock prevents any modifications or deletions. CanNotDelete lock prevents deletion but allows modifications. Locks override RBAC: even an Owner cannot delete a resource protected by a CanNotDelete lock without first removing the lock.

Azure RBAC built-in roles

Role	Can read?	Can modify?	Can delete?	Can manage access?
Owner	Yes	Yes	Yes	Yes
Contributor	Yes	Yes	Yes	No
Reader	Yes	No	No	No
User Access Administrator	Yes	No	No	Yes (RBAC only)

Key exam facts — AZ-104

ARM processes every Azure API call: portal, CLI, PowerShell, SDK.
Resource hierarchy: Management Group > Subscription > Resource Group > Resource.
RBAC: principal + role + scope. Inherited downward. Additive across multiple assignments.
ARM Incremental mode: safe, does not delete. Complete mode: deletes untracked resources.
Azure Policy: Audit (flag only) or Deny (block). Applies compliance rules regardless of RBAC.
Locks: CanNotDelete prevents deletion. ReadOnly prevents all modifications. Overrides Owner role.

Common exam traps

The resource group location restricts where resources inside it can be deployed.

The resource group location only stores the resource group metadata. Resources inside the group can be deployed to any Azure region regardless of the resource group's own location.

Azure Policy and RBAC serve the same purpose.

RBAC controls who can take actions on resources. Azure Policy controls what configurations are permitted regardless of who is making the request. An Owner with full RBAC permissions can still be blocked from deploying a non-compliant resource by a Deny policy.

ARM template Complete mode is safer because it enforces a clean state.

Complete mode deletes any resource in the resource group that is not defined in the template. If the template is missing resources that should exist, Complete mode will delete them silently. Use Incremental mode for most deployments and reserve Complete only when you explicitly want to enforce the exact template state.

Practice questions — Azure Resource Manager

These questions are representative of what you will see on AZ-104 exams. The correct answer and explanation are shown immediately below each question.

Q1.A developer has Contributor RBAC access to a production resource group. An Azure Policy in Deny mode prevents creation of storage accounts without encryption. The developer tries to create an unencrypted storage account. What happens?

A.The storage account is created because Contributor RBAC allows it

B.The creation is denied by Azure Policy regardless of the RBAC assignment

C.The storage account is created but flagged as non-compliant

D.The request requires Global Administrator approval

Explanation: Azure Policy operates independently from Azure RBAC. RBAC controls who can take actions; Policy controls what configurations are permitted. Even with Contributor access (which allows resource creation), an Azure Policy in Deny mode blocks any deployment that doesn't meet the policy requirement. Policy enforces compliance rules that override individual user permissions.

Q2.An organization deploys an ARM template in Complete mode to a resource group that already contains a storage account not defined in the template. What happens to the existing storage account?

A.It is preserved because Complete mode only adds new resources

B.It is deleted because Complete mode enforces the exact state defined in the template

C.It is moved to a different resource group

D.The deployment fails because of the resource conflict

Explanation: ARM template Complete mode enforces the exact state defined in the template within the targeted resource group. Any resource in the resource group not defined in the template is deleted. This is a significant risk — use Complete mode carefully and only when you explicitly want the resource group to contain exactly what's in the template. Incremental mode adds or updates resources without deleting untracked ones.

Q3.An administrator assigns the Reader RBAC role to a user at the subscription level. The user attempts to modify a VM in a resource group within that subscription. What is the result?

A.The modification succeeds because Reader includes read-write at subscription level

B.The modification is denied because Reader only allows read operations

C.The result depends on the resource group's RBAC settings overriding the subscription assignment

D.Reader at subscription level grants write access only within the user's own resource groups

Explanation: Reader is a read-only RBAC role. Assigned at the subscription level, it grants read access to all resources within that subscription (inherited through the hierarchy). It does not allow any modifications. RBAC assignments are additive and inherited downward — a Reader at subscription scope is a Reader everywhere in that subscription unless a more permissive role is added at a lower scope.

Q4.A company needs to prevent accidental deletion of a critical production database while still allowing configuration changes to it. Which Azure resource lock should be applied?

A.ReadOnly lock

B.CanNotDelete lock

C.No lock; use RBAC to restrict delete permissions instead

D.Delete lock applied at the subscription level

Explanation: CanNotDelete lock prevents deletion of the resource but still allows read and write operations — including configuration changes. ReadOnly lock would prevent any modifications (including desired configuration changes). Locks override even Owner RBAC permissions — no one can delete a CanNotDelete-locked resource without first removing the lock.

Q5.A company has 15 Azure subscriptions across three departments. They need to apply a security policy to all subscriptions simultaneously without applying it to each subscription individually. What should they use?

A.Apply the Azure Policy to each subscription manually

B.Create a Management Group containing all subscriptions and apply the policy at the Management Group level

C.Create a single large resource group spanning all subscriptions

D.Use Entra ID Conditional Access to enforce the policy

Explanation: Management Groups allow hierarchical organization of subscriptions. Policies and RBAC assignments applied at a Management Group level are inherited by all subscriptions, resource groups, and resources within it. This is the correct pattern for enforcing governance at scale across multiple subscriptions without individual manual configuration.

Frequently asked questions — Azure Resource Manager

What is Azure Resource Manager (ARM)?

Azure Resource Manager is the management layer that processes every Azure request — whether from the portal, CLI, PowerShell, REST API, or SDK. It authenticates the request (using Entra ID), authorizes it (checking RBAC and Policy), and then executes it. ARM is also the deployment engine for ARM templates and Bicep, enabling infrastructure as code deployments where you declare desired state and ARM reconciles the current state.

What is the difference between Azure RBAC and Azure Policy?

Azure RBAC controls who can perform which actions on which resources (identity and access management). Azure Policy controls what configurations are permitted regardless of who is making the request. You can think of it this way: RBAC says 'you are allowed to create storage accounts', Policy says 'any storage account you create must have encryption enabled'. A Deny policy blocks non-compliant deployments even from users with full Contributor or Owner access.

What is the Azure resource hierarchy?

Azure uses a four-level hierarchy: (1) Management Groups — organize multiple subscriptions for policy and RBAC at scale; (2) Subscriptions — billing and access control boundaries, each with its own invoice; (3) Resource Groups — logical containers for related resources that share a lifecycle; (4) Resources — individual Azure services (VMs, storage accounts, databases). Policies and RBAC assignments applied at higher levels are inherited by everything below.

What is the difference between ARM Incremental and Complete deployment modes?

Incremental mode (default) adds or updates resources defined in the template but leaves existing resources not in the template unchanged. This is safe for most deployments. Complete mode enforces the exact state in the template — any resource in the target resource group not defined in the template is deleted. Complete mode is useful for environment enforcement but dangerous if the template doesn't include all intended resources.

What are Azure resource locks and how do they work?

Resource locks prevent accidental deletion or modification of Azure resources. CanNotDelete lock: users can read and modify the resource but cannot delete it. ReadOnly lock: users can read the resource but cannot modify or delete it. Locks override RBAC permissions — even an Owner cannot delete a CanNotDelete-locked resource without first removing the lock. Locks can be applied at subscription, resource group, or resource level and are inherited downward.

Practice this topic

AZ-104practice questions

Test yourself on Azure Resource Manager

JT Exams routes you to questions in your exact weak areas — automatically, after every session.

Free practice test Start 7-Day Free Trial

No credit card · Cancel anytime