ARM Templates
Start course

The Azure cloud is a collection of resources that work in unison to deliver a product or a service. Hardware is virtual and services can be created and destroyed at the stroke of a key. In the context of DevOps, resources can be "spun up" as part of a pipeline. It is crucial that when resources are deployed multiple times, those deployments are consistent, repeatable, and can be automated. Doing it manually through the Azure portal isn’t practical. Azure Resource Manager (ARM) has an interface for processing resource templates that specify resource deployments.

In this course, we look at how those templates can be built and deployed. We start with a simple template and move on to more complex examples to illustrate many of the useful features available when deploying resources with templates. This course contains plenty of demonstrations from the Azure platform so you can see exactly how to use Azure Resource Manager in practice.

If you have any feedback on this course, please reach out to us at

Learning Objectives

  • Understand what Azure Resource Manager (ARM) is and its use cases
  • Learn about the different ARM templates available and how they can be used
  • Deploy databases using an ARM template
  • Export a template and create templates using QuickStart templates
  • Deploy resources using a script

Intended Audience

This is a beginner-level course aimed at anyone who wants to learn more about managing and configuring their Azure environment, and fast-tracking their deployments.


To get the most out of this course, you should have a basic understanding of the Azure platform.


GitHub Repo



An ARM template is a JSON file describing the resources or services that you want to deploy and it has many advantages. Templates are idempotent. This means changes are applied only once, which is exactly what we want. Associated with this is repeatability, and that each time we apply the template we get the same result. Unlike a procedural script where the order of commands is crucial, the template is submitted as one object and Azure Resource Manager works out the order that resources should be created in. So dependency management and orchestration of deployment operations are carried out correctly. That JSON format also allows for nested and hierarchical resources and you can divide up a deployment into multiple linked files to make complex deployments modular and easier to manage. Azure Resource Manager includes commands for testing templates, and Azure DevOps has a task for including ARM templates in pipelines.

A template file is made up of five sections. There are parameters that can be passed into the template. A parameter has a name and a type, for example, string or int for integer, so like programming data types. There is a functions section, this is where you define your own functions. This is in addition to the ARM template built-in functions. Any values you want to use within the template are defined in the variables section. So not variables in the traditional programming sense, but more like constants. Of course, we have a resources section which is obviously the most important part of the template as this is where we define the resources or services we want to deploy. Finally, we have an outputs section that could be used for displaying information or daisy-chaining templates. Also at the root of the template, we have the JSON schema, which we shall see is very important when building a template and also the content version.

Parameters allow you to pass variables into the template to make its functionality more dynamic. Each parameter object starts with its name. A parameter has a type that can be an int, bool, array, object, string, secure object, or secure string. You can also define a default value, allowed values and minimum and maximum lengths or values. Within the metadata section, you can give your parameter a description.

Before I move on to the function section, I just briefly want to touch on the built-in functions that are available within ARM templates. As you can see from this table, there are quite an extensive array of built-in functions, ranging from array functions through to string, although not all of the string functions have been listed here. Many of the functions are what you would expect to find in most programming languages and definitely in the .NET environment. Resource functions are there to provide access to your Azure resources and account settings, while the deployment value functions allow you to access different sections of the template.

User-defined functions are more like formulas or expressions rather than functions that you might find in a procedural programming language. They do take parameters that are defined with a name and a data type and the return type called output also has a defined data type. Template variables and parameters are global and can be used within user-defined functions. While you can use built-in logical functions within your user-defined function, there is no facility for iterations or for-loops. Essentially user-defined functions are a way of separating out complex or compound functionality that you want to use more than once into a separate piece of template code.

Variables are key-value pairs that are defined once and can be used throughout the template. As I said earlier, they are more like constant values as they can't be assigned to once defined. Variables don't have to be simple data types, they can be nested and complex JSON objects. The resource section is the main event, if you will. This is where we define the resources or services that we want to deploy. For obvious reasons, different resources will have different properties but there are some properties that all resources must contain. Every resource needs a name and every resource is of a type and is located somewhere. The resource shown here is an app service and depends on another resource of the type app service plan.

Output values are essentially the inverse of parameters. They enable you to output values from your template for either informational purposes or as inputs to linked templates, that we shall look at later, or to be used in scripts that executing the template.

About the Author
Learning Paths

Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a  Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.