This chapter covers Azure Resource Manager (ARM), the foundational deployment and management service for Azure. ARM is the 'control plane' through which you create, update, and delete resources. For AZ-900, understanding ARM is critical because it underpins every interaction with Azure resources, and questions about ARM templates, resource groups, and management groups appear frequently across multiple domains. This objective area (Azure Architecture Services) carries approximately 20-25% of the exam weight, with ARM concepts being a core component. By the end of this chapter, you will be able to explain ARM's role, its key components, and how it enables consistent, repeatable deployments.
Jump to a section
Imagine you are the city planner of a growing metropolis. You need to build a new neighborhood with houses, a school, a park, and a fire station. Each building is like an Azure resource (a VM, a database, a storage account). Without a plan, you'd hire separate contractors for each building, each ordering their own materials, digging their own foundations, and connecting to utilities haphazardly. This leads to chaos, wasted materials, and incompatible designs. Azure Resource Manager (ARM) is like a master architect and a single blueprint. You write one declarative plan (an ARM template) that describes every building, its size, location, and how they connect to roads and power lines. The architect ensures all buildings are built in the correct order (dependencies), uses consistent materials (same region and subscription), and can update or tear down the entire neighborhood with a single command. If you need to replicate the neighborhood in another city, you reuse the same blueprint. ARM is the orchestration layer that turns your intent into a coordinated, repeatable deployment, preventing configuration drift and manual errors.
What is Azure Resource Manager and Why Does It Exist?
Azure Resource Manager (ARM) is the deployment and management service for Azure. It provides a consistent management layer that enables you to create, update, and delete resources in your Azure subscription. Before ARM, Azure used the Azure Service Management (ASM) model, which was less flexible and lacked declarative deployment capabilities. ARM was introduced to solve several business problems:
Inconsistent management: Different resource types had different management APIs, making automation difficult.
Lack of declarative deployment: You had to script resource creation step-by-step, with no easy way to define the entire infrastructure as code.
No dependency management: You had to manually ensure resources were created in the correct order.
Hard to roll back: There was no simple way to revert changes or delete a group of resources together.
ARM addresses these by providing a single REST API, declarative templates (ARM templates), and resource grouping (resource groups). It also enforces Role-Based Access Control (RBAC), policies, and tags at the resource level.
How ARM Works – Step by Step
Request Submission: When you create a resource via the Azure portal, PowerShell, CLI, or SDK, the request goes to the ARM API.
Authentication and Authorization: ARM checks your identity (via Azure AD) and verifies you have the required RBAC role (e.g., Contributor) on the target scope (subscription or resource group).
Template Validation (if using ARM template): ARM validates the template syntax and ensures all referenced resources exist or are defined.
Dependency Resolution: ARM analyzes the dependsOn properties or implicit dependencies (e.g., a VM depends on its NIC) and determines the correct creation order.
Resource Provider Registration: ARM sends requests to the appropriate resource providers (e.g., Microsoft.Compute for VMs) in the correct order.
Resource Provisioning: Each resource provider creates the resource in its backend, returning status to ARM.
State Recording: ARM records the final state of the resource in its database, linking it to the resource group and subscription.
Response: ARM returns the result (success or failure) to the caller. If a failure occurs, ARM can automatically roll back (if using rollbackOnError in templates).
Key Components of ARM
Resource Group: A logical container for resources that share the same lifecycle. All resources in a group are typically deployed, updated, and deleted together. A resource can belong to only one resource group, but a resource group can contain many resources.
ARM Template: A JSON (or Bicep) file that declaratively defines the infrastructure. It includes parameters, variables, resources, and outputs. ARM templates are idempotent – deploying the same template multiple times results in the same state.
Resource Provider: A service that supplies Azure resources. For example, Microsoft.Compute supplies VMs, Microsoft.Storage supplies storage accounts. Each resource provider has a set of resource types and API versions.
Management Group: A container for managing access, policies, and compliance across multiple subscriptions. Management groups form a hierarchy (up to 6 levels deep) and are used for enterprise governance.
RBAC (Role-Based Access Control): ARM uses RBAC to enforce permissions. Built-in roles like Owner, Contributor, and Reader can be assigned at management group, subscription, resource group, or resource scope.
Tags: Key-value pairs that can be applied to resources for categorization, cost tracking, and automation. Tags are not inherited by default.
ARM Templates vs. Bicep
ARM templates are native JSON files. They can be verbose and hard to read. Bicep is a domain-specific language (DSL) that compiles to ARM templates. Bicep is simpler, with cleaner syntax, modularity, and better error messages. Both are declarative and support all ARM features.
How ARM Compares to On-Premises Equivalent
On-premises, infrastructure is often managed manually or with scripts (PowerShell, Bash). There is no central, declarative orchestration layer. Changes are made directly to servers, leading to configuration drift. ARM provides: - Declarative vs. Imperative: You declare the desired state, not the steps. - Idempotency: Repeated deployments produce the same result. - Dependency Management: Automatic ordering. - Audit and History: ARM stores deployment history (up to 800 deployments per resource group). - Role-Based Access: Fine-grained permissions.
Azure Portal and CLI Touchpoints
Portal: When you create a resource, the portal sends ARM REST API calls. You can view deployment status, resource group membership, and templates under 'Deployments'.
CLI: Commands like az group create, az deployment group create interact with ARM. The --template-file parameter deploys an ARM template.
PowerShell: New-AzResourceGroup, New-AzResourceGroupDeployment.
REST API: https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProvider}/{resourceType}/{resourceName}?api-version=2019-10-01.
Business Scenario: E-Commerce Application
A retail company deploys a web app with a SQL database, a storage account for images, and a virtual network. They use an ARM template to define everything. When they need to deploy to a new region (e.g., Europe), they reuse the same template with different parameters (region, SKU). ARM ensures all resources are created in the correct order, with consistent naming and tags for cost tracking. If a deployment fails, ARM rolls back partially, preventing orphaned resources.
Pricing
ARM itself is free. You pay only for the underlying resources (VMs, storage, etc.). There is no cost for using ARM templates, management groups, or resource groups.
Create a Resource Group
Open the Azure portal, search for 'Resource groups', and click 'Create'. Enter a name (e.g., 'rg-ecommerce-prod'), select a region (e.g., East US), and optionally add tags (e.g., Environment=Production). Resource groups are free and serve as a logical container. Behind the scenes, ARM registers the resource group in its database and assigns it a unique ID. Important: A resource group can contain resources from different regions, but the group itself must be in one region. This is a common exam trap.
Write an ARM Template
Create a JSON file that declares the desired resources. For example, a template to deploy a storage account includes the schema, contentVersion, parameters (like storageAccountName), variables, resources (with type 'Microsoft.Storage/storageAccounts'), and outputs (like the storage endpoint). ARM templates use a declarative syntax – you describe 'what' you want, not 'how'. The template must include the `apiVersion` for each resource type, e.g., '2021-09-01'. Use tools like VS Code with the ARM Tools extension for validation.
Deploy the Template
Use Azure CLI: `az deployment group create --resource-group rg-ecommerce-prod --template-file template.json --parameters parameters.json`. ARM receives the request, validates the template, and checks RBAC permissions. It then resolves dependencies. For instance, a VM depends on its NIC, which depends on a VNet and subnet. ARM ensures the VNet and subnet are created first. It then calls the resource providers in order. If any resource fails, ARM can roll back (if configured). Deployment history is stored and viewable in the portal.
Verify Deployment
In the portal, go to the resource group and click 'Deployments'. You'll see the deployment name, status (Succeeded/Failed), and duration. Click on the deployment to view details – which resources were created, modified, or deleted. ARM also logs operations in the Activity Log. You can download the template and parameters for future use. Important: ARM deployments are idempotent; re-deploying the same template results in the same state, not duplicate resources.
Manage with Tags and RBAC
After deployment, apply tags to resources for cost reporting. Use Azure Policy to enforce tags. Assign RBAC roles at the resource group level – e.g., give the development team 'Contributor' on the resource group so they can manage resources but not change access. ARM enforces these permissions on every subsequent request. Tags are not automatically inherited; you must apply them explicitly or use Azure Policy to enforce inheritance.
Scenario 1: Enterprise Governance with Management Groups
A multinational corporation has 50 subscriptions across different departments (HR, IT, Finance). They need to enforce compliance policies (e.g., all resources must be in approved regions) and control costs. They use management groups to organize subscriptions into a hierarchy: Root -> Finance -> Subscriptions. They apply Azure Policy at the management group level to restrict allowed regions. ARM ensures that any resource creation request is evaluated against these policies. If a developer tries to create a VM in a non-approved region, ARM denies the request. This prevents non-compliance before it happens. Without ARM, enforcing such policies would require custom scripts and manual audits.
Scenario 2: Multi-Region Disaster Recovery
A healthcare company runs a critical application in two Azure regions (primary and secondary). They use ARM templates to deploy identical infrastructure in both regions, with different parameters (e.g., different storage account names). When a disaster strikes the primary region, they fail over to the secondary region by running the same ARM template (which is already deployed) and updating DNS. ARM's idempotency ensures no duplicate resources. The company can also use ARM templates to update both regions simultaneously, ensuring consistency. Common mistake: forgetting to update parameters when deploying to a different region, leading to naming conflicts. ARM will fail the deployment, preventing a partial state.
Scenario 3: DevOps CI/CD Pipeline
A software company uses Azure DevOps to deploy a microservices application. Their pipeline includes an ARM template deployment task that provisions a resource group, a container registry, and an AKS cluster. The template is stored in Git, and any change triggers a new deployment. ARM's incremental deployment mode ensures that only changed resources are updated. If the pipeline fails mid-deployment, ARM's rollback feature (if enabled) reverts changes. The team can also use 'what-if' operations to preview changes before deployment. Without ARM, they would need custom scripts to handle dependencies and state, leading to fragile pipelines.
Objective Code and Weight
This section aligns with AZ-900 objective 'Describe Azure Resource Manager' (part of 'Describe Azure architecture and services', which is 15-20% of the exam). Specific sub-objectives: 'Describe the Azure Resource Manager (ARM) and ARM templates', 'Describe resource groups', 'Describe management groups'.
Common Wrong Answers and Why Candidates Choose Them
'ARM is a resource like a VM.' – Wrong. ARM is the management layer, not a resource. Candidates confuse the tool with the object it manages.
'A resource group can contain resources from multiple subscriptions.' – Wrong. A resource group is scoped to a single subscription. Candidates think it's like a folder that can span subscriptions.
'ARM templates are mandatory for deploying resources.' – Wrong. You can deploy via portal, CLI, PowerShell, SDK – templates are optional but recommended for repeatability.
'Tags are automatically inherited from the resource group.' – Wrong. Tags are not inherited by default; you must use Azure Policy to enforce inheritance.
Specific Terms and Values
Management group depth limit: Up to 6 levels (not including root).
Deployment history limit: 800 deployments per resource group (older ones are deleted).
Resource group region: The resource group itself has a region (where the metadata is stored), but resources can be in any region.
ARM template parameters: Used to pass values like names, SKUs, locations.
Incremental vs. Complete mode: Incremental adds/updates resources; Complete deletes resources not in the template (use with caution).
Edge Cases and Tricky Distinctions
Resource group deletion: Deleting a resource group deletes all resources inside it. This is a common exam scenario – be aware that you cannot recover a deleted resource group.
Move resources: You can move a resource to another resource group or subscription, but the resource must support the move (e.g., VMs can be moved, but some like Azure SQL databases have restrictions).
Locking: You can add a 'ReadOnly' or 'Delete' lock at the resource group level to prevent accidental changes. Locks override RBAC permissions.
Memory Trick: 'RAMP' – Resource group, ARM template, Management group, Policy. Remember that ARM orchestrates all four. For exam questions about 'what controls permissions?', think RBAC; for 'what enforces rules?', think Azure Policy.
ARM is the deployment and management service for Azure – it is not a resource itself.
Resource groups are logical containers within a single subscription; they can contain resources from multiple regions.
ARM templates are JSON (or Bicep) files that declaratively define infrastructure; they are idempotent and support incremental or complete deployment modes.
Management groups organize subscriptions for governance; the hierarchy supports up to 6 levels.
RBAC roles can be assigned at management group, subscription, resource group, or resource scope.
Tags are key-value pairs for categorization; they are not inherited by default.
ARM enforces Azure Policy and locks before resource creation.
Deployment history is stored for up to 800 deployments per resource group.
These come up on the exam all the time. Here's how to tell them apart.
Resource Group
Logical container for resources within a single subscription
Used to group resources with the same lifecycle
Can be deleted, which deletes all resources inside
Supports RBAC and policies at the resource group level
Has a region (where metadata is stored)
Management Group
Logical container for subscriptions, not resources
Used to apply governance and compliance across multiple subscriptions
Cannot be deleted if it contains subscriptions
Supports RBAC and policies at the management group level
Has no region; it is a global construct
Mistake
ARM is a physical server or a resource you can create.
Correct
ARM is a management service, not a resource. You do not 'create' an ARM; you use it to create other resources.
Mistake
A resource group can span multiple subscriptions.
Correct
A resource group is contained within a single subscription. To manage resources across subscriptions, use management groups.
Mistake
ARM templates are the only way to deploy resources.
Correct
ARM templates are one method. You can also use the portal, CLI, PowerShell, SDKs, and third-party tools like Terraform (via ARM API).
Mistake
Tags applied to a resource group are automatically applied to all resources inside it.
Correct
Tags are not inherited. You must apply tags explicitly or use Azure Policy to enforce tagging.
Mistake
ARM templates are only for initial deployment; you cannot update resources with them.
Correct
ARM templates are idempotent and can be used for updates. You modify the template and redeploy – ARM applies changes incrementally.
ARM (Azure Resource Manager) is the current deployment model, while ASM (Azure Service Management) is the classic model. ARM supports declarative templates, resource groups, RBAC, and tags. ASM is older, lacks these features, and is being phased out. For AZ-900, focus on ARM; classic deployments are legacy.
Yes, you can move resources between resource groups or subscriptions, but the resource must support the move operation (most do). However, some resources like Azure SQL databases have restrictions. Use the 'Move' action in the portal or CLI. Note that moving does not change the resource's region.
Deleting a resource group deletes all resources within it. This is irreversible. Azure prompts for confirmation. It is a common exam scenario: you must be careful when deleting resource groups. Always ensure you have backups or the resources are no longer needed.
Parameters are inputs to an ARM template that allow customization without changing the template. For example, you can have a parameter for the VM size or storage account name. Parameters are defined in the `parameters` section of the template and can have default values. During deployment, you provide parameter values via a separate parameters file or inline.
Incremental mode (default) adds new resources and updates existing ones without deleting anything not in the template. Complete mode deletes resources that exist in the resource group but are not defined in the template. Complete mode is risky and should be used with caution, often reserved for greenfield deployments.
Yes, Terraform can deploy Azure resources using the AzureRM provider, which interacts with the ARM API. However, Terraform uses its own state file and HCL syntax, not ARM templates. Both are infrastructure-as-code tools, but ARM templates are native to Azure.
A resource provider is a service that supplies Azure resources. For example, Microsoft.Compute provides VMs, Microsoft.Storage provides storage accounts. Each resource provider has a namespace and a set of resource types. You must register a resource provider in your subscription before you can create resources of that type (though many are auto-registered).
You've just covered Azure Resource Manager (ARM) — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?