Azure Resource Manager Templates Quick Start Guide

4 (4 reviews total)
By Ritesh Modi
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Infrastructure as Code and Configuration Management

About this book

Azure Resource Manager (ARM) templates are declarations of Azure resources in the JSON format to provision and maintain them using infrastructure as code. This book gives practical solutions and examples for provisioning and managing various Azure services using ARM templates.

The book starts with an understanding of infrastructure as code, a refresher on JSON, and then moves on to explain the fundamental concepts of ARM templates. Important concepts like iteration, conditional evaluation, security, usage of expressions, and functions will be covered in detail.

You will use linked and nested templates to create modular ARM templates. You will see how to create multiple instances of the same resources, how to nest and link templates, and how to establish dependencies between them.

You will also learn about implementing design patterns, secure template design, the unit testing of ARM templates, and adopting best practices.

By the end of this book, you will understand the entire life cycle of ARM templates and their testing, and be able to author them for complex deployments.

Publication date:
February 2019


Chapter 1. Infrastructure as Code and Configuration Management

Welcome, readers, to the world of Azure Cloud, Azure Resource Manager (ARM), and ARM templates. Azure Cloud is growing in  leaps and bounds and has good acceptability within enterprises. Azure Cloud provides a very performance-centric, scalable, and reliable Azure Resource Manager platform for management and governance of our deployments. To create resources on Azure, ARM templates are preferred over other mechanisms because of their inherent advantages. These advantages are mentioned throughout this book.

ARM templates have become an essential skill for any serious development on Azure, and writing reusable effective ARM template is sought after by many organizations. The Azure DevOps paradigm, to a large extent, also depends on ARM templates for its automation requirements.

In this first chapter, we will cover the following topics:

  • Configuration management
  • Infrastructure as code
  • Understanding ARM templates
  • Designing ARM template
  • A primer on JSON
  • Introducing Azure Resource Manager

What is configuration management?

Every deployment comprises two stacks of resources:

  • Environment or infrastructure resources 
  • Application deployment

Infrastructure resources refer to hardware, software, and platform resources that make an environment suitable for application deployment. For example: infrastructure resources might contain hardware resources, such as networks, load balancers, network interface cards, physical server, virtual machines, network connectivity, an operating system, as well as platform resources, such as container runtime, and framework deployments, such as .NET core. Each of these infrastructure resources should be configured in a way that ensures the application will work according to its design.

After infrastructure resource-provisioning, the application is deployed on top of them. These are related to resources such as application binaries, application dependencies, and package installations.

The configuration of these resources is needed across environments—from higher-level environments, such as the production environment, to lower-level environments, such as the dev and test environments. There can be multiple environments for a solution. The configuration for each of these environments is different. The configuration for a production environment for a solution is different than the configuration of a development environment for the same solution. The configuration differences could be in terms of number of virtual machines, the size of virtual machines, the DNS names, the IP address range, and more. The application configuration for each of these environments is also different. For example: the connection string to database, integration endpoints to other systems, and other configurations are different across these environments.

Active management of both the infrastructure- and application-level configuration information as well as data is known as configuration management in software life cycle management parlance.

There are many tools that can help manage configurations across environments. Some of these are open source while others are propriety.

Each cloud provider also has its own configuration-management tools.

Azure provides ARM templates for provisioning and configuring the infrastructure resources. Other cloud vendors provide their own native ways to configure the environments.

Tools such as Desired State Configuration, Chef, Puppet, and Ansible are suitable for application configuration.

ARM templates enable a concept known as Infrastructure as Code; let's understand it in the next section.


Infrastructure as Code

Infrastructure as Code is one of the important facets of configuration-management systems. Generally, an environment is provisioned using manual efforts, such as using a self-service portal or wizard that provides step-by-step directions to configure a resource. It might go a step further and the environment can be provisioned using scripts, such as PowerShell and Bash. These scripts can then execute either manually or automatically using an orchestrator tool.

There are some serious limitations in using any of the previously mentioned approaches:

  • Lack of repeatability, consistency, and predictability during provisioning and updating environments. The configuration values for scripts are either entered manually by copying from documents and Excel sheets.
  • Lack of diagnostic information and it's difficult to figure out the exact error location.
  • Human error while providing configuration values.
  • Lack of confidence in deployments.
  • Lack of efficiency and speed.

