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 Microsoft AZ-900, ARM templates belong to the management and governance objectives: the July 20, 2026 skills outline explicitly includes infrastructure as code, Azure Resource Manager and ARM templates. The fundamentals exam asks candidates to describe their purpose rather than to author a production-ready deployment from scratch. Learn how a declarative resource definition differs from a sequence of portal clicks, where resource groups and subscriptions fit into deployment, and why version control matters. The current AZ-900 exam scope should guide study priorities instead of older detailed deployment checklists.
Why Organizations Choose ARM Templates for Deployments
Consistent deployments are a practical reason to describe infrastructure in code. A team can review a storage account’s encryption, networking and tags before deploying it to development and production. However, templates do not automatically eliminate configuration drift: changes made outside the template, differences in permissions and service defaults can still affect resources. Teams need source control, peer review, policy checks and periodic validation to establish whether the deployed environment actually matches its intended configuration. Infrastructure as code reduces manual repetition only when it is maintained as a trusted operational process.
A reusable template can support multiple resource groups, subscriptions or regions when its parameters, resource dependencies and access rights are designed for those scopes. Names may require a unique suffix, some service features vary by region, and subscriptions have quotas and policy restrictions. Reusing a file therefore does not guarantee that every environment will deploy identically. For disaster recovery, a declarative infrastructure definition is helpful, but recovered services also need data restoration, networking, identity, secrets and validation. Repeatability should be demonstrated through tests rather than assumed from the mere existence of a JSON file.
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 declares Azure resource types, compatible API versions, names, locations, dependencies and properties. Outputs can return nonsecret values such as a resource ID or endpoint needed by a later deployment stage. Avoid outputting passwords, storage account keys or connection strings that include secrets, because deployment history and logs can expose output values to authorized readers. The template’s structure is useful at a conceptual level for AZ-900; production authors must also verify schema and API behavior for the specific resource provider and deployment scope.
Parameters and Variables in ARM Templates
Parameters let the same deployment definition accept controlled differences between environments, such as region, approved SKU, resource name or application settings. Provide parameters through a secure deployment workflow or a parameter file whose sensitive values are not committed to source control. Passwords and keys should use supported secure parameter mechanisms and an approved secrets service where appropriate. Parameterization does not exempt resources from Azure Policy or quota checks. Before deploying, validate the values against the environment and review which defaults might change a resource unexpectedly.
Variables are expressions computed within an ARM template, whereas parameters represent values supplied to a deployment. Teams may use variables to build a naming convention or reuse an expression that depends on a region and an environment prefix. A function that produces a deterministic unique string can help avoid some naming collisions, but it does not guarantee global uniqueness for arbitrary inputs or satisfy every Azure resource naming rule. Keep expressions understandable and avoid using variables as a substitute for managing sensitive data securely.
How ARM Templates Differ From Manual Portal Deployments
Manual Azure portal provisioning is useful when exploring a new resource because it exposes configuration options and service information. It is not correct to say the portal leaves no audit record: Azure Activity Log and deployment history can record relevant management operations, subject to retention and permissions. What portal clicks generally lack is a complete, version-controlled, reviewable description of the desired infrastructure state. Teams moving from exploration to repeatable deployment should export or author an appropriate template, examine what it includes, and avoid treating the exported configuration as automatically production ready.
Declarative Azure ARM template deployments can be stored alongside application code, reviewed through pull requests and executed by an authorized deployment identity. That creates a repeatable record of intended resource definitions, but the committed file is not proof of the live state after later manual changes. Review resource differences using the ARM what-if operation and maintain a recovery plan for failed deployments. This distinction between intended configuration, approved changes and actual deployed resources is central to responsible infrastructure as code.
Deploying ARM Templates Using Different Methods
Azure supports deploying ARM JSON templates through the portal, Azure CLI, Azure PowerShell and supported automated delivery systems. Each method submits a deployment to the Azure Resource Manager control plane, with parameters and an appropriate target scope. A successful command requires access to the resource types and deployment operations involved; simply possessing a JSON file is not enough. In a learning subscription, a safe first step is to validate a minimal template and preview its proposed changes before creating billable resources.
Azure CLI and PowerShell can place deployments into a reviewed automation pipeline, including Azure DevOps or GitHub Actions workflows. Service connections or federated identities should receive only the required permissions, and pipeline configuration should avoid embedding secrets in source files or output logs. A deployment may still fail because of Azure Policy, a region-specific limitation, a naming conflict or quota restrictions. Check the returned deployment operations rather than treating the absence of an immediate command error as proof that infrastructure has been correctly configured.
Understanding Incremental and Complete Deployment Modes
Incremental mode is the default Azure Resource Manager deployment mode. It ordinarily leaves unrelated resources outside the template in place, while it creates or updates the resources declared inside the template. However, ‘incremental’ does not mean applying only the properties explicitly changed by the author: when a resource is redeployed, properties omitted from the definition can be reset to default values. Include all intended nondefault properties and examine the preview of the effective change, especially for networking, identity and data protection settings.
Complete mode is a legacy deployment behavior in which resources missing from the submitted resource-group template may be deleted. Microsoft now warns against choosing it for resource deletion and says it will be gradually deprecated; deployment stacks are the recommended approach where managed resource deletion is required. Do not present complete mode as a convenient production cleanup technique. Run what-if to preview potential creates, changes and deletions, obtain the right approvals and protect dependent data. For AZ-900, recognizing the contrast with incremental mode is enough; implementation safeguards belong to advanced operations work.
ARM Templates and Idempotency
Declarative deployments aim for idempotency: applying the same desired configuration more than once should not create a new copy of each resource. In practice, that expectation depends on stable resource names, correct scope, supported API behavior and unchanged inputs. A redeployment can update properties, fail validation or be affected by external changes, policies and locks. Test a harmless repeat deployment before relying on an automation workflow. Idempotency is a design property worth understanding, not a blanket guarantee that every rerun is safe or free of side effects.
When drift appears, redeploying the intended template may correct supported properties, but it can also overwrite an approved emergency change or fail because a resource is locked. A responsible team should compare the desired and live configurations, investigate who changed them, and decide whether to reconcile or update the source of truth. The ARM what-if operation is useful for previewing potential changes without applying them. Deployment history, Azure Policy evaluations and monitoring can provide additional evidence, although they serve different purposes and cannot be substituted for one another.
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 Microsoft’s concise declarative language for creating Azure deployments. Its compiler produces ARM template JSON, allowing authors to work with resource definitions, parameters, modules and expressions using a syntax that is usually easier to review than large nested JSON files. It does not replace Azure Resource Manager itself or eliminate role-based permissions, policy restrictions and resource provider limits. For an introduction, the key relationship is that ARM remains the deployment engine while Bicep is another authoring format for expressing the resources to deploy.
Microsoft recommends Bicep for many new Azure infrastructure-as-code projects because it improves readability and supports modules and tooling, while ARM JSON templates remain supported. AZ-900’s July 2026 guide explicitly names Azure Resource Manager and ARM templates under management and governance, not a requirement to write Bicep expressions. A fundamentals candidate should understand declarative deployment and recognize the relationship between the two formats. A learner pursuing a technical administrator or engineering role can then practice authoring, validating and deploying a small Bicep file in a controlled environment.
ARM Templates in the Context of Azure Governance
ARM templates can set desired tags, diagnostic settings or resource properties, but a template by itself does not establish continuing compliance. Azure Policy can audit, deny or modify certain resource configurations according to assigned policy definitions, and role-based access control limits who can perform deployments. The policy’s actual effect depends on its assignment, effect, scope and exemptions. A governance-minded team should verify those controls and record evidence of enforcement. No declaration of ‘secure by default’ should replace an inspection of the deployed resource and its applicable policies.
A template is one piece of a governed Azure resource architecture. Resource groups, subscriptions and management groups define organizational and permission boundaries; tags can support cost reporting; resource locks can discourage accidental changes; Azure Policy can assess or constrain selected configurations. A deployment identity still needs the relevant privileges, and its permissions should be scoped appropriately. These controls work together rather than being guaranteed by a template. For AZ-900, recognizing the role of each helps explain why governance remains separate from the mechanics of provisioning a resource.
Real-World Scenarios Where ARM Templates Add Value
Suppose a platform team provisions development environments for several projects. An ARM template or Bicep module can define a standard storage account and virtual network, with controlled parameters for project identification and allowed regions. Before each deployment, the team should validate input, review the what-if output, check quotas and ensure naming conventions do not collide. Afterward, it should inspect the resulting resource properties and record costs. Repeatable configuration can improve delivery speed, but time savings and exact equivalence must be measured rather than promised.
For disaster recovery, infrastructure definitions can speed the recreation of certain services in another approved region. They are not a replacement for backups, data replication, secrets management, identity setup, DNS cutover or application-level recovery testing. A template that recreates an empty database or storage account does not restore the business information previously stored there. Recovery planning should state its recovery time and recovery point goals and test the complete workflow. ARM templates are useful building blocks in this process, but the overall continuity result depends on systems beyond resource deployment.
Conclusion
Azure Resource Manager templates illustrate several fundamentals in the AZ-900 management and governance domain: declarative infrastructure as code, repeatability, resource hierarchy and authorized resource deployment. The July 2026 published objectives require candidates to describe those tools, not prove competence as a production infrastructure engineer. Distinguish ARM’s control plane from the JSON or Bicep files that express desired resources, and know why policies, permissions, tags, locks and monitoring complement deployments. This conceptual model is more helpful for a fundamentals exam than memorizing long command-line syntax.
A useful first exercise is to inspect an ARM template that creates a modest Azure resource, identify its parameters and outputs, then run validation or what-if using a test subscription and appropriate permissions. Read the predicted result before deciding whether to deploy. If you create resources, check applicable charges and delete them safely after the exercise. The hands-on goal is not to build an expensive environment; it is to understand what declarative configuration expresses, how the Azure control plane processes it and what evidence verifies the resulting state.
Beyond AZ-900, practical infrastructure work requires deeper understanding of deployment scopes, conditions, modules, pipeline identities, naming rules, resource locks, policy enforcement and failure recovery. Bicep and Template Specs can help standardize approved definitions, while a controlled CI/CD process can require review before publication. These methods are valuable when they solve a genuine operational problem. Students should build on the fundamentals with permitted small-scale projects and the appropriate official documentation rather than assuming that familiarity with an ARM template alone guarantees broader cloud-engineering readiness.