Academmia

Azure Resource Manager (ARM) and ARM templates

az-900•mixed•

Management and governance

Azure Resource Manager (ARM) and ARM templates

Short Summary

In this lesson, I explain what Azure Resource Manager (ARM) is and why most Azure management actions go through it. Then I explain what an Azure Resource Manager template (ARM template) is and why “declarative” templates help you deploy the same environment consistently. You’ll leave with a simple mental model: tools send requests, ARM processes them, templates describe the desired end state.

Learning Objectives

By the end of this lesson, you will be able to:

  • Define Azure Resource Manager (ARM) and describe its role as Azure’s deployment and management layer.
  • Trace how tools like the Azure portal, Azure command-line interface (CLI), and Azure PowerShell interact with ARM.
  • Distinguish declarative templates from imperative scripts at a high level.
  • Identify the main deployment scopes for ARM template deployments (resource group, subscription, management group, tenant).
  • Explain how templates help reduce “drift” (small, accidental differences) between environments.

Core Concepts

Azure Resource Manager (ARM) is Azure’s deployment and management service. It’s part of the control plane (the side of Azure that handles management operations like create, update, delete). In practice, ARM is the “front desk” for management: when you send a management request, ARM receives it, checks your permissions, and forwards the request to the right Azure service.

When you use different tools—like the Azure portal, Azure command-line interface (CLI), Azure PowerShell, REST (Representational State Transfer) APIs, or SDKs (Software Development Kits)—you’re mostly choosing a different interface. Behind the scenes, they send management requests through ARM. ARM then routes the request to the appropriate resource provider (the Azure service that supplies a specific resource type, like compute or storage).

An Azure Resource Manager template (ARM template) is an Infrastructure as Code (IaC) file. It is typically JavaScript Object Notation (JSON) and declarative, meaning you describe what you want (the target end state), not how to do it step by step. ARM reads the template and performs the required operations to reach that end state.

A practical rule of thumb:

  • Declarative (templates): “Make the environment look like this.”
  • Imperative (scripts): “Run these commands in this order.”

ARM templates can define many resources in one deployment (not just one resource) and can model dependencies, so resources are deployed in the right order.

ARM template deployments can target different scopes:

  • Resource group scope: deploy resources for one solution/application group.
  • Subscription scope: deploy or configure items that apply across a subscription.
  • Management group scope: apply changes across multiple subscriptions grouped together.
  • Tenant scope: apply changes at the Microsoft Entra tenant level (organization-wide).

Note: Microsoft also offers Bicep, a newer authoring language that is converted to an ARM template during deployment. It’s still the same ARM engine underneath—just a different way to write the desired state.

Practical Understanding

Practical Situation 1: “I deployed in the portal, but the result looks the same as a CLI deployment”

You notice that creating a resource in the Azure portal and creating the same resource using CLI or PowerShell ends up producing the same outcome.

How to think about it: Those are different tools sending management requests, but ARM is the shared management layer that processes them. The tool is your interface; ARM is the service that validates and coordinates the deployment.

Common misunderstanding: “Portal deployments are different from CLI deployments.” The interface differs, but the requests still go through ARM.

Practical Situation 2: “We must deploy the same environment repeatedly without drift”

Your team needs to deploy the same setup (networking, compute, storage) multiple times across environments and you want it to stay consistent.

How to think about it: This is a classic Infrastructure as Code (IaC) use case. An ARM template stores the desired state in a file, so you can redeploy the same design and reduce manual differences over time.

Common misunderstanding: “Repeating a set of CLI commands is the same as a template.” Commands can work, but templates are designed around a declarative desired-state model that’s easier to repeat consistently.

Practical Situation 3: “A deployment has dependencies and order matters”

You’re deploying multiple related resources where one depends on another (for example, an app needs networking to exist first).

How to think about it: A template can describe multiple resources in one deployment, and ARM can orchestrate the deployment order based on dependencies. You describe the target structure; ARM coordinates the steps.

Common misunderstanding: “A template can only deploy one thing.” Templates can define many resources in a single coordinated deployment.

Practical Situation 4: “We need to apply changes at different scopes”

Some changes should apply to a single resource group, while others should apply across a subscription (or beyond).

How to think about it: ARM template deployments support different scopes. Pick the scope that matches how wide you want the change to apply: resource group for most app deployments, broader scopes for cross-subscription or organization-wide work.

Common misunderstanding: “Templates only work at the resource group level.” Templates can be deployed at resource group, subscription, management group, or tenant scopes.

Common Pitfalls

  • Mistake: Treating Azure Resource Manager (ARM) as an optional add-on. Correction: ARM is the default deployment and management layer that processes most create/update/delete operations in Azure.

  • Mistake: Confusing an ARM template with Azure Resource Manager (ARM) itself. Correction: ARM is the service; an ARM template is a declarative file that tells ARM what to deploy.

  • Mistake: Thinking templates are imperative scripts. Correction: Templates are declarative: they describe the desired end state, and ARM determines the sequence of operations.

  • Mistake: Assuming templates can only deploy one resource or only Virtual Machines (VMs). Correction: A template can describe multiple resource types and deploy a complete environment as one coordinated deployment.

  • Mistake: Ignoring deployment scope. Correction: Choose the scope (resource group, subscription, management group, tenant) based on where the change should apply.

Check Your Understanding

  • Explain the difference between “a tool that triggers deployments” and “the service that processes deployments,” using your own words.
  • Write a one-sentence definition of an ARM template without using the word “template.”
  • Describe a real scenario where a declarative approach is safer than an imperative approach.
  • Name two deployment scopes and explain when you would use each.
  • Describe how ARM helps when deploying multiple resources that depend on each other.

Further Reading