These limitations demand using a more systematic and automated approach for the creation of environments and the deployment of applications.

Infrastructure as Code can help remove these limitations. At a high level, Infrastructure as Code refers to the process of defining environments using code and then using it to create environments. However, Infrastructure as Code is much more than this. Infrastructure as Code mandates that infrastructure definitions after it's converted into code should follow the same application life cycle management principles that typically is followed for applications, they are as follows:

  • They should be versioned and stored in a version-controlled repository. Developers should be able to author infrastructure-related code and push them into the repository.
  • The repository helps with collaborating among developers about code related to infrastructure.
  • There should be a process established to verify and validate the changes done to infrastructure code to ensure that only well-tested code is deployed to higher-level environments.
  • After verification, the code should be stored in a place that can be used by all the environments for creation and updates.
  • Configuration information for each environment should be stored alongside the actual infrastructure code. These configurations can then be applied to each environment as applicable.
  • After the infrastructure code is deployed to pre-production and production environments, appropriate operational validation should be conducted to ensure that the environment is behaving as intended and meeting expectations.
  • There should be active monitoring of the environment and any deviation from the known desired configuration should be reported back.

The following screenshot is depicting the process followed for Infrastructure as Code:


What are ARM templates?

ARM templates are JSON files and they enable Infrastructure as Code for Azure Cloud Platform. ARM templates help to provision and configure resources in a predictable, consistent, and repeatable manner.

ARM templates help in the following ways:

  • Specifying resources and their configurations in a declarative manner. There is no scripting involved in provisioning resources.
  • Providing intent and what should be provisioned by defining the resources rather than how to deploy the resources.
  • Offers idempotent deployments by ensuring that the end state of the deployment is always consistent and predictable. This means that even during incremental deployments, the end state will remain consistent. It also means that templates deployed over and over will not change the end result, and environments will be equivalent when used to create multiple environments.
  • Orchestrates the provisioning and configuration process by declaring dependencies between resources.
  • Parameterizes the deployment process by enabling reusability, modular, and generic development.
  • Cross-subscription, cross-region, and multiple resource group deployment and configuration of resources.
  • Enables DevOps in the continuous integration and the continuous deployment of resources and the environment.

Designing ARM templates

ARM templates are one of the foundational pillars for the successful deployment of solutions on Azure. Authoring the right set of ARM templates—that are modular, reusable, and generic—is the first major task for ARM templates. The other aspect is the management and governance of these ARM templates. It is absolutely crucial to design the ARM template in a way that it can evolve over a period of time as well as be managed effectively.

The process for designing an ARM template is as follows:

  • Identification of resources: This is the first step when designing ARM templates for a solution; it involves the identification of resources and their count. There are many resources that provide similar features; however, there are differences between them. It is advised to read the fine print of those resources before selecting them for the solution.
  • Resource location: After resource identification, the location of these resources should be ascertained. Resources should be determined based on organizational policies and objectives. This also depends on sovereign rules and statutory regulations. The location is also determined based on the availability and pricing of resources in that region. There are also architectural requirements in terms of high availability, disaster-recovery, and performance to choose multiple locations for these resource locations.
  • Identification of the resource provider and its version: Resources are made available in Azure by resource providers. Resource providers are containers that provide security and namespaces to resource types. Each resource provider provides an API layer through which clients interact with it. This API undergoes changes based on changes in the resource types it contains. If there are breaking changes in resources, the resource provider version is incremented to reflect the breaking changes. Also, the addition of new features will change the version number of these resource providers. These version numbers are based on the date on which they are released. While designing ARM templates, it is necessary to determine the appropriate resource-provider version number based on your requirements.
  • Sequencing: Now that the Api version location and resources are identified, the sequence in which these resources should be provisioning needs to be determined. This is a necessary activity because a few resources might be dependent on other resources before they can be provisioned. This dependency could be because a resource might need data from other resources, or they could be a child resource of those resources.
  • Identification of parameters and variables: Now that the sequencing of resources is determined, it is important to make the template generic, modular, and reusable. It is also important that templates are maintainable and easy to change. Parameters for resource configuration and the execution of templates should be ascertained such that templates can be reused across environments and solutions. Variables should be determined based on the number of times a value is used multiple times within the template.
  • Identification of output from the template: The template output is important because it provides the return value and feedback about the execution of the template and its resources. This output also helps with testing the ARM templates.
  • Identification of the deployment process: ARM templates can be deployed using Azure portal, Azure PowerShell, Azure CLI, REST API, and SDKs. It is important to identify the tools used for the deployment of ARM templates. Azure PowerShell and Azure CLI are preferred means for deploying ARM templates. Furthermore, an orchestrator tool, such as Azure DevOps should be used to automate the deployment process.

