Azure Resource Manager (ARM)
A beginner-friendly guide to the front desk of Azure: how every click, command, and template becomes a real resource, how deployments work, how access and rules are checked, and how to use ARM safely.
Every time you create a virtual machine in the Azure portal, run a command in a terminal, or press a button in an automation pipeline, something quietly receives your request, checks that you are allowed to make it, checks that it follows the rules, and then asks the correct Azure service to do the work. That quiet helper is called Azure Resource Manager, usually shortened to ARM. It is the single doorway through which almost all management of Azure resources passes.
This guide explains ARM from the ground up. You need no earlier knowledge of cloud tools. Every new word is explained when it first appears, with an everyday comparison and a practical example. By the end you will understand what ARM does, how a request travels through it, how templates describe whole environments, how deployments behave, how access and policy are enforced, and how to use all of this safely in real projects.
Microsoft keeps improving ARM and the tools around it, and some older tools are retired over time. This guide teaches the lasting ideas and uses typical figures as examples. Before relying on a specific limit, feature, or tool status, confirm it in Microsoft’s official Azure documentation.
1The Big Idea: ARM Is Azure’s Front Desk
Azure Resource Manager is the deployment and management layer of Azure. You talk to it, and it talks to everything else.
The simple definition
A resource in Azure is anything you can create and manage, such as a virtual machine, a database, a storage account, or a network. Azure Resource Manager is the service that lets you create, update, organise, secure, and delete those resources in a consistent way. Whatever tool you use, whether the web portal, a command-line program, a programming library, or an automation system, the request is sent to ARM first.
ARM does not build a virtual machine itself. It is a coordinator. It receives your request, confirms your identity, checks your permissions, checks the rules that apply, and then forwards the work to the specialised service that knows how to build that kind of resource. When the work finishes, ARM reports the result back to you and records what happened.
Think of the front desk of a large hotel. Guests can ask for a room, a taxi, a meal, or a repair. They do not walk into the kitchen or the garage themselves. The front desk checks who they are, whether the request is allowed, and then tells the right department what to do. At the end, the desk confirms the result and writes it in the logbook. ARM is that front desk for the entire Azure hotel.
What ARM gives you
One way to manage everything
Every kind of resource is created and managed through the same pattern, so the skills you learn for one apply to all.
Central checks
Permissions, policies, and locks are enforced in one place, so they cannot be skipped by using a different tool.
Repeatable deployments
You can describe a whole environment in a file and deploy it again and again with the same result.
Organisation
Resource groups, tags, and the management hierarchy are all provided through ARM.
ARM is about the management of resources, not the use of them. Creating a database goes through ARM. Reading rows from that database does not, because that traffic goes straight to the database service.
2Why ARM Exists: A Short History and Four Good Reasons
ARM was created to fix real problems that appeared in Azure’s first years.
The old way and the new way
Azure’s earliest management model, now often called the classic model, treated each resource separately. A virtual machine, its network, and its storage were managed with different interfaces, there was no folder to hold related items together, and there was no common way to apply permissions or labels. Around the middle of the 2010s, Microsoft introduced Azure Resource Manager as a new model, and it became the standard way to work. The classic model has been retired for most services, so today almost everything you do uses ARM.
Classic model
Resources managed one by one, with limited grouping and limited access control.
Resource Manager model
Resources placed in groups, managed through one consistent layer, controlled by roles, and deployable from templates.
Everything goes through ARM
New Azure services launch only in the ARM model, and tools such as Bicep and Terraform are built on top of it.
The four problems it solved
Managing related things together
Applications are made of many parts. ARM lets you create, update, and delete the parts as one unit through resource groups.
Repeating setups reliably
Clicking through a portal is slow and error-prone. Templates let you describe an environment once and reproduce it exactly.
Controlling access
Role-based access control let organisations decide exactly who may do what, at every level of the structure.
Knowing who did what
Every management action is recorded, which supports audits, troubleshooting, and security investigations.
Imagine a company that once let every department hire, spend, and give out keys independently. Over time, nobody knew who had which key, costs were unclear, and moving offices meant redoing everything by hand. A central office with standard forms, a staff register, and a clear logbook fixes all of this. ARM is that central office for Azure.
3Core Concepts: The Words You Need
ARM has a small vocabulary. Learn these terms once and every later chapter becomes easier.
| Term | What it means | Everyday comparison |
|---|---|---|
| Resource | A manageable item in Azure, such as a virtual machine or a database | One piece of equipment |
| Resource group | A logical folder that holds related resources | A labelled box |
| Resource provider | A service that supplies a family of resource types, such as compute, storage, or networking | A specialised department |
| Resource type | The kind of resource a provider offers, for example a virtual machine or a disk | A product category |
| API version | A dated edition of the rules for talking to a resource type | An edition of a form |
| Scope | The level at which an action or rule applies | An address level |
| Template | A file that describes the resources you want, not the steps to build them | A building blueprint |
| Deployment | One run of a template or request set against ARM | One construction job |
| Declarative | Describing the desired result rather than the steps | Ordering a dish by name |
| Idempotent | Running the same thing many times gives the same final result | Pressing a lift button twice |
Declarative versus imperative
These two words are among the most important in modern cloud work. An imperative approach lists the steps to follow: “create a network, then create a disk, then create a machine, then attach the disk”. A declarative approach describes the end state: “I want a network, a disk, and a machine with the disk attached”. ARM templates are declarative. ARM works out the steps, the order, and which parts already exist.
An imperative instruction is a recipe: chop, fry, boil, serve. A declarative instruction is a restaurant order: “one vegetable biryani”. The restaurant decides how to make it, and if the dish is already on the table, it does not cook a second one. ARM works like the restaurant.
The word idempotent sounds scary, but the idea is friendly: you can run a deployment again without fear. If everything already exists as described, nothing changes. If something is missing or different, ARM fixes only that part.
4Many Tools, One Doorway
The portal, the command line, programming libraries, and automation tools all speak to the same ARM service.
flowchart LR
P["Azure Portal"] --> A
C["Command-line tools: Azure CLI, PowerShell"] --> A
S["SDKs for languages such as Python, .NET, Java, JavaScript"] --> A
R["Direct REST API calls"] --> A
T["Templates and Bicep"] --> A
X["Terraform and other tools"] --> A
A["Azure Resource Manager: one consistent API"]
A --> V["Resource providers: Compute, Storage, Network, Web, Database"]
What each tool is good for
| Tool | Style | Best for |
|---|---|---|
| Azure portal | Point and click in a web page | Learning, exploring, and one-off tasks |
| Azure CLI and PowerShell | Typed commands, run in a terminal or script | Quick automation and scripting |
| SDKs | Calls from inside your own programs | Applications that manage Azure themselves |
| REST API | Raw web requests | Custom tools and understanding what happens underneath |
| ARM templates and Bicep | Declarative files | Repeatable, reviewed, version-controlled environments |
| Terraform and similar | Declarative files in another language | Teams working across several clouds |
A bank can be reached through a branch counter, a phone app, a cash machine, or a cheque, but all of them lead to the same central accounts and the same security checks. You may choose the channel that suits you, yet the rules and records are identical. The same is true for the tools that reach ARM.
Because every tool goes through ARM, a policy or lock cannot be bypassed by switching to a different tool. It also means the activity log shows actions from every tool in one place, with the identity that made them.
5Architecture: The Parts Inside the Front Desk
ARM is built from a few cooperating parts, each with a clear job.
flowchart TB
U["Caller: person, script, or application"] --> FE["ARM front end: receives and validates requests"]
FE --> AU["Authentication: Microsoft Entra ID"]
FE --> AZ["Authorization: role-based access control"]
FE --> LK["Resource locks"]
FE --> PL["Azure Policy evaluation"]
FE --> RT["Router: finds the right resource provider"]
RT --> RP1["Microsoft.Compute"]
RT --> RP2["Microsoft.Storage"]
RT --> RP3["Microsoft.Network"]
RT --> RP4["Many other providers"]
FE --> LG["Activity log: records the action"]
The parts and their jobs
Front end
Accepts requests, checks that they are well formed, and manages the conversation with the caller, including long-running operations.
Authentication
Microsoft Entra ID proves who is calling, using sign-in tokens issued to people and applications.
Authorization
Role-based access control decides whether that identity is allowed to perform this action at this scope.
Policy and locks
Azure Policy checks that the request follows your rules. Locks protect important resources from deletion or change.
Router
Finds the resource provider that owns the resource type and forwards the request to it.
Activity log
Writes down what was requested, by whom, and with what outcome, so there is an audit trail.
An airport works in a similar way. A check-in desk takes your booking, a passport officer proves who you are, security decides whether you may carry certain things, and a gate agent sends you down the right corridor. A record of your journey is kept at every step. The terminal as a whole is ARM.
6Resource Providers and Resource Types
Resource providers are the specialists that actually do the work behind ARM.
What a resource provider is
A resource provider is a service that offers one family of resource types and knows how to create, update, and delete them. Each provider has a name that starts with “Microsoft”, followed by a dot and a word that says what it does. The compute provider handles virtual machines, the storage provider handles storage accounts, the network provider handles virtual networks and load balancers, and the web provider handles web apps. A resource type is a specific kind of resource within a provider, such as a virtual machine or a disk.
| Provider (family) | Examples of what it manages |
|---|---|
| Compute | Virtual machines, disks, availability sets, scale sets |
| Storage | Storage accounts, blob containers, file shares |
| Network | Virtual networks, load balancers, public addresses, security groups |
| Web | App Service plans and web apps |
| SQL and database providers | Database servers and databases |
| Key Vault | Vaults for secrets, keys, and certificates |
| Authorization | Role assignments, locks, and policy assignments |
Registration
Before you can create a resource of a certain family in a subscription, the provider must be registered for that subscription. Registration simply tells Azure that this subscription may use that family of services. Most common providers are registered automatically when you create your first resource of that kind, but sometimes you must do it yourself, and an error that says a provider is “not registered” is the clue.
API versions
Each resource type is described by an API version, a dated edition of the rules for creating and managing it. When a provider adds new options, it releases a new API version, and old versions keep working for a long time. In a template you choose the version you are using, and the properties you may set depend on it. Newer versions give access to newer features.
A resource provider is like a specialised department in a government office: one for passports, one for driving licences, one for taxes. Registration is like opening a file for yourself in a department before you can use its services. An API version is the edition of the application form that department currently uses.
If a template that worked last year fails today with a message about an unsupported property, check the API version. A property may exist only in a newer version, or a very old version may no longer accept something you try to set.
7Resource IDs: Every Item Has an Address
ARM gives every resource a unique, readable address that describes exactly where it sits.
A resource ID is a long text address that spells out the full path to a resource. It contains, in order, the subscription, the resource group, the provider, the resource type, and the resource name. If you read it from left to right, it tells you the whole story of where the resource lives.
Subscription
The unique identifier of the subscription that holds the resource.
Resource group
The name of the group that contains it.
Provider and type
Which family and kind of resource it is.
Name
The name you gave it, unique within its group and type.
A resource ID is like a full postal address: country, state, city, street, and flat number. No two homes share the same complete address, and anyone can tell exactly where to go by reading it. Because the ID is unique, role assignments, locks, and policies can point at one exact resource without confusion.
Why resource IDs matter in practice
- Linking resources: one resource often refers to another by its ID, for example a virtual machine pointing at its network card.
- Assigning access: role assignments are attached to the ID of a scope, such as a resource group.
- Reading logs: the activity log and error messages show IDs, so you can find the exact resource involved.
- Querying: tools such as Azure Resource Graph use IDs to find and join information across subscriptions.
A name alone is not enough, because many groups can contain resources with the same name. When you need to be exact, for example in a script that deletes something, use the full ID, not only the name.
8How a Request Travels Through ARM
Follow one request step by step, from your keyboard to a finished resource.
sequenceDiagram
participant U as You or your tool
participant E as Microsoft Entra ID
participant A as Azure Resource Manager
participant K as Access, Lock and Policy checks
participant P as Resource Provider
U->>E: Sign in and ask for a token
E-->>U: Token that proves identity
U->>A: Request to create a resource, with the token
A->>E: Is this token valid
E-->>A: Yes
A->>K: Is this action allowed, unlocked, and within policy
K-->>A: Approved
A->>P: Create the resource
P-->>A: Accepted, work in progress
A-->>U: Request accepted, check status later
P-->>A: Work finished
A-->>U: Final result available
The steps in plain words
Sign in
You prove who you are to Microsoft Entra ID, which gives you a short-lived token, like a temporary visitor pass.
Send the request
Your tool sends the request to ARM together with the token, saying what you want and where.
Check the token
ARM confirms with Entra ID that the token is genuine and has not expired.
Check access, locks, and policy
ARM looks at all role assignments that reach the target scope, any locks, and all policies from the management group down.
Hand over to the provider
ARM sends the request to the correct resource provider in the correct region.
Do the work
The provider builds the resource. Slow work continues in the background.
Report and record
ARM returns the result and writes an entry in the activity log.
Knowing the order helps you diagnose problems. An authentication error means the token is missing or invalid. An authorization error means a role is missing. A policy error names the rule that blocked you. A provider error comes from the specific service, such as running out of quota.
9Slow Work and Status: Long-Running Operations
Creating a database or a virtual machine can take minutes. ARM handles this with a polite “we have started, come back and check” approach.
Why requests do not simply wait
Some actions finish in a blink, such as adding a tag. Others, such as building a virtual machine or a database, take many minutes. Keeping a connection open that long would be fragile. So ARM accepts the request quickly, replies with an acknowledgement that includes a way to check progress, and lets the work continue in the background. This pattern is called an asynchronous operation.
Accepted
ARM confirms that the request is valid and has been passed on. It gives you a status address.
In progress
The resource provider builds the resource. Asking the status address returns a state such as “running”.
Succeeded or failed
The final state, with details. Tools that “wait” for a deployment are really checking this status again and again.
Ordering a custom cake works this way. The shop gives you a receipt immediately, saying the order is accepted. You do not stand at the counter for hours. You can call and ask “is it ready?” using the receipt number, and the shop tells you whether it is baking, ready, or has run into a problem.
Eventual consistency
Azure is a huge distributed system, so a change made in one place can take a short moment to appear everywhere. You might create a resource and find that a list does not show it for a few seconds, or that a freshly assigned role takes a short while to take effect. This is called eventual consistency. The practical advice is to be patient, to build scripts that check and retry, and to avoid assuming that “created” always means “visible everywhere” the instant the call returns.
A script that creates a role assignment and then immediately tries to use it may fail once and succeed a minute later. If a failure seems strange and then disappears, suspect timing before suspecting a mistake.
10Control Plane and Data Plane
Two words explain what ARM covers and what it does not. They show up in almost every Azure discussion.
The two planes
The control plane is the layer where you manage resources: create them, change settings, delete them, give people access. ARM is the control plane for Azure. The data plane is the layer where you use the resources: read a file from storage, run a query on a database, send a message to a queue. Data plane requests usually go straight to the service, not through ARM.
| Question | Control plane (through ARM) | Data plane (to the service) |
|---|---|---|
| Example: storage | Create a storage account, change its redundancy | Upload or download a file |
| Example: database | Create a database server, set firewall rules | Run a query, insert a row |
| Example: key vault | Create a vault, set who can use it | Read a secret value |
| Who checks permission | Azure role-based access control through ARM | The service itself, sometimes using roles and sometimes its own keys |
| Logged in | Activity log | Resource logs of that service |
In a library, the librarian’s office decides who may join, which shelves exist, and the borrowing rules. That is the control plane. Reading a book on a shelf is the data plane. A person may be allowed to manage the library without being allowed to read the private archive, and the other way round.
Why the difference matters
- Permissions are separate. Being the Owner of a storage account lets you manage it but does not automatically let you read its files, unless you also hold a data role.
- Outages can differ. A problem in the control plane may stop you from creating or changing resources, while existing resources keep serving users through the data plane.
- Logs differ. The activity log shows management actions, while each service keeps its own logs of data actions.
Because the planes are separate, well-designed applications keep running even if management operations are slow or unavailable. Avoid designs where a running application needs to call ARM for every user request. Use the control plane to set things up and change them, not to serve traffic.
11Templates: Describing an Environment in a File
An ARM template is a blueprint. You write what you want, and ARM builds it.
What a template is
An ARM template is a text file, written in a structured format called JSON, that describes the resources you want to exist. It does not list steps. It lists the end result: a network of this size, a storage account with these settings, a web app connected to that database. You hand the file to ARM as a deployment, and ARM creates whatever is missing and adjusts whatever differs.
An architect’s blueprint shows what the house looks like, not which worker lays which brick on which day. Different builders can use the same blueprint and produce the same house. A template is the blueprint, ARM is the building contractor, and the finished environment is the house.
The parts of a template
| Part | Purpose | Everyday comparison |
|---|---|---|
| Schema and version | Tells tools which template language edition the file uses | The title line of a form |
| Parameters | Values supplied at deployment time, such as a name or a size | Blanks to fill in on the form |
| Variables | Values worked out inside the template and reused | A calculated field |
| Functions | Small reusable pieces of logic, plus many built-in helpers | Calculator buttons |
| Resources | The things to create or update | The list of rooms in the blueprint |
| Outputs | Values handed back after the deployment finishes | The receipt |
Why parameters matter
A good template is written once and used many times. The same file can build a small test environment and a large production environment, because the differences, such as size, name, and region, are parameters. You keep one blueprint and many small files of values, one for each environment. This reduces mistakes, because production and test differ only in the values you choose to change.
Give parameters sensible defaults, short descriptions, and allowed-value lists where possible. A well-described parameter is documentation that travels with the template and stops a tired person at midnight from typing something invalid.
12Bicep: A Friendlier Way to Write Templates
Bicep is a simpler language that turns into an ARM template behind the scenes.
The problem with raw templates
Writing templates directly in JSON works, but the files become long, hard to read, and full of punctuation. Microsoft created Bicep to solve this. Bicep is a domain-specific language, which means a small language built for one job: describing Azure resources. You write Bicep files, and a tool translates them into standard ARM templates before they are deployed. ARM itself still receives the same kind of template as before, so nothing about the control plane changes.
Why people like Bicep
- Shorter and easier to read than the raw format
- Resources can refer to each other by simple names
- Dependencies are often worked out automatically
- Modules make reuse natural
- Support for new Azure features is typically available quickly
- Good editor help, such as hints and error checks while you type
Things to keep in mind
- It only targets Azure, unlike tools that span several clouds
- Teams must learn another small language
- State is not stored separately, so you rely on ARM itself as the source of truth
- Very old templates may need conversion work
Bicep is like writing a letter in your own language and having a professional translator turn it into the formal legal language the court requires. The court, which is ARM, only sees the formal version, but you enjoy writing in the comfortable one.
Because Bicep compiles to a standard template, existing templates still work, and you can convert between the two. Most teams starting fresh on Azure today choose Bicep or Terraform rather than writing raw templates by hand.
13Scopes: Where a Deployment Applies
A deployment always targets a level of the Azure hierarchy. Choosing the right level matters.
Azure organises things in layers. At the top are tenants and management groups, below them subscriptions, below those resource groups, and inside those the resources. A scope is the level at which something is applied. A deployment can target any of four scopes.
flowchart TB
T["Tenant"] --> M["Management group"]
M --> S["Subscription"]
S --> G["Resource group"]
G --> R["Resource"]
| Scope | Typical uses |
|---|---|
| Resource group | The everyday case: create the resources of an application |
| Subscription | Create resource groups, assign policies, set budgets, assign roles across the whole subscription |
| Management group | Apply policies and roles across many subscriptions, and organise subscriptions |
| Tenant | Organisation-wide setup, such as creating management groups |
A company rule can be announced to a single team, a whole department, a branch, or the entire company. A rule announced at the top applies everywhere below it. In the same way, a policy assigned at a management group reaches every subscription under it, while a template deployed to a resource group affects only that group.
Start deployments at the lowest scope that does the job. A smaller scope means a smaller blast radius if something goes wrong, and it needs smaller permissions.
14Deployment Modes: Incremental and Complete
When you deploy to a resource group, ARM must decide what to do with resources that are not in your template. The mode answers that.
Incremental mode
ARM adds or updates the resources in the template and leaves everything else in the group alone. This is the usual and safer choice.
Complete mode
ARM makes the group match the template exactly. Resources in the group that are not in the template can be deleted.
Incremental mode is like adding new furniture to a room according to a plan, leaving existing furniture where it is. Complete mode is like asking a cleaner to make the room look exactly like the picture, which means anything not in the picture gets taken out.
Complete mode can remove resources someone created by hand or another team added to the same group. Use it only on groups fully owned by one template, and preview the change first.
Preview before you commit: what-if
ARM can run a what-if operation. It compares your template with what already exists and shows what would be created, modified, or deleted, without changing anything. Reading a what-if result before deploying is one of the most valuable habits you can build, in the same way you reread an email before pressing send.
Validate
Check that the template is well formed and that the values make sense.
What-if
See the planned creates, changes, and deletes.
Review and approve
A person or a pipeline gate confirms the plan is what was intended.
Deploy
Apply the change for real.
15Dependencies, Order, and Parallel Work
ARM works out what must be built first and builds independent things at the same time.
Dependencies
Some resources need others to exist first. A virtual machine needs a network card, which needs a network. A dependency is exactly this “needs first” relationship. ARM reads the template, builds a map of the dependencies, and creates things in a safe order. Resources with no dependency between them are created in parallel, which makes large deployments much faster than doing one thing at a time.
flowchart LR
N["Virtual network"] --> I["Network interface"]
I --> V["Virtual machine"]
D["Disk"] --> V
K["Key vault"] --> A["Web app"]
When building a house, you cannot put up the roof before the walls, but the electrician and the plumber can work at the same time once the walls stand. ARM acts like a site manager who schedules everything that can safely happen together.
Loops and conditions
- Copy loops let a template create several similar resources, such as five identical servers or three storage accounts, without repeating text.
- Conditions let a resource be created only if a parameter says so, for example a monitoring tool only in production.
Over-specifying order slows deployments. Declare only the dependencies that really exist and let ARM parallelise the rest.
16Reuse: Modules, Template Specs, and Stacks
Big environments are built from small, reusable pieces, just like large programs.
Modules
A module is a template that another template calls. One module might build a standard storage account, and many projects reuse it.
Template specs
A template spec stores a template inside Azure itself as a resource, so teams can deploy approved templates and control who may use them.
Shared module registries
Organisations publish versioned modules to a registry so every team uses the same trusted building blocks.
Deployment stacks
A stack treats the resources from a deployment as one managed unit, which helps with updating, protecting, and cleaning up what the deployment created.
Modules are like standard building parts from a catalogue: doors, windows, and staircases. Instead of designing a new door for every house, builders pick the approved one. A template spec is the catalogue stored in the company warehouse, and a stack is the folder that remembers which parts went into which house, so a later renovation or demolition is orderly.
Azure has had a service called Blueprints for packaging environments with policies and roles. Microsoft has announced it is being retired in favour of newer options such as template specs and deployment stacks. Check current documentation before starting anything new on a retiring feature.
17The Life of a Deployment
Follow a template deployment from the moment you submit it until it is done.
flowchart TD
A["You submit a template with parameter values"] --> B["ARM validates syntax and values"]
B --> C["ARM checks access, locks, and policy"]
C --> D["ARM builds the dependency map"]
D --> E["Independent resources are sent to providers in parallel"]
E --> F["Providers create or update resources"]
F --> G{"All succeeded?"}
G -->|Yes| H["Outputs returned and history recorded"]
G -->|No| I["Failure recorded with error details"]
Deployment history
Every deployment leaves a record at its scope, showing its name, status, time, the resources touched, the inputs, and any errors. This history is a free logbook. When something breaks, it often answers the question “what changed recently?” within seconds. Azure keeps only a limited number of past deployments per scope and cleans older ones automatically, so treat the history as a short-term aid and keep your template files in version control as the permanent record.
What happens on failure
If one resource fails, ARM does not usually undo the others. Resources that were created successfully stay. This is why idempotency is so valuable: after fixing the cause, you run the same deployment again, and ARM creates only what is still missing. Some pipelines also use a rollback option that redeploys the last known good state, but a forward fix is usually simpler.
If a builder finishes the walls but the roof tiles are delayed, the walls do not get demolished. When the tiles arrive, the builder simply resumes with the roof. Re-running a deployment is this same resumption.
18Identity and Access: Who May Do What
ARM combines identity and roles so that every action is allowed only for the right person, at the right level.
Role-based access control
Role-based access control, often written RBAC, decides what an identity may do. It is built from three ideas: a security principal (who: a person, group, application, or managed identity), a role definition (what: a collection of allowed actions), and a scope (where: the subscription, group, or resource it applies to). Putting them together creates a role assignment.
| Common built-in role | What it allows |
|---|---|
| Owner | Everything, including giving access to others |
| Contributor | Create and manage resources, but not give access to others |
| Reader | View resources only |
| User Access Administrator | Manage who has access, but not the resources themselves |
In an office building, a key card has three facts: who holds it, which doors it opens, and which floors it works on. An Owner card opens everything and can print new cards. A Reader card lets you walk through and look, but touch nothing.
Machines need identities too
Programs and pipelines also call ARM. They should not use a person’s account or a password stored in a file. Azure offers two safer routes. A service principal is an identity for an application. A managed identity is an identity that Azure creates and looks after for a resource, so there is no password to store, leak, or rotate by hand. Where possible, choose managed identities, and for external pipelines use federated sign-in methods that avoid long-lived secrets.
Grant the smallest role at the smallest scope that does the job. A pipeline that only deploys to one resource group should have Contributor on that group, not Owner on the subscription. Privileged Identity Management can make powerful roles available only for a short approved time.
A new role assignment may take a short while to apply everywhere. If access seems denied right after you granted it, wait a few minutes before assuming a mistake.
19Governance: Policy, Locks, and Tags
Access says who may act. Governance says what is acceptable, whoever acts.
Azure Policy
Policies define conditions such as “only these regions” or “storage must use encryption”. They can deny a request, flag a resource as non-compliant, or add missing settings automatically.
Resource locks
A delete lock stops deletion. A read-only lock stops changes. Locks apply even to Owners until the lock is removed.
Tags
Tags are name and value labels, such as owner, project, or cost centre, used for searching, reporting, and cost tracking.
Activity log
A record of every management action, with who, what, when, and the result.
Think of a school. Key cards decide who can enter which room. School rules decide what may happen inside, such as no food in the lab. A padlock on the trophy cabinet protects precious items even from staff. Name labels on every item make it easy to know whose it is. Azure uses the same four tools together.
A person can be fully allowed by their role and still be stopped by a policy. That is intentional. Roles answer “may this person act?”, while policies answer “is this result allowed?”.
A read-only lock on a resource can block actions that seem harmless, because some read-looking operations actually write data underneath. Use locks deliberately, on critical items, and document where they are.
20Security Practices for ARM
Because ARM can create and destroy infrastructure, protecting access to it is a top priority.
The main risks
Stolen or over-powered identities
If an attacker obtains a highly privileged account or a leaked pipeline secret, they can create costly resources, read configuration, or delete everything. Strong sign-in, multi-factor authentication, and narrow roles reduce this risk.
Secrets inside templates
Passwords or keys typed into a template or its values file end up in version control and deployment history. Templates should refer to secrets stored safely rather than contain them.
Unreviewed changes
A small edit to a shared template can widen a firewall to the entire internet. Review and approval catch such changes before they spread.
Protective habits
- Use secure parameters for secret values so they are not shown in logs or history, and prefer references to a key vault.
- Require multi-factor sign-in for people with management access.
- Prefer managed and federated identities over stored passwords.
- Enforce policy to block risky settings, such as public storage or unapproved regions.
- Limit who can change policy and role assignments, since those are the keys to the castle.
- Send the activity log to a central place and set alerts for sensitive actions such as role changes and policy removal.
- Review changes in code review before deployment pipelines apply them.
The person holding the master key to a building must be vetted, must not copy the key onto a sticky note, and must have their every entry logged. Management access to Azure is the master key, and ARM is the lock it turns.
21Monitoring and Troubleshooting
When something goes wrong, ARM leaves clues in several places. Knowing where to look saves hours.
Where to look
| Place | What you learn |
|---|---|
| Deployment history | Which deployment ran, what it touched, and its error messages |
| Activity log | Who performed which management action, and whether it succeeded |
| Policy compliance view | Which resources break which rules |
| Resource health and service health | Whether the problem is yours or an Azure-side issue |
| Alerts on activity log events | Early warnings when sensitive actions occur |
Common error families
| Symptom | Likely meaning | First step |
|---|---|---|
| Authorization failed | Your identity lacks a needed role at that scope | Check the role assignments at the target scope |
| Request disallowed by policy | A policy blocked the request | Read which policy and which setting it names |
| Resource already exists or name taken | Names for some resources must be globally unique | Choose a more unique name |
| Provider not registered | The subscription has not enabled that family of services | Register the provider |
| Quota exceeded | The subscription or region reached a limit | Request more quota or choose another size or region |
| Scope is locked | A lock prevents the action | Find the lock and decide whether it should stay |
| Too many requests | Throttling, covered in the next chapter | Wait and retry more slowly |
A good detective starts with the logbook, the guest list, and the rule book. Deployment history is the logbook of jobs, the activity log is the guest list of who did what, and policy is the rule book. Reading them in order resolves most mysteries quickly.
Error messages from ARM often contain a nested detail section that names the true cause. The top line may be a generic “deployment failed”, while the real reason sits one level inside. Always expand the details.
22Throttling and Limits: ARM Protects Itself
ARM serves millions of requests, so it limits how fast any one caller can ask, and how many things you can create.
Throttling
Throttling means slowing down callers who send too many requests in a short time. When you exceed the allowed rate, ARM replies with a “too many requests” answer, commonly the number 429, and usually includes a hint saying how many seconds to wait before trying again. This protects the shared service so that one noisy script cannot spoil the experience for everyone else. The exact allowances vary by operation type, scope, and time, and Microsoft adjusts them, so treat any figure you read as an example and check the current documentation.
A busy restaurant kitchen accepts orders from many tables. If one table shouts out fifty orders a minute, the waiter politely says, “Please slow down, I will come back in a moment.” The hint about when to return is the retry instruction. It is not rudeness. It keeps the kitchen working for everybody.
How to behave well
- Respect the wait hint. When ARM says to wait, wait at least that long.
- Use growing delays. If it fails again, wait longer each time, with a little randomness so many clients do not retry at the same instant.
- Ask for less. Use one list call instead of hundreds of single lookups. Query many subscriptions at once with Azure Resource Graph.
- Avoid tight polling. Check the status of a long deployment every few seconds, not hundreds of times per second.
- Spread the load. Large automations can use several identities or stagger their work.
Limits
Azure also sets limits on how many items you may have: resources of certain types per group, deployments in the history, parameters in a template, template size, tags per resource, and role assignments per subscription. Many limits can be raised on request, while others are fixed. Limits matter when you design at scale, for example choosing many resource groups rather than putting thousands of resources into one.
Specific throttling and limit figures change over time. Before designing something near an edge, such as a huge template or a very large role assignment count, read the current limits page for each service involved.
23Reliability: What If ARM Has a Bad Day?
ARM is designed to be highly available, but wise architects still plan for the day management operations are slow.
How ARM is built for resilience
ARM runs as a distributed service across Azure regions, with copies in many places, so that the failure of one location does not stop management everywhere. Requests are routed to a healthy instance close to the target. Resource data is replicated, and the service is designed so that a problem in one region should have limited impact elsewhere. Even so, no service is perfect, and any cloud has had occasional periods when portal pages were slow or some operations failed.
What to design for
Keep running without the control plane
Applications should serve users using the data plane alone. They should not need to create or modify resources just to handle a user request.
Plan capacity ahead
Do not depend on creating new servers at the moment of a crisis. Scale rules and spare capacity should be configured in advance.
Make deployments retryable
Idempotent templates mean a failed run can simply be run again once service is restored.
Have a manual path
Know how to reach emergency access routes, and keep break-glass accounts documented and protected.
If the airline’s booking website goes down, planes that have already boarded still fly. The booking system is the control plane, the flight is the data plane. A well-run airline does not need the website at the very moment it is flying passengers.
When management calls fail unexpectedly across many subscriptions, check Azure service health before spending hours debugging your own templates. A shared problem looks different from a local one.
24Infrastructure as Code and CI/CD
The real power of ARM appears when templates live in version control and pipelines deploy them.
Infrastructure as code
Infrastructure as code means describing servers, networks, and databases in files, storing those files like program code, and creating real infrastructure from them. This gives you history, review, repeatability, and the ability to rebuild an entire environment from scratch. If someone asks “what changed last Tuesday?”, you read the commit log rather than guess.
flowchart LR
A["Developer edits template"] --> B["Pull request and review"]
B --> C["Automated checks: lint, validate"]
C --> D["What-if preview"]
D --> E{"Approval"}
E -->|Approved| F["Deploy to test"]
F --> G["Deploy to production"]
E -->|Rejected| A
The healthy workflow
Write and review
Changes are proposed as pull requests and read by another person.
Check automatically
A linter catches style problems, and validation catches broken templates early.
Preview
What-if output is attached to the review so approvers see what will change.
Deploy in stages
The same template goes to test first, then to production, with only parameter values differing.
Watch and detect drift
Drift means reality has moved away from the template, often because someone clicked in the portal. Regular what-if runs reveal it.
Treating infrastructure as code is like keeping a restaurant’s recipes in a locked, dated recipe book instead of in each cook’s head. Anyone can reproduce the dish, changes are discussed before the book is edited, and the history shows who changed the salt and why.
The portal is excellent for learning and investigating. For anything that must be repeatable, make the change in code. A manual change that is not in the template will be a surprise the next time the template runs, especially in complete mode.
25Choosing a Tool: ARM Templates, Bicep, or Terraform
All three end at ARM when they manage Azure. The choice is about how you write and track your plans.
| Question | Raw ARM templates | Bicep | Terraform |
|---|---|---|---|
| Language | JSON | Azure-specific, simpler syntax | HashiCorp Configuration Language |
| Clouds supported | Azure only | Azure only | Many clouds and services |
| Readability | Verbose | Concise | Concise |
| State tracking | None, Azure is the truth | None, Azure is the truth | Keeps its own state file that must be protected |
| New Azure features | Fast | Typically fast | Depends on provider updates |
| Preview of changes | What-if | What-if | Plan |
| Best fit | Existing estates and generated templates | Teams focused on Azure | Multi-cloud teams or those already using it |
When Bicep shines
- The organisation is committed to Azure
- No separate state file to store and secure
- Close alignment with Azure features and tooling
When Terraform shines
- The team manages several clouds and external services
- Experienced staff already know it
- You need state-based features, at the cost of protecting the state
Three travellers can reach the same city by train, bus, or car. The roads and the destination are the same, and ARM is the destination. Which vehicle is best depends on how far you are going, who travels with you, and what you already know how to drive.
The best tool is the one your team can use consistently, review properly, and operate safely. Do not mix three tools on the same resources without clear boundaries, because they can disagree about what the desired state is.
26Design Patterns That Work
Over the years, teams have found a handful of patterns that make ARM-based environments easier to run.
Lifecycle grouping
Put resources that are created, changed, and deleted together into the same resource group. When the project ends, one deletion cleans it all up.
One template, many environments
Keep a single set of templates and supply different parameter values for test, staging, and production.
Landing zone
Prepare a standard, governed place for new workloads, with management groups, policies, networks, and roles already set up before teams arrive.
Guardrails by policy
Block unsafe options centrally so that every team, using any tool, is held to the same standards.
Shared module library
Publish approved, versioned modules for common items such as storage accounts and networks, so teams assemble rather than invent.
Separate permissions by environment
Use different identities and scopes for test and production so a mistake in one cannot reach the other.
A landing zone is like a well-planned new housing estate. Roads, power, water, and fire rules are in place before the first family moves in. Residents build their own houses, but the neighbourhood standards keep everyone safe and everything connected.
27Anti-Patterns: Mistakes to Avoid
These are practices that look convenient today and cause pain later.
Clicking in production
Making changes by hand in the portal creates drift, leaves no review, and cannot be repeated. Make the change in the template and deploy it. Use the portal to look and learn, and keep manual changes to emergencies that are written back to code afterwards.
Everything in one resource group
Mixing unrelated projects in one group makes permissions, cleanup, and cost tracking messy, and increases the risk of a complete-mode deployment deleting things it should not.
Owner for everyone
Giving broad roles for convenience means one stolen account or one mistyped command can wreck an entire subscription. Use narrow roles at narrow scopes.
Secrets in templates or value files
Passwords and keys saved in files spread into version control, copies, and logs. Keep secrets in a vault and reference them, using secure parameters when a value must be passed.
Complete mode without a preview
Running complete mode on a shared group, without reading what-if output, is a classic way to delete things by accident.
One giant template
A single enormous file is slow to review, risky to change, and hard to reuse. Split it into modules with clear responsibilities.
Hard-coded values everywhere
Names, sizes, and regions typed directly into many places make environment differences error-prone. Use parameters and variables.
Ignoring tags and naming rules
Without consistent names and tags, nobody knows who owns what or what it costs, and old, forgotten resources keep billing quietly.
28Best Practices Checklist
Use this checklist as a quick review before running anything important.
| Area | Good habit |
|---|---|
| Structure | Group resources by shared lifecycle. Use management groups and subscriptions to separate environments and teams. |
| Code | Keep templates in version control. Review every change. Use modules and parameters. |
| Safety | Always run what-if. Prefer incremental mode. Use complete mode only on groups fully owned by one template. |
| Access | Least privilege at the narrowest scope. Managed identities for machines. Time-limited elevation for powerful roles. |
| Secrets | Never store them in templates. Use a vault and secure parameters. |
| Governance | Policies for guardrails. Locks on critical items. Tags for owner, project, and cost. |
| Naming | A consistent naming convention that shows type, workload, environment, and region. |
| Operations | Send the activity log to central monitoring. Alert on role, policy, and lock changes. |
| Resilience | Retry with backoff. Keep running without the control plane. Test rebuilding from code. |
| Hygiene | Remove unused resources, review role assignments regularly, and keep API versions reasonably current. |
Common beginner mistakes
- Assuming a successful command means the resource is instantly visible and usable everywhere.
- Forgetting that some names must be globally unique and then being surprised when a deployment fails.
- Deleting a resource group without checking everything inside it.
- Confusing management permission with data permission and wondering why an Owner cannot read files.
- Leaving test environments running and discovering the bill at month end.
- Assuming a policy is a bug when it is actually doing its job.
29Real-World Examples
Here is how organisations typically use ARM in everyday life. The names are illustrative.
A start-up launching a web product
A small team keeps one set of templates for a web app, a database, and monitoring. A new test environment for each feature branch is created in minutes and deleted when the branch is merged. Because the environment is code, a new developer can have a full copy running on day one.
A bank enforcing strict rules
A bank uses management groups to separate regulated and unregulated workloads. Policies, assigned at the top, deny public storage and restrict regions, and every team’s deployments pass through the same checks. Auditors read the activity log to confirm who changed what.
A retailer preparing for a sale
Before a big sale, the retailer deploys extra capacity from the same templates used all year, with larger sizes in the parameter file. After the sale, they redeploy with the normal values. Because the process is automatic, nobody has to remember a long list of manual steps.
A software company running many customers
A company hosting separate environments for each customer uses a module for the standard environment and creates one resource group per customer. Tags record the customer and the plan, so costs are reported accurately, and offboarding is a single deletion after approval.
A university running classroom labs
A teacher needs identical practice environments for a hundred students. A template creates each one in a separate group with a budget and an expiry tag, and a scheduled job deletes them at the end of term.
In each story, ARM provides the same foundation: a consistent way to describe, deploy, protect, and track resources. What differs is the amount of governance and automation wrapped around it.
30Mini Labs to Practise
Hands-on practice makes ideas stick. Try these on a free or sandbox subscription, and delete everything afterwards.
Watch ARM in the activity log
Create a resource group and a storage account in the portal. Then open the activity log and find the entries for each action. Notice who, what, and when are all recorded.
Export a template
From the resource group, use the export option to see a template of what you built. Compare the parameters and resources with what you chose in the portal.
Deploy twice
Deploy the same template twice into a new group. Observe that the second run changes nothing, proving idempotency.
Try what-if
Change one setting in your template and run what-if before deploying. Read the preview, then deploy and compare.
Meet a policy
Assign a built-in policy that allows only certain regions to a test group. Try to create a resource elsewhere and read the denial message.
Meet a lock
Add a delete lock to a test resource, then try to delete it. Remove the lock afterwards and note where you had to go to do so.
Role experiment
Give a test user the Reader role on a group. Confirm they can view but not change anything. Then explore what changes at Contributor.
Clean up
Delete the test resource groups and confirm that everything inside disappears together. This shows the value of grouping by lifecycle.
Choose the smallest and cheapest sizes, work in a throwaway group, and delete everything after each lab so you do not pay for forgotten resources.
31Glossary in Plain Words
A quick reference for the terms used in this guide.
| Term | Plain meaning |
|---|---|
| Azure Resource Manager | The management layer that receives, checks, and forwards requests to create and manage Azure resources |
| Resource | Any manageable item in Azure |
| Resource group | A logical container for related resources |
| Resource provider | A service that supplies and manages a family of resource types |
| Resource ID | The full unique address of a resource |
| Control plane | The management layer, where you create and configure resources |
| Data plane | The usage layer, where you read and write the data in a resource |
| Template | A declarative file that describes resources |
| Bicep | A simpler language that compiles to templates |
| Parameter | A value supplied when you deploy |
| Module | A reusable template called by another template |
| Deployment | One run of a template against a scope |
| Scope | The level at which something applies |
| Incremental mode | Add and update, leave the rest alone |
| Complete mode | Make the group match the template, removing extras |
| What-if | A preview of what a deployment would change |
| Idempotent | Safe to run repeatedly with the same final result |
| RBAC | Role-based access control, deciding who may do what |
| Managed identity | An Azure-managed identity for a resource with no password to handle |
| Policy | A rule about what settings and resources are acceptable |
| Lock | A protection against deletion or change |
| Tag | A name and value label on a resource |
| Throttling | Slowing down callers who send too many requests |
| Drift | When real infrastructure differs from its template |
| Eventual consistency | Changes taking a short time to appear everywhere |
32Frequently Asked Questions
33Summary and Key Takeaways
Azure Resource Manager is the front desk of Azure. Understanding it makes every other Azure topic easier.
You have seen that every management tool speaks to the same ARM service, which checks identity, access, locks, and policy before handing work to resource providers. You learned the vocabulary of resources, groups, providers, types, scopes, and IDs. You saw how templates and Bicep describe a desired result rather than steps, how deployments choose between incremental and complete modes, how what-if previews protect you, and how dependencies let ARM build in the right order and in parallel. You looked at governance, security, monitoring, throttling, reliability, and the habits that keep environments healthy over years.
Key Takeaways
- ARM is the single control plane for managing Azure resources. The portal, command-line tools, SDKs, templates, and Terraform all go through it.
- Every request is authenticated, authorised, checked against locks and policy, and recorded before a resource provider does the work.
- Templates and Bicep are declarative and idempotent: describe the end result, and re-run safely.
- Use incremental mode by default, run what-if before deploying, and treat complete mode with great care.
- Apply least privilege at the narrowest scope, use managed identities, and keep secrets in a vault rather than in templates.
- Use policies, locks, tags, and the activity log together for governance, safety, and accountability.
- Keep templates in version control and deploy through reviewed pipelines to avoid drift and mistakes.
- Design applications so they run without the control plane, and make management scripts retry politely when throttled.