1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Introduction to Azure Resource Manager

ARM JSON Template Structure

The course is part of these learning paths

AZ-103 Exam Preparation: Microsoft Azure Administrator
course-steps 15 certification 6 lab-steps 9
AZ-203 Exam Preparation: Developing Solutions for Microsoft Azure
course-steps 20 certification 1 lab-steps 7
AZ-301 Exam Preparation: Designing a Microsoft Azure Architecture
course-steps 14 certification 7 lab-steps 3
Architecting Microsoft Azure Solutions
course-steps 10 certification 6 lab-steps 5
Developing, Implementing and Managing Azure Infrastructure
course-steps 10 certification 7 lab-steps 2
more_horiz See 3 more
Start course
Duration1h 30m
star star star star star-half


During this lecture, we will explore the structure of an Azure Resource Manager (ARM) JSON Template. Once you understand the different components of an ARM JSON Template, you will understand how to modify existing templates, and piece your own templates together. ARM JSON Templates have several top-level sections: parameters, variables, resources, and outputs (output parameters).


Hello, and welcome to Microsoft Azure Resource Manager, ARM JSON Template Structure. 

In this lecture, we're going to explore the ARM JSON Template Structure, how to define Azure resource dependencies within an ARM template, what ARM JSON template functions are and nested ARM JSON templates. 

Let's start by taking a look at the structure of an Azure Resource Manager JSON template. A JSON template is simply a JSON file that contains several different sections inside of it. 

First of all, we have input parameters. When we specify input parameters, these parameter values can be specified by the person who's deploying the template at execution time. Variables allow us to define custom pieces of data that we can reuse inside of our template. Any time that we have duplicate information inside of our template, we may want to consider defining a variable and then utilizing that variable instead. The meat of the JSON template is the Resources section. Inside of the Resources section, we define all of the individual cloud resources such as virtual networks, or virtual machines, or web apps, or storage accounts and many, many other types of resources. All of the properties that describe each of these resources are declared as a child object of each resource. 

Finally, we can provide Output Parameters. So after deploying an Azure Resource Manager JSON template, which we will discuss in a different lecture, you can provide data from that JSON template to the person who called the script. One additional feature is that we can actually nest templates together. These are formally called Linked Templates, and a linked or nested template is actually declared as a resource inside of the parent's template. When you're deploying your Azure Resource Manager templates, you may encounter scenarios where one resource is dependent on one or more other resources. 

There's a few different ways to resolve this inside of your Azure Resource Manager JSON Template. First of all, each resource has a dependsOn property that allows you to define explicit dependencies for that resource. Additionally, a resource can specify up to five levels deep of nested child resources. Finally, we can use the references ARM Template function to reference a property on a different resource, which creates an implicit dependency on that other resource. Now you do want to be careful when you're defining dependencies, because if you define too many dependencies that are unnecessary, you can actually interrupt the parallelism of the Azure Resource Manager API, which provides the rapid deployment times that you're accustomed to. 

The Azure Resource Manager JSON Templates support a large variety of template functions. There's only a handful of template functions listed here just to show a demonstration, but there is actually close to 20 or 30 different functions available if you go out to the official Azure Resource Manager documentation page. For example, we have an ARM Template function that allows us to concatenate values together. We can obtain the final resource ID of another resource after it's been provisioned. 

We can use the Variables function to retrieve the value of a variable that we've declared inside the variables section of our ARM Template, and we also have a Parameters function that allows us to retrieve the input parameters that a user has specified for the deployment of that Azure Resource Manager Template. Please visit the documentation for a comprehensive list of ARM Template functions. In some cases, you'll need to deploy multiple instances of a similar resource. For example, if you're deploying a global application where an Azure web application is provisioned in multiple regions across the globe, but have similar configurations, you may need to create what's called a "copy." So each resource supports the "copy" JSON property, which allows you to specify the number of copies of that resource that you would like to create. Inside of your resource definition, you can use a special template function called copyIndex that gives you the current iteration such as zero, one, two, three and so on so that you can use that to uniquely name each resource in the copy array. 

As we briefly discussed previously, we can create linked or nested templates. A nested template is declared as a resource in the parent template. The linked template must be accessible by the Azure Resource Manager API via an anonymously authenticated URI. A parent template can pass input parameters into a nested or linked template, and the parent template can also retrieve output parameters from the linked template, and utilize those in additional deployment of resources. 

Now that we've discussed the fundamentals of the Azure Resource Manager JSON Template structure, let's go ahead and take a look at the actual structure inside one of our editors.

About the Author

Trevor Sullivan is a Microsoft MVP for Windows PowerShell, and enjoys working with cloud and automation technologies. As a strong, vocal veteran of the Microsoft-centric IT field since 2004, Trevor has developed open source projects, provided significant amounts of product feedback, authored a large variety of training resources, and presented at IT functions including worldwide user groups and conferences.