This chapter covers Azure Resource Manager — the deployment and management layer underneath every Azure resource. AZ-900 tests this under objective 2.1, and it's foundational: nearly every other Azure Architecture and Services topic assumes you understand how ARM organizes and manages resources.
Jump to a section
A simple way to picture Azure Resource Manager (ARM)
Imagine a large office building where every request — deliveries, maintenance, visitor access, room bookings — has to go through a single front desk, no matter which floor or department it's for. The front desk doesn't do the work itself, but it logs every request, checks whether the requester is allowed to make it, and routes it to the right team. Because everything passes through the same front desk, the building manager can see a consistent record of everything happening, apply the same security rules everywhere, and even set up standing instructions ("always route deliveries for Floor 4 this way") instead of explaining the process to every visitor individually. Azure Resource Manager (ARM) is that front desk for Azure: every request to create, change, or delete anything — whether it comes from the Azure portal, the CLI, PowerShell, or a script — passes through the same layer, which checks permissions and then carries out the request consistently.
What ARM is and the problem it solves
Azure Resource Manager is the management layer that receives every request to create, update, or delete an Azure resource, regardless of which tool sent that request — portal, CLI, PowerShell, REST API, or an SDK. Before ARM existed, different tools could behave inconsistently. ARM gives every interface the same consistent behavior, the same permission checks, and the same auditing.
How it works
Every resource in Azure belongs to a resource group — a logical container used to manage related resources together (for example, deploying, monitoring, or deleting them as a set). Resource groups themselves live inside a subscription, and subscriptions can be organized under management groups for larger organizations. When you make a request — through any tool — it goes to ARM, which checks your permissions (via role-based access control) and then carries out the operation against the relevant resource provider (the underlying service responsible for that resource type, such as the compute or storage resource provider).
Key components
Resource groups: logical containers for related resources, sharing a lifecycle for management purposes.
Resource providers: the services behind each resource type (e.g. Microsoft.Compute, Microsoft.Storage) that actually create and manage resources.
ARM templates / Bicep: declarative files describing what resources should exist, letting you deploy consistently and repeatably rather than clicking through the portal each time.
Tags: metadata you can attach to resources or resource groups for organization, cost tracking, or automation.
Resource locks: settings that prevent accidental deletion or modification of critical resources.
An important nuance: resource group location vs. resource location
A resource group's location setting is often misunderstood — it only determines where the resource group's own metadata is stored. The individual resources inside a resource group can be deployed to a different region than the resource group itself. This is a genuinely useful distinction and a common point of confusion.
Portal and CLI touchpoints
az group create --name myResourceGroup --location eastus
az deployment group create --resource-group myResourceGroup --template-file main.bicepThe portal exposes the same operations through "Create a resource," "Deploy a custom template," and resource group management pages.
Create a resource group
A resource group is created first, giving you a container to organize related resources. Its location setting is metadata storage for the group itself, not a restriction on where the resources inside it must live.
Deploy resources into the group
Resources are deployed into the resource group — through the portal, CLI, PowerShell, or a declarative template. ARM validates the request and hands it to the appropriate resource provider.
Apply access control and tags
Role-based access control can be applied at the subscription, resource group, or individual resource level. Tags can be added for cost tracking or organization, and locks can be applied to prevent accidental deletion.
Manage resources as a group
Because related resources share a resource group, common operations like monitoring, applying policy, or deleting an entire environment can be done at the group level instead of one resource at a time.
A software team building a new application creates a resource group per environment — one for development, one for staging, one for production — so each environment's resources can be managed, monitored, and torn down independently without affecting the others. When the development environment is no longer needed, deleting that one resource group removes everything inside it in one operation.
A separate scenario: a company centralizes its infrastructure deployment using ARM templates (or Bicep) checked into source control, so every environment is created the same repeatable way instead of being clicked together by hand — reducing configuration drift between environments and making changes reviewable before they're applied. Teams that skip this and rely purely on manual portal clicks often end up with environments that have quietly diverged from each other over time.
Objective 2.1 expects candidates to understand what Azure Resource Manager is, how resource groups organize resources, and how requests flow through ARM regardless of the tool used.
A common wrong answer is assuming a resource group's location restricts where its resources can be deployed — it doesn't; the location is just where the group's own metadata lives. Another common trap is confusing a resource group with a subscription, or assuming management groups are required (they're optional and used mainly by larger organizations with multiple subscriptions).
On moving resources between regions specifically: for most Azure resource types, the region set at creation is not something you can simply edit afterward. Moving a resource to a different region typically means creating an equivalent resource in the target region and decommissioning the original — though the exact approach depends on the specific resource type, and some services do offer dedicated migration tooling. Rather than treating this as one universal rule, the exam-safe takeaway is that resource location is generally fixed at creation and changing it is service-specific, not something covered by a single blanket method.
Stable terms: Resource Group, Resource Provider, ARM Template, Subscription, Management Group.
Azure Resource Manager is the single layer every management request passes through, regardless of whether it comes from the portal, CLI, PowerShell, or an SDK.
A resource group's location stores only the group's own metadata — resources inside it can live in a different region.
For most resource types, the region is fixed at creation; moving to a new region is generally a create-and-decommission process specific to that service, not a universal one-step operation.
Management groups are an optional layer above subscriptions, mainly relevant for larger organizations.
ARM templates and Bicep let you deploy resources declaratively and repeatably, rather than reconstructing an environment manually each time.
These come up on the exam all the time. Here's how to tell them apart.
ARM Templates / Bicep (declarative)
Describes the desired end state in a file
Repeatable — same file produces the same result
Reviewable and version-controllable before deployment
Better for consistent multi-environment setups
Portal / CLI clicks (imperative)
Performs actions step by step, in the moment
Faster for a one-off change or quick test
Harder to reproduce exactly the same way twice
No file artifact to review or track changes to
Mistake
A resource group's location determines where its resources must be deployed.
Correct
The resource group's location only stores the group's own metadata. Resources inside it can be deployed to a different region than the group itself.
Mistake
You can freely move any resource to a different region by editing a setting.
Correct
For most resource types, the region is fixed once the resource is created. Moving to a different region generally means creating an equivalent resource in the new region and decommissioning the old one — the specific approach and any available migration tooling depends on the resource type, so this isn't a single universal rule to memorize.
Mistake
Management groups are required for every Azure account.
Correct
Management groups are an optional organizational layer, mainly useful for larger organizations managing multiple subscriptions together.
Mistake
ARM templates and the Azure portal produce different results.
Correct
Both go through the same Azure Resource Manager layer — the tool used doesn't change how the request is ultimately processed.
A resource group is a logical container for related Azure resources — it doesn't do anything on its own, but it lets you manage, monitor, and delete a set of resources together instead of one at a time. Every resource belongs to exactly one resource group.
For most resource types, the region is fixed once created, so moving to a new region typically means creating an equivalent resource in the target region and retiring the original. Some services provide specific migration tooling; this varies by resource type, so check that service's documentation rather than assuming one method applies everywhere.
No — the resource group's location only determines where the group's metadata is stored. The virtual machine (or any other resource) inside it can be deployed to any supported region you choose, independent of the resource group's location.
No, management groups are optional. They exist to help larger organizations apply policies and access control across multiple subscriptions at once. A single-subscription account can use resource groups without ever needing a management group.
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?