ARM template resources section in Azure - Deep Dive

Overview - ARM template resources section

What is it?

The ARM template resources section is where you define the cloud components you want to create or manage in Microsoft Azure. Each resource represents a service or object like a virtual machine, storage account, or network. This section describes what resources to deploy, their settings, and how they connect. It is written in JSON format and is part of an ARM template that automates Azure deployments.

Why it matters

Without the resources section, you cannot tell Azure what to build or change. It solves the problem of manually creating cloud services by letting you describe your infrastructure as code. This makes deployments repeatable, consistent, and easy to update. Without it, managing cloud resources would be slow, error-prone, and hard to track.

Where it fits

Before learning this, you should understand basic cloud concepts and JSON syntax. After this, you can learn about parameters, variables, and outputs in ARM templates to make deployments more flexible and reusable.

Mental Model

Core Idea

The resources section is a detailed shopping list telling Azure exactly what cloud items to create and how to set them up.

Think of it like...

It's like writing a recipe for a cake where each ingredient and step is a resource and its settings, so the baker (Azure) knows exactly what to prepare.

┌─────────────────────────────┐
│ ARM Template                │
│ ┌─────────────────────────┐ │
│ │ Resources Section       │ │
│ │ ┌─────────────────────┐ │ │
│ │ │ Resource 1           │ │ │
│ │ │ - type              │ │ │
│ │ │ - name              │ │ │
│ │ │ - properties        │ │ │
│ │ ├─────────────────────┤ │ │
│ │ │ Resource 2           │ │ │
│ │ │ - type              │ │ │
│ │ │ - name              │ │ │
│ │ │ - properties        │ │ │
│ │ └─────────────────────┘ │ │
│ └─────────────────────────┘ │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is the resources section

Concept: Introduce the resources section as the place to list cloud items to create.

In an ARM template, the resources section is a JSON array where each item describes one Azure resource. Each resource has a type (like 'Microsoft.Storage/storageAccounts'), a name, and properties that configure it. This section tells Azure what to build when you deploy the template.

Result

You understand that the resources section is the core part of an ARM template that defines what cloud services will be created.

Knowing the resources section is the foundation because it controls the actual cloud infrastructure you want to manage.

2

Foundation

Basic structure of a resource item

Concept: Explain the key fields inside a single resource object.

Each resource in the resources section has these main fields: - type: The kind of Azure service (e.g., virtual machine, storage account). - apiVersion: The version of the Azure API to use. - name: The unique name of the resource. - location: The Azure region where it will be created. - properties: A nested object with settings specific to the resource type. - dependsOn (optional): List of other resources that must be created first. Example: { "type": "Microsoft.Storage/storageAccounts", "apiVersion": "2022-09-01", "name": "mystorageaccount", "location": "eastus", "properties": { "accessTier": "Hot" } }

Result

You can identify and write the basic parts needed to define a resource in the template.

Understanding these fields helps you customize resources and control deployment order.

3

Intermediate

Using dependsOn to order resources

🤔Before reading on: do you think Azure creates resources in the order they appear in the template or based on dependencies? Commit to your answer.

Concept: Introduce dependsOn to control the creation order of resources.

Azure deploys resources in parallel by default. To ensure one resource is created before another, use the dependsOn field. It lists resource names that must finish deploying first. This prevents errors when one resource needs another to exist first. Example: { "type": "Microsoft.Network/virtualNetworks", "name": "myVnet", "apiVersion": "2022-07-01", "location": "eastus", "properties": { /* vnet settings */ } }, { "type": "Microsoft.Network/networkInterfaces", "name": "myNic", "apiVersion": "2022-07-01", "location": "eastus", "dependsOn": ["myVnet"], "properties": { /* nic settings */ } }

Result

You can control resource deployment order to avoid dependency errors.

Knowing how to use dependsOn prevents deployment failures caused by resource creation timing.

4

Intermediate

Nested resources and child objects

🤔Before reading on: do you think all resources must be top-level in the resources array, or can some be nested inside others? Commit to your answer.