The preceding process is shown here:


A brief primer on JSON

JavaScript Object Notation (JSON) is a lightweight data-representation and interchange format. It is a text-based and human-readable format that is easy to read, comprehend, and update. Many people think of JSON as a programming language or a markup language; however, it is neither. It is a pure representation of data in text format.

Prior to JSON, XML was the preferred data-exchange format and JSON has few similarities with it. Like XML, JSON is self-describing. It is quite easy to understand the intent of a JSON document by just reading through it. Also, like XML, it can create complex as well as nested objects. It is hierarchical, and objects can be composed of child objects and arrays. However, the similarities end here. JSON documents are terser and much more compact compared to XML documents. As a result, they are also much more reader-friendly. The data in XML documents is all string-based, however, in JSON, data can have types that make it easier to parse and validate them. The XML syntax is quite verbose compared to JSON.

JSON is supported by almost all programming languages and it provides SDKs to generate as well as read them intuitively.

There are a few limitations when it comes to JSON documents. They do not have any schema definition and documents do not have any fixed specification associated to them. In effect, there are no parsers or facilities to validate that a JSON document adheres to a certain specification.

A simple JSON document is shown here:

“customer” : {
                “customerId”: 1,
                “firstName”: “ritesh”,
                “lastName”: “Modi”,
                “isRepeatCustomer”: true,
                “address”: {
                                “streetName”: “10, Park Street”,
                                “city”: “Mumbai”,
                                “Country”: “India”
“productsOrdered”: [“IPhone”, “TShirt”]

Readers will notice that this JSON document is quite easy to read and comprehend. The basic JSON syntax comprises name-value pairs, where the name part is always decorated in double-quotes. Also, as a practice, the name part of the name-value pair follows the camel-casing naming standard. Each name is followed by a colon, :, and subsequently followed by the value part. Each name-value pair is separated using a comma: ,.

A JSON document starts with a left curly bracket, {, and ends with a right curly bracket: }. A JSON value can hold values of numbers, strings, Boolean, objects, and array data types:

  • Strings: Strings are a sequence of continuous characters and always enclosed within double quotes. In the preceding example, India is a string value assigned to Country. "Country": "India"; sincedouble-quotes are special characters in JSON, they need to be escaped if they are part of the value. For example: "/"India/"" will have an output of "India" assigned to the name element instead of just India without quotes.
  • Numbers: JSON supports multiple data types related to numbers, including integers, scientific, and real numbers.
  • Boolean: JSON supports true and false as Boolean values. They are never enclosed within quotes.
  • Null: JSON also supports Null as a value. It means nothing is assigned to the name element.
  • Objects: JSON also has a concept of an object. An object is a collection of key-value pairs enclosed within left curly brackets, {, and right curly brackets, }. Objects can be nested; that is, an object can contain another object as a child object. The customer document shown before in this section is an example of a JSON object.
  • Arrays: JSON arrays start with left square brackets, [, and end with right square brackets, ]. JSON arrays contain name-value pairs separated by a comma. They can also contain a set of values. productsOrdered in the previous example was an example of JSON arrays.

ARM templates support the following additional objects:

  • SecureString: A secure string is similar to a native JSON string; the difference is that the ARM templates runtime ensures that these values are never written in log files. These values are not visible on the Azure portal. This datatype is used to pass credentials, keys, and secrets that should not be visible to anyone.
  • SecureObject: A secure object is similar to native JSON arrays and objects. Again, these values are not visible in Azure portal and log files and are used to pass arrays and objects as secrets to ARM templates.

Azure Resource Manager

Azure Resource Manager, also popularly known as ARM, is the successor of Azure Service Management and is the new management framework that helps in provisioning, managing, monitoring, and governing Azure Resources.


The ARM framework helps to provision resources. The entire framework is highly scalable, performance-centric, and comprises multiple internal components. These components are not directly visible to users, but they help implement modularity and reusability within the overall architecture.

Here is the ARM architecture:

Here is the same architecture using examples of resource providers and types:

We will be referring to this architecture not only in this section but also throughout this chapter. The architecture comprises an Azure Resource Manager API component. This is one of the main components and the first point of contact with the Azure APIs for doing any operation within Azure. This is the control plane for the entire ARM framework.

When a client wants to talk to Azure, they must send their requests to this component. The ARM API does all the deciding, routing, and scheduling of resources. It hands over the incoming requests to other components that have designated responsibilities. While provisioning resources, it hands over the requests to the resource provider component, and the resource provider eventually ensures that resource instances are created based on the resource types controlled by them. Similarly, it hands over the request to other components, such as Azure policies, to evaluate the request and check whether the action in the request should be executed or denied.


Resources are provisioned in Azure in parallel. This was one of the drawbacks of ASM. Resources were provisioned in sequence and that was a real productivity dampener, as well as less predictable from a deployment perspective. The ARM framework is built completely from scratch and ensures that resources can be provisioned in parallel. Users can provide their own dependency graph between resources while provisioning them.


The framework helps to provision resources in any Azure region where the resource provider and resource types are available. The request to provision a resource reaches the ARM API containing information about the target region and API ensures that it validates the configuration information and resource availability at a given location.


The entire Azure framework is API-driven. There are various types of APIs, such as ARM, resource provider API, resource API, tenant API, usage API, cost API, and administrative API's. These APIs are scaled out automatically by Azure and are built using principles of single responsibility.


There are multiple types of clients that can interact with the ARM framework; the important ones are Azure PowerShell, the Azure command-line interface, Azure portal, ARM templates, Azure SDKs for different languages, and Azure REST APIs. These clients allow a varying degree of automation and implementation of DevOps.


Cloud deployments need active management even more than on-premises deployment. The management of cloud resources refers to the organization of resources in a way that allows easy and faster appropriate report generation and provision of artifacts that can manage resources as a collection rather than individually.


ARM frameworks provide features to add metadata information to all resource types in every resource provider, including resource groups. This helps with designing a complete information-management repository for Azure Resources and with generating reports based on these tags. Tags can help generate cost and usage reports for different environments, departments, phases, services, products, and so on. The possibilities for such reports are endless as ARM allows the creation of custom tags.

Resource groups

Resource groups are logical containers for hosting resources in Azure. A resource cannot exist without being contained in a resource group. A resource group is a management container that provides security boundary, policy, and locks assignments, reporting on cost, usage, and logs related to management-plane activities. A resource group is created within a region; however, resources contained in it can be in a different location and need not be in the same location as a resource group. Resource groups help with managing multiple resources as a group.


ARM framework manages access, authorization, policies, locks, and other management-related features in a hierarchical way. It means that there are parent-child relationships between these artifacts. The artifacts that form this hierarchy are management groups, subscriptions, resource groups, and resources. Providing access at the subscription level automatically provides access to the resource groups and the resources within them. The top most artifact is management group, which is a logical container for grouping Azure subscriptions; below it, subscriptions and resource groups are within subscriptions, and finally resources are within resource groups. This feature helps with the easy management and application of management-related activities to multiple subscription, resource groups, and resources.


The ARM framework provides monitoring capabilities for all its resources and resource groups. Monitoring helps to capture the essential telemetry and events. They store this data into storage accounts and other resources that are easily accessible, and then generate reports based on them. Azure provides numerous reports out of the box based on this data. Monitoring helps to identify issues with any resource related to health, performance, and availability. It also helps to identify changes made to the resources along with relevant information about initiator, date and time, activity performed, and other data.


Every resource in Azure generates events and telemetry that are logged in log files. The telemetry information is related to the health of the resource, including CPU utilization memory availability and network stats, and are written to the diagnostic logs. The events generated include any management control plane changes/updates/deletion of resources, and are written to the activity log. There are multiple types of log storage and these logs can be combined using log analytics.


Azure provides features to generates alerts based on log data that's captured using monitoring. These alerts could be based on multiple events, and this typically involves the health of a resource. Custom alerts can be configured; based on them, appropriate actions can be initiated.


The alerts are defined based on rules and are generated once the log files identify data that meets the condition of these rules. An action can be automated to be executed based on these alerts. The actions include notifying stakeholders using email, text messages, or by calling them. It could also be configured to execute scripts in Azure functions or Azure automation runbooks.


Any enterprise cloud platform should provide enough governance features to manage deployments effectively. Governance refers to the exercising policies to control over deployment and access to resources and resource groups. It also means creating policies that meet the organizational objectives.

Role-based access control

After authenticating and gaining access to the Azure environment, there is an additional layer that checks for access authorization to the resource and resource group. This additional layer is role-based access control (RBAC), which checks whether the user who is trying to access the resource has permissions to access and perform the activity it intends to perform. It is composed of three different components:

  • Permissions: Also known as role definition
  • Scope: The scope on which the permissions are evaluated. They are resource groups and resources
  • Principal: The actor trying to access the resources. It could be a user, group, or a service principle

RBAC assigns permissions to a principle at a given scope. For example, contributor permission is assigned to a service principal for a resource group.

It is also hierarchical and flows down from subscription to the resource group, and finally to the resource level.

Any permissions assigned to a principal at a resource group scope automatically gets the same access for resources contained within that resource group.


Policies is another important feature provided by the ARM framework. Policies provide control over the management plane of resources. While RBAC provides control on access to the data plane, Policies provides control over the management plane. It means that policies affect access and permissions to provision a resource. For example, a policy could explicitly deny the creation of resource in all regions apart from Central US and East US. These policies are checked while creating a new resource and are also evaluated for the existing resources.


Locks ensure that resources cannot be deleted or updated. This feature ensures that every ownership having permission on a scope, a principal cannot delete a resource. This is an additional layer of resource protection and especially useful for resources that are critical for working out a solution. The resources can only be deleted after removing the lock. There are two modes:

  • CanNotDelete: This lock prevents deletion of a resource. Under this mode, resources can be updated and read at the management-control level.
  • ReadOnly: This lock prevents deleting and updating a resource or resource group. This is more constraint compared to the CanNotDelete mode.


This chapter provided information about foundational concepts related to Azure Cloud, ARM, and ARM templates. Infrastructure as Code is a relatively new paradigm and should be adopted by enterprises to automate the process of provisioning environments. They also help in making Azure DevOps effective and efficient. ARM templates help to provision environments using a declarative approach. This helps to define the environment using JSON language and provides numerous ways to deploy them.

ARM provides an extensible and performant framework to manage, provision, and govern resources. We covered these topics in detail and provided a basic primer on JSON – the language of ARM templates.

We will start exploring ARM templates in more detail from the next chapter onward, and will cover the tools needed to create, deploy, and write basic ARM templates.

About the Author

  • Ritesh Modi

    Ritesh Modi is a former Microsoft senior technology evangelist. He has been recognized as a Microsoft Regional Director for his contributions to Microsoft products, services, and communities. He is a cloud architect, a published author, a speaker, and a leader who is popular for his contributions to datacenters, Azure, Kubernetes, blockchain, cognitive services, DevOps, artificial intelligence, and automation. He is the author of eight books.

    Ritesh has spoken at numerous national and international conferences and is a published author for MSDN magazine. He has more than a decade of experience in building and deploying enterprise solutions for customers, and has more than 25 technical certifications. His hobbies are writing books, playing with his daughter, watching movies, and learning new technologies. He currently lives in Hyderabad, India.

    You can follow him on Twitter at @automationnext.

    Browse publications by this author

Latest Reviews

(4 reviews total)
Sure anytime This worth your time and money
informative book
couldn't download the videos, error message. bad customer service

Recommended For You

Book Title
Unlock this book and the full library for FREE
Start free trial