Azure Resource Manager – Templates (JSON)

In Azure and Azure Stack, the Azure Resource Manager is the management layer (API) where you connect to for deploying resources. In this blog we are going to look at the Azure Resource Template and how to use it when deploying resources. When deploying resources with Azure Resource Manager keep in mind the following aspects. It is:

  • Template-driven – Using templates to deploy all resources.
  • Declarative – You declare the resources you want to have instead of imperative where you need to make rules.
  • Idempotent – You can deploy the template over and over again without affecting the current state of resources.
  • Multi-service – All services can be deployed using Azure Resource Manager, Website, Storage, VMs etc.
  • Multi region- You can choose in which region you would like to deploy the resources.
  • Extensible – Azure Resource Manager is extensible with more resource providers and thus resources.

You can deploy a resource template using the Azure Portal, PowerShell or Azure CLI. But before you actually can deploy those resources you have to create a resource group. When you start the deployment you need to specify the resource group you want to create the resources in. Let’s look at how a deployment template looks like and how it is built from the ground up.

An Azure Resource Template is a JSON file. I find Visual Studio one of the best tool to author the resource templates. Also it provides intellisense for building the resource template and some helpers / functions to easily author the resource template. Let’s look closer at the content of this template file. If you take an empty resource template it looks like this:

Each element has different objects. Find in the table the objects that define a Azure Resource Manager Template:

Element name Required Description
$schema Yes Location of the JSON schema file that describes the version of the template language.
contentVersion Yes Version of the template (such as When deploying resources using the template, this value can be used to make sure that the right template is being used.
parameters No Values that are provided when deployment is executed to customize resource deployment.
variables No Values that are used as JSON fragments in the template to simplify template language expressions.
resources Yes Types of services that are deployed or updated in a resource group.
outputs No Values that are returned after deployment.

So let’s deep dive into some of the sections involved to understand how a resource template is built.


When you start a new deployment and you have parameters defined in your resource template then these needs to be entered in before the deployment can start. It are values used for that specific deployment. These parameters are then used in other sections of the template. When we look at a parameter in the parameters section it can be for example a value to select a specific Operating System version when deploying a Virtual Machine:

Element name Required Description
parameterName Yes Name of the parameter. Must be a valid JavaScript identifier.
type Yes Type of the parameter value. See the list below of allowed types.
defaultValue No Default value for the parameter, if no value is provided for the parameter.
allowedValues No Array of allowed values for the parameter to make sure that the right value is provided.

The allowed types for values are:

  • string or secureString – any valid JSON string
  • int – any valid JSON integer
  • bool – any valid JSON boolean
  • object – any valid JSON object
  • array – any valid JSON array

As I mentioned earlier, when you start the deployment you are prompted for the parameters that you have defined in your resource template. Another option is to put the parameters in a templatename.params.json file. In this file you specify the parameters upfront so you don’t have to specify them when you start the deployment. This is beneficial for example when you need to repeatedly deploy resources using the same set of parameters. Or you need to give deployments to people that you want to fully pre-populate so they only need to run a PowerShell one liner to deploy the resource template. An example of a template parameter file looks like this:

When you deploy for example with PowerShell your template you can also specify the template parameter file to use in that deployment:

In that case you won’t be prompted with parameters as they are retrieved from the template parameter file. (unless you didn’t specify it in your template parameter file)


The variables are values that can be constructed for example from parameters to create a variable and use that in other sections of your deployment template. Or let’s say you want to use a single value across multiple resources. When defined in a variable you can reuse that variable in the resources section of your deployment template so when it needs to change you can change it in your template just in one place, and you don’t need to specify it each time at deployment as a parameter. Here you see an example of the variables section in a resource template:


The resources section in the template are the actual resources that you are going to deploy or update. This can be a collection of resources and their configuration settings (properties) you can define directly in the resource or populate them from parameters and/or variables. Here you see an example where the first resource describes the properties you need to define and the second resource containing a storage account:

Element name Required Description
apiVersion Yes Version of the API that supports the resource.
type Yes Type of the resource. This value is a combination of the namespace of the resource provider and the resource type that the resource provider supports.
name Yes Name of the resource. The name must follow URI component restrictions defined in RFC3986.
location No Supported geo-locations of the provided resource.
tags No Tags that are associated with the resource.
dependsOn No Resources that the resource being defined depends on. The dependencies between resources are evaluated and resources are deployed in their dependent order. When resources are not dependent on each other, they are attempted to be deployed in parallel. The value can be a comma separated list of a resource names or resource unique identifiers.
properties No Resource specific configuration settings.
resources No Child resources that depend on the resource being defined.


In this section you can define outputs from your template. These values can be for example a connection string from a deployment of a database. This can then be passed into another deployment to use for example as connection string for a website you are going to deploy.

Element name Required Description
outputName Yes Name of the output value. Must be a valid JavaScript identifier.
type Yes Type of the output value. Output values support the same types as template input parameters.
value Yes Template language expression which will be evaluated and returned as output value.

We just looked at each section of a resource template file and hope it gave you basic understanding of what the sections mean and how they are populated. I advise you to play with existing resources available on Github and learn more on how to build these templates your own.

Here you will find a complete example of a Virtual Machine deployment:

Spread the word. Share this post!