Concept: Explain how some resources can be nested inside others as child resources.

Some Azure resources have child resources that belong inside them, like subnets inside a virtual network. You can define these nested resources inside the parent resource's resources array. This groups related resources and simplifies management. Example: { "type": "Microsoft.Network/virtualNetworks", "name": "myVnet", "apiVersion": "2022-07-01", "location": "eastus", "properties": { /* vnet settings */ }, "resources": [ { "type": "subnets", "name": "default", "apiVersion": "2022-07-01", "properties": { /* subnet settings */ } } ] }

Result

You can organize related resources hierarchically inside the template.

Understanding nested resources helps keep templates clean and reflects real Azure resource relationships.

5

Intermediate

Using variables and parameters in resources

🤔Before reading on: do you think resource properties can only have fixed values, or can they use variables and parameters? Commit to your answer.

Concept: Show how to use variables and parameters to make resource definitions flexible.

Instead of hardcoding values, you can use parameters and variables inside resource fields. Parameters let users provide input when deploying. Variables store reusable values inside the template. Use expressions like [parameters('paramName')] or [variables('varName')] in resource properties. Example: { "type": "Microsoft.Storage/storageAccounts", "name": "[parameters('storageAccountName')]", "location": "[variables('location')]", "properties": { "accessTier": "Hot" } }

Result

You can create templates that adapt to different inputs and environments.

Using parameters and variables in resources makes templates reusable and easier to maintain.

6

Advanced

Resource copy loops for multiple instances

🤔Before reading on: do you think you must write each resource instance separately, or can you create many with one definition? Commit to your answer.

Concept: Introduce the copy property to deploy multiple resource instances from one template entry.

The copy property lets you create multiple copies of a resource with a single definition. You specify a count and use the copyIndex() function to give each instance a unique name or property. Example: { "type": "Microsoft.Storage/storageAccounts", "name": "[concat('storage', copyIndex())]", "apiVersion": "2022-09-01", "location": "eastus", "copy": { "name": "storageLoop", "count": 3 }, "properties": { "accessTier": "Hot" } }

Result

You can efficiently deploy many similar resources without repeating code.

Knowing copy loops reduces template size and errors when deploying multiple similar resources.

7

Expert

Resource lifecycle and deployment modes

🤔Before reading on: do you think ARM templates always add resources, or can they update and delete too? Commit to your answer.

Concept: Explain how resource deployment modes affect creation, update, and deletion behavior.

ARM templates support two deployment modes: Incremental and Complete. - Incremental mode adds or updates resources but leaves others untouched. - Complete mode makes the deployed resources exactly match the template, deleting any not listed. This affects how the resources section is interpreted during deployment and controls resource lifecycle management. Example deployment command: az deployment group create --mode Complete --template-file template.json --resource-group myRG

Result

You understand how deployment mode changes resource management behavior.

Knowing deployment modes helps avoid accidental resource deletion or orphaned resources in production.

Under the Hood

When you deploy an ARM template, Azure Resource Manager reads the resources section and processes each resource object. It calls the Azure service APIs specified by the resource type and apiVersion to create or update the resource. The dependsOn field builds a dependency graph to order operations. Nested resources are deployed as part of their parent. The deployment engine tracks state and reports success or failure for each resource.

Why designed this way?

The resources section was designed as a declarative JSON list to make infrastructure as code simple and readable. JSON is widely supported and easy to generate. The dependency model allows parallel deployment for speed but ensures order when needed. Nested resources reflect Azure's hierarchical resource model. This design balances clarity, flexibility, and automation.

┌───────────────────────────────┐
│ ARM Template Deployment Engine │
├───────────────┬───────────────┤
│ Reads JSON    │ Builds Graph  │
│ resources[]   │ of dependsOn  │
├───────────────┴───────────────┤
│ Deploys resources in order    │
│ using Azure APIs              │
│ ┌───────────────┐             │
│ │ Resource 1    │             │
│ │ Resource 2    │             │
│ │ Nested Child │             │
│ └───────────────┘             │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does the order of resources in the resources array guarantee deployment order? Commit to yes or no.

