2.3 Azure Resource Manager (ARM) Overview

What Azure Resource Manager Is

Azure Resource Manager (ARM) is the deployment and management service — the single control plane — for all of Azure. Whether you click in the Azure Portal, type an Azure CLI command, run an Azure PowerShell cmdlet, call the REST API, or use a language SDK, the instruction is converted into an identical request that is sent to the ARM endpoint. ARM is what makes the result the same no matter which tool you choose.

The exam's favorite one-liner: all Azure management tools talk to Azure through ARM. There is no "back door" to a resource that bypasses ARM.

The ARM request lifecycle

Every management action follows the same path:

1. You issue a request from Portal / CLI / PowerShell / REST / SDK.
2. ARM receives the request at its endpoint.
3. Authentication — ARM confirms who you are using Microsoft Entra ID (formerly Azure AD); the request carries a bearer token.
4. Authorization — ARM confirms what you may do by checking RBAC role assignments and evaluating Azure Policy (a policy can deny the action outright).
5. Routing — ARM forwards the validated request to the correct resource provider.
6. Execution — the resource provider performs the work (creates the VM, provisions the storage account).
7. Response — ARM returns the result and status to you.

Exam reflex: ARM authenticates and authorizes before anything is created. If a question asks "what stops an unauthorized create," the answer is ARM's authorization step (RBAC + Policy), not a firewall.

Resource providers

Each Azure service is delivered by a resource provider — a service that supplies a family of resource types. The type name format is provider/resourceType, e.g. Microsoft.Compute/virtualMachines.

A provider must be registered in a subscription before its types can be deployed. Many are auto-registered on first use, but a brand-new or rarely used service may need manual registration — a real-world gotcha worth knowing.

Infrastructure as code: ARM templates and Bicep

ARM enables declarative deployment: you describe the desired end state and ARM figures out how to reach it.

• ARM templates are JSON files listing the resources to deploy.
• Bicep is a cleaner domain-specific language that compiles ("transpiles") down to an ARM template — same engine, friendlier syntax.

Key properties the exam tests:

• Declarative — you state what, not how.
• Idempotent — deploying the same template repeatedly yields the same result; existing matching resources are left as-is rather than duplicated.
• Dependency-aware — ARM reads dependsOn relationships and deploys in the correct order.
• Parallel — independent resources deploy at the same time for speed.

Worked example

You submit a Bicep file that defines a virtual network, then a subnet inside it, then a VM with a NIC in that subnet. ARM deploys the virtual network first, the subnet next, and the VM last because of the dependency chain — even though you listed them in any order. Re-running the same file changes nothing because the deployment is idempotent.

Cross-cutting ARM features

• RBAC — fine-grained permissions at any scope in the hierarchy.
• Tags — key/value metadata for cost reporting and organization (for example costCenter=marketing).
• Locks — CanNotDelete or ReadOnly locks guard critical resources from accidental change.

Bottom line: ARM is the consistent, secured, idempotent gateway to Azure. Every tool, every template, every API call goes through it.

Choosing Your Interface to ARM

All of these tools front the same ARM API, so the choice is about workflow, not capability:

For repeatable deployments, prefer infrastructure as code (ARM templates or Bicep) over clicking in the Portal, because templates are version-controlled, reviewable, and idempotent.

ARM Templates vs Bicep — what to remember

Because Bicep compiles down to an ARM template, anything you can deploy with one you can deploy with the other; Bicep simply improves the authoring experience. Both are declarative and idempotent.

Management Locks Protect Critical Resources

A frequent ARM exam topic is resource locks, applied at the resource, resource-group, or subscription scope and inherited downward:

• CanNotDelete — authorized users can read and modify the resource but cannot delete it.
• ReadOnly — users can read the resource but cannot modify or delete it (more restrictive than RBAC).

Locks are the guardrail that stops an accidental delete of, say, a production database, even by an account that otherwise has Owner rights.

Worked end-to-end scenario

A developer runs az deployment group create with a Bicep file that defines a virtual network, a dependent subnet, and a VM. ARM authenticates the developer through Microsoft Entra ID, checks that their RBAC role allows the create and that no Azure Policy denies it, then deploys the virtual network first, the subnet second, and the VM last based on the dependency chain — deploying any independent resources in parallel. A CanNotDelete lock on the resource group would still permit this create but block a later accidental delete.

Bottom line revisited: Know the lifecycle (authenticate → authorize → route → execute), that all tools share ARM, that providers must be registered, and that templates/Bicep are declarative and idempotent.