Azure Resource Manager templates, commonly referred to as ARM templates, are JSON-based files that define the infrastructure and configuration of Azure resources in a declarative format. Instead of writing step-by-step instructions for how to create a resource, you describe what you want the final state to look like, and Azure Resource Manager handles the process of making that state a reality. This declarative approach is one of the foundational concepts that separates modern cloud infrastructure management from traditional manual provisioning methods.
For candidates preparing for the AZ-900 Microsoft Azure Fundamentals exam, ARM templates represent an important concept within the broader topic of Azure management and governance tools. The AZ-900 does not expect you to write complex templates from scratch, but it does expect you to understand what ARM templates are, why organizations use them, and how they fit into the Azure infrastructure deployment story. Grasping this concept also builds intuition for related topics like consistency, repeatability, and infrastructure as code that appear throughout the exam and throughout real cloud work.
Why Organizations Choose ARM Templates for Deployments
The primary reason organizations adopt ARM templates is consistency. When infrastructure is deployed manually through the Azure portal, small differences in configuration accumulate over time across environments. A development environment might have slightly different settings than a staging environment, which in turn differs from production. These inconsistencies cause bugs that are difficult to reproduce and security gaps that are hard to detect. ARM templates eliminate this problem by defining the exact configuration once and applying it identically every time a deployment runs.
Repeatability is the second major benefit. Once an ARM template is written and validated, it can be used to deploy the same environment as many times as needed, across different subscriptions, regions, or resource groups. This capability is particularly valuable during disaster recovery scenarios, where organizations need to rebuild infrastructure quickly and accurately. It is also useful for development teams that need fresh, clean environments on demand without waiting for manual provisioning processes. The combination of consistency and repeatability is why ARM templates became a standard tool in enterprise Azure operations.
The Structure of an ARM Template File
An ARM template is a JSON file organized into several distinct sections, each serving a specific purpose in the deployment process. The schema section identifies the version of the template language being used. The content version field allows teams to track versions of the template itself. The parameters section defines inputs that can be provided at deployment time, making the template reusable across different environments by accepting values like environment names, locations, or pricing tiers as variables rather than hardcoded strings.
The resources section is the most important part of the template. It contains an array of resource definitions, each specifying the type of Azure resource to deploy, its API version, its location, and its properties. The outputs section allows the template to return values after deployment completes, such as the connection string for a newly created database or the public IP address of a virtual machine. Understanding this structure at a high level is sufficient for the AZ-900 exam, though candidates pursuing more advanced certifications will need to develop much deeper familiarity with each section and its syntax.
Parameters and Variables in ARM Templates
Parameters are one of the features that make ARM templates flexible and reusable rather than rigid and single-purpose. By defining parameters for values that change between deployments, such as the name of a resource, the Azure region where it should be created, or the performance tier it should use, a single template can serve multiple environments without modification. At deployment time, parameter values are supplied either through a separate parameters file, through command-line arguments, or through an interactive prompt, depending on how the deployment is executed.
Variables serve a different purpose within a template. While parameters accept external input, variables store values that are calculated or derived within the template itself and reused in multiple places. For example, if a template needs to construct a storage account name by combining a prefix with a unique string, that logic can be placed in a variable and referenced throughout the template rather than duplicated in multiple resource definitions. Together, parameters and variables give templates the expressiveness needed to handle real-world deployment scenarios without becoming cluttered with repeated or hardcoded values.
How ARM Templates Differ From Manual Portal Deployments
Deploying resources through the Azure portal involves clicking through a series of configuration screens, making selections, and submitting forms. This process is intuitive for learning and well-suited for one-time tasks, but it does not scale well and leaves no automatic record of exactly what configuration choices were made. If the same environment needs to be recreated weeks later, someone must remember or reconstruct every setting, which introduces both effort and the risk of error.
ARM template deployments replace this process with a file-driven approach where every configuration choice is documented in code that can be stored, reviewed, and shared. The template file itself becomes a form of documentation that describes the infrastructure exactly as it was deployed. When something needs to change, the template is updated and redeployed rather than having someone navigate the portal and manually adjust settings. This shift from clicking to coding is what the term infrastructure as code refers to, and ARM templates are one of the primary ways Microsoft implements this practice on the Azure platform.
Deploying ARM Templates Using Different Methods
Azure provides several ways to deploy an ARM template, giving teams flexibility to choose the method that fits their workflow. The Azure portal includes a built-in template deployment experience where you can paste or upload a template file and fill in parameter values through a form interface. This method is useful for testing and learning but is less common in production environments where automation is preferred.
The Azure CLI and Azure PowerShell are the most common deployment methods in practice. A single command referencing the template file and an optional parameters file is all that is needed to initiate a deployment. These commands can be incorporated into shell scripts, build pipelines, or automation workflows, making them the natural choice for teams that want to integrate template deployments into their development and release processes. Azure DevOps and GitHub Actions both provide native support for ARM template deployments, allowing infrastructure changes to follow the same review and approval processes as application code changes.
Understanding Incremental and Complete Deployment Modes
ARM templates support two deployment modes that determine how the deployment engine handles resources that already exist in the target resource group. In incremental mode, which is the default, the deployment adds new resources and updates existing ones but leaves resources that are in the resource group but not in the template untouched. This mode is safe for most scenarios because it does not remove anything that was not explicitly included in the template being deployed.
Complete mode takes a more aggressive approach. Any resource that exists in the resource group but is not defined in the template being deployed will be deleted. This mode is useful when you want the template to be the single source of truth for everything in the resource group, ensuring that no manually created or leftover resources remain. However, it requires careful attention because accidentally deploying a template in complete mode that is missing a resource definition will result in that resource being permanently deleted. For AZ-900 candidates, understanding that these two modes exist and knowing the basic difference between them is the appropriate level of depth.
ARM Templates and Idempotency
One of the most valuable properties of ARM templates is idempotency, which means that deploying the same template multiple times produces the same result each time regardless of how many times it is run. If you deploy a template that defines a storage account and then deploy the same template again without any changes, Azure will recognize that the storage account already exists with the correct configuration and leave it unchanged rather than creating a duplicate or returning an error.
This property makes ARM templates safe to use in automated scenarios where a deployment might run repeatedly, such as in a continuous integration pipeline that deploys infrastructure as part of every build. It also makes remediation easier. If someone manually changes a resource configuration in a way that deviates from what the template defines, redeploying the template brings the resource back into the correct state. This self-correcting capability is one of the reasons infrastructure as code practices using ARM templates improve the long-term reliability and maintainability of Azure environments.
Template Specs for Storing and Sharing Templates
Template Specs are an Azure resource type that allows organizations to store ARM templates directly in Azure and share them across teams and subscriptions in a controlled way. Rather than keeping template files in a file share or source control repository and managing access separately, Template Specs are stored as Azure resources with their own access controls, versioning, and lifecycle management. Any team with appropriate permissions can reference and deploy a Template Spec without needing a copy of the underlying file.
This capability addresses a common governance challenge in larger organizations where multiple teams need to deploy infrastructure consistently but should not be able to modify the approved template definitions. A central platform engineering team can publish approved Template Specs for common infrastructure patterns, such as a virtual machine with standard security configurations or a storage account with required encryption settings, and other teams can deploy those specs without being able to alter the underlying template. This separation of authoring and consumption supports better governance without requiring a complex approval process for every deployment.
Bicep as a Modern Alternative to JSON Templates
Bicep is a domain-specific language developed by Microsoft that compiles down to ARM template JSON but offers a significantly cleaner and more readable syntax. Where ARM template JSON requires verbose syntax with deeply nested structures, Bicep achieves the same result with fewer lines of code that more closely resemble natural language. For example, declaring a parameter in Bicep takes a single concise line compared to the multi-line JSON block that ARM templates require.
For the AZ-900 exam, awareness that Bicep exists and that it is Microsoft’s recommended approach for new ARM template development is sufficient. Candidates pursuing the AZ-104 or AZ-700 certifications will need to develop practical Bicep skills, but the fundamentals exam focuses more on the concept of infrastructure as code and the role ARM templates play rather than the specific syntax differences between JSON and Bicep. Understanding that Bicep and ARM templates are closely related and that Bicep is essentially a better way to write ARM templates captures the relationship accurately for exam purposes.
ARM Templates in the Context of Azure Governance
ARM templates connect directly to Azure governance concepts that the AZ-900 exam covers in the management and governance domain. When organizations deploy infrastructure through templates, they have a natural enforcement point for governance requirements. Templates can be designed to always include specific tags on resources for cost tracking, always enable diagnostic logging, or always apply encryption settings, making compliance with organizational policies a built-in outcome of every deployment rather than something that must be verified separately after the fact.
Azure Policy can be used alongside ARM templates to enforce governance rules at the platform level, blocking or modifying deployments that do not meet defined requirements. This combination of template-driven deployments and policy enforcement creates a governance model where the risk of non-compliant infrastructure being deployed is significantly reduced compared to environments that rely on manual processes and periodic audits. For AZ-900 candidates, recognizing that ARM templates are not just a deployment convenience but also a governance tool gives a more complete picture of why Microsoft emphasizes them as a core platform capability.
Real-World Scenarios Where ARM Templates Add Value
To make the concept concrete, consider an organization that needs to set up identical development environments for ten different project teams. Without ARM templates, an administrator would spend days clicking through the portal to create virtual networks, storage accounts, virtual machines, and other resources for each team, inevitably introducing small inconsistencies along the way. With an ARM template, the administrator creates and validates the configuration once, then runs the deployment ten times with different parameter values for team names and project identifiers, completing the work in a fraction of the time with guaranteed consistency.
Another common scenario is disaster recovery preparation. Organizations that define their Azure infrastructure in ARM templates can recover from a regional outage by deploying their templates to a different Azure region, potentially in a matter of hours rather than the days or weeks a manual rebuild might require. This capability has real business continuity implications and is one of the reasons cloud architects include infrastructure as code practices as a standard component of any well-designed Azure environment. These practical applications help AZ-900 candidates connect the technical concept to the business value it delivers.
Conclusion
ARM templates occupy an important place in the AZ-900 exam not because the fundamentals certification requires deep technical implementation skills, but because they represent a concept that runs through the entire philosophy of modern cloud infrastructure management. The ideas behind ARM templates, consistency, repeatability, idempotency, and infrastructure as code, are ideas that appear across every level of Azure certification and across every serious discussion of how to operate cloud environments responsibly and efficiently.
For candidates sitting the AZ-900 exam, the goal is to leave with a clear understanding of what ARM templates are, what problems they solve, and how they connect to broader Azure management and governance topics. That level of understanding is genuinely achievable through the combination of reading, watching demonstrations, and spending a small amount of time in the Azure portal exploring the template deployment experience firsthand. Even without writing a single line of JSON, seeing a template file, recognizing its structure, and watching a deployment complete gives you the intuitive familiarity that makes exam questions on this topic feel straightforward rather than abstract.
For those who go beyond the AZ-900 and pursue associate or expert level certifications, the knowledge built here becomes the foundation for much deeper work with Bicep, Template Specs, deployment pipelines, and governance automation. The professionals who invest time in genuinely understanding infrastructure as code early in their Azure learning journey consistently find that it accelerates their progress across every other domain they study. ARM templates are not a niche topic for specialists. They are a core capability of the Azure platform that every cloud professional benefits from knowing well, and starting that knowledge with the AZ-900 is exactly the right place to begin.