Common Belief: The resources are deployed in the order they appear in the template.

Reality: Azure deploys resources in parallel unless dependsOn specifies dependencies.

Why it matters: Assuming order controls deployment can cause race conditions and deployment failures.

Quick: Can you deploy a resource without specifying an apiVersion? Commit to yes or no.

Common Belief: apiVersion is optional and Azure will pick a default if missing.

Reality: apiVersion is required to tell Azure which API version to use for the resource type.

Why it matters: Missing apiVersion causes deployment errors or unexpected behavior.

Quick: Does dependsOn accept resource types or only resource names? Commit to your answer.

Common Belief: dependsOn can list resource types to depend on.

Reality: dependsOn must list the full resource names, not types.

Why it matters: Incorrect dependsOn causes ignored dependencies and deployment errors.

Quick: Does Complete deployment mode only add resources? Commit to yes or no.

Common Belief: Complete mode only adds or updates resources, never deletes.

Reality: Complete mode deletes any existing resources not in the template.

Why it matters: Using Complete mode without care can cause accidental resource deletion.

Expert Zone

1

Resource names must be unique within their scope; nested resources inherit scope from parents, affecting naming and dependencies.

2

The apiVersion affects available properties and behavior; using outdated versions can cause missing features or errors.

3

Copy loops can be nested and combined with conditions, but complex loops increase deployment time and template complexity.

When NOT to use

Avoid using the resources section alone for very dynamic or large-scale deployments; instead, use ARM template linked templates or Bicep for modularity and maintainability.

Production Patterns

In production, resources sections are often split into multiple linked templates for separation of concerns. Parameters and variables are heavily used to customize deployments per environment. Deployment modes are chosen carefully to avoid accidental deletions.

Connections

Infrastructure as Code (IaC)

The resources section is a core part of IaC in Azure, defining infrastructure declaratively.

Understanding resources in ARM templates helps grasp how IaC automates cloud infrastructure management.

Dependency Graphs in Project Management

dependsOn creates a dependency graph similar to task dependencies in project plans.

Knowing dependency graphs in project management clarifies how resource deployment order is controlled.

Recipe Writing in Cooking

Defining resources and their properties is like writing a recipe with ingredients and steps.

This connection shows how clear instructions lead to predictable results, whether baking or deploying cloud resources.

Common Pitfalls

#1 Forgetting to specify apiVersion causes deployment failure.

Wrong approach:

{
"type": "Microsoft.Storage/storageAccounts",
"name": "mystorage",
"location": "eastus",
"properties": {}
}

Correct approach:

{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2022-09-01",
"name": "mystorage",
"location": "eastus",
"properties": {}
}

Root cause:

Not knowing apiVersion is mandatory for Azure to know which API to call.

#2 Assuming resource order controls deployment sequence.

Wrong approach:

"resources": [
{ "name": "resourceB", "dependsOn": [] },
{ "name": "resourceA", "dependsOn": [] }
]

Correct approach:

"resources": [
{ "name": "resourceA", "dependsOn": [] },
{ "name": "resourceB", "dependsOn": ["resourceA"] }
]

Root cause:

Misunderstanding that Azure deploys in parallel unless dependencies are declared.

#3 Using dependsOn with resource types instead of names.

Wrong approach:

"dependsOn": ["Microsoft.Storage/storageAccounts"]

Correct approach:

"dependsOn": ["mystorageaccount"]

Root cause:

Confusing resource type with resource name in dependency declarations.

Key Takeaways

The resources section is the heart of an ARM template, defining what Azure cloud services to create and configure.

Each resource needs a type, apiVersion, name, location, and properties to describe it fully.

dependsOn controls deployment order by specifying resource dependencies, preventing timing issues.

Using parameters, variables, and copy loops in resources makes templates flexible and scalable.

Deployment modes affect how resources are added, updated, or deleted, so choose carefully to avoid mistakes.