SkarpChapter 16 of 20
Infrastructure as Code on Azure: ARM Templates and Bicep Fundamentals
See how Azure resources can be defined as code using templates and Bicep so that environments become repeatable, testable, and version-controlled.
Big Picture: Infrastructure as Code on Azure
From Clicks to Code
You have seen how to manage Azure with the portal, CLI, and PowerShell. Infrastructure as Code (IaC) is the next step: managing your environment using code files instead of manual clicks.
Azure Resource Manager at the Center
Azure Resource Manager (ARM) is the deployment and management layer for Azure. Every request to create or manage resources flows through ARM, no matter which tool you use.
Focus for AZ-900
For AZ-900, you must recognize what ARM templates and Bicep are, why declarative templates matter, and when IaC is preferred over portal-based configuration.
Azure Resource Manager (ARM) Fundamentals
What ARM Is
Azure Resource Manager is the deployment and management service for Azure. It gives you a consistent management layer to create, update, and delete resources.
Resources and Resource Groups
A resource is an individual Azure service instance. A resource group is a logical container that holds related resources for a solution or workload.
Same ARM, Different Tools
Portal, CLI, PowerShell, ARM templates, and Bicep all call the same ARM API. That is why RBAC, Azure Policy, and locks behave consistently across tools.
Declarative vs Imperative: How IaC Describes Azure
Imperative vs Declarative
Imperative scripts say how to do something step by step. Declarative templates describe what the final environment should look like, and the platform figures out how.
Declarative on Azure
ARM templates and Bicep are declarative. You define resources and their properties; Azure Resource Manager plans and executes the deployment.
Why Declarative Matters
Declarative IaC is repeatable, testable, and version-controlled. It helps you safely reproduce environments across dev, test, and production.
ARM Templates: JSON-Based Infrastructure Definitions
What Is an ARM Template?
An ARM template is a JSON file that defines one or more Azure resources and their configurations. It is the native template format for Azure Resource Manager.
Key Sections
Common sections: schema, contentVersion, parameters, variables, resources, outputs. The resources section lists the Azure resources to deploy.
Why Use ARM Templates?
ARM templates are declarative, idempotent, and version-controllable, making them ideal for repeatable, standardized Azure deployments.
ARM Template: A Minimal Example
Look at this simplified ARM template that deploys a storage account. You do not need to memorize it, but notice the JSON structure and key sections.
Bicep: A Friendlier Language That Compiles to ARM
What Is Bicep?
Bicep is a domain-specific language for deploying Azure resources declaratively. It is a higher-level, more human-readable language than ARM JSON.
How Bicep Relates to ARM
You write Bicep files, which are compiled into ARM templates. Azure Resource Manager executes the compiled ARM JSON, not the Bicep source directly.
Why Use Bicep?
Bicep offers cleaner syntax, better tooling support, and reusable modules, making it easier to author and maintain Azure Infrastructure as Code.
Bicep vs ARM: Side-by-Side Feel
Here is a simple Bicep file that does the same job as the earlier ARM JSON: deploy a storage account. Notice how much shorter and more readable it is.
Real-World Scenario: Repeatable Environments with Bicep
The Project Team Problem
Your team needs identical dev, test, and demo environments. Manually creating resources in the portal is error-prone and inconsistent.
Using Bicep for Repeatability
One teammate writes a Bicep file describing the full environment. Everyone deploys the same template with different parameters for each environment.
Governance Plus IaC
Combine Bicep with Azure Policy and locks to enforce allowed SKUs and protect critical environments from accidental deletion.
Thought Exercise: Portal vs CLI vs ARM vs Bicep
Work through these scenarios and decide which Azure management approach fits best. There are no single "correct" answers, but the reasoning will train your exam instincts.
- One-time experiment
- You want to quickly try a new PaaS database service for a lab, and you are not sure you will keep it.
- Question: Would you use the portal, CLI/PowerShell, or ARM/Bicep? Why?
- Monthly training labs
- Every month, 30 students need identical lab environments (same resource group layout, same services, same SKUs).
- Question: Which tool makes it easiest to recreate those environments reliably? How would you store and share the configuration?
- Production baseline
- Your company wants every new project to start from a standard "landing zone" with networks, monitoring, and policies.
- Question: Which approach best guarantees that every project starts from the same baseline, and how does that tie into Azure Policy and locks?
- Small configuration tweak
- You need to quickly change the pricing tier for a single App Service in a non-critical dev environment.
- Question: Would you edit a template, run a CLI command, or just use the portal?
Pause and answer these in your own words. Then compare:
- For repeatable, standardized, multi-resource deployments, ARM templates or Bicep are usually best.
- For quick, ad-hoc changes or experiments, the portal or CLI is often enough.
Being able to articulate this trade-off is exactly what AZ-900 questions will test.
Quiz 1: ARM and Declarative Templates
Check your understanding of Azure Resource Manager and declarative IaC.
Which statement best describes how Azure Resource Manager (ARM) works with ARM templates and Bicep?
- ARM executes Bicep files directly, and the portal converts them into JSON only for display.
- ARM is the deployment and management service that receives compiled ARM templates (from JSON or Bicep) and uses them to create or update resources declaratively.
- ARM is only used by the Azure portal; CLI and PowerShell bypass ARM when using templates.
- ARM is a legacy deployment model that has been fully replaced by Bicep.
Show Answer
Answer: B) ARM is the deployment and management service that receives compiled ARM templates (from JSON or Bicep) and uses them to create or update resources declaratively.
Azure Resource Manager is the deployment and management service for Azure. Whether you author templates in raw JSON or in Bicep, they are ultimately compiled to ARM templates that ARM processes declaratively. The portal, CLI, and PowerShell all call ARM; Bicep is not a replacement for ARM but a higher-level language that targets it.
Quiz 2: When to Prefer IaC
Apply what you know about when ARM templates or Bicep are the best choice.
Your team needs to deploy the same three-tier web application environment (front end, API, database) to development, test, and production, ensuring they stay consistent over time. Which approach best meets this requirement?
- Have each developer create the resources manually in the portal following a written checklist.
- Use Azure CLI interactively each time to create the resources, copying commands from a shared document.
- Create an ARM template or Bicep file that defines all required resources and deploy it with different parameters for each environment.
- Rely only on Azure Policy to automatically create any missing resources when needed.
Show Answer
Answer: C) Create an ARM template or Bicep file that defines all required resources and deploy it with different parameters for each environment.
Defining the environment in an ARM template or Bicep file gives you a declarative, repeatable, and version-controlled way to deploy the same infrastructure across multiple environments. Manual portal work and ad-hoc CLI commands are error-prone, and Azure Policy enforces rules but does not by itself define and deploy complete application stacks.
Key Term Flashcards: ARM, ARM Templates, Bicep
Use these flashcards to reinforce the core concepts for AZ-900.
- Azure Resource Manager (ARM)
- Azure Resource Manager is the deployment and management service for Azure that provides a consistent management layer to create, update, and delete resources across tools like the portal, CLI, PowerShell, ARM templates, and Bicep.
- Resource group
- A resource group is a logical container in Azure that holds related resources for an application or workload and allows you to deploy, manage, and delete them together.
- Declarative Infrastructure as Code
- A declarative IaC approach describes the desired final state of your infrastructure (which resources and configurations should exist) rather than specifying the exact sequence of steps to create them.
- ARM template
- An ARM template is a JSON file that defines one or more Azure resources and their configurations declaratively, using sections like parameters, variables, resources, and outputs.
- Bicep language
- Bicep is a higher-level, more human-readable domain-specific language for Azure that compiles to ARM templates, making it easier to author and maintain declarative infrastructure definitions.
- Idempotent deployment
- An idempotent deployment is one where running the same template or configuration repeatedly results in the same infrastructure state, without unintended side effects.
- Relationship: Bicep and ARM templates
- You author infrastructure in Bicep files, which are compiled into ARM templates (JSON). Azure Resource Manager processes the ARM template, not the Bicep source, during deployment.
- When to prefer ARM/Bicep over the portal
- Prefer ARM templates or Bicep when you need repeatable, consistent, multi-resource deployments that can be version-controlled and reused across environments.
Connecting IaC with Governance and Exam Strategy
IaC + Policy + Locks
Use ARM/Bicep to define infrastructure, Azure Policy to enforce rules, and resource locks to protect critical resources from accidental changes.
Typical Exam Signals
Repeatable, version-controlled deployments across environments point to ARM templates or Bicep. Enforcing standards points to Azure Policy; preventing deletion points to locks.
Your Next Steps
Your Skarp diagnostic and mock exams will test these ideas. Missed items feed into spaced review and a gap guide for deeper follow-up.
Key Terms
- Bicep
- Bicep is a higher-level, more human-readable domain-specific language for Azure that compiles to ARM templates, making it easier to author and maintain declarative infrastructure definitions.
- ARM template
- An ARM template is a JSON file that defines one or more Azure resources and their configurations declaratively, using sections like parameters, variables, resources, and outputs.
- Azure Policy
- Azure Policy is a service in Azure that you use to create, assign, and manage policies that enforce rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements.
- Resource lock
- A resource lock is a setting applied to an Azure resource or resource group (Read-only or Delete) that helps prevent accidental modification or deletion, even by users with permissions.
- Resource group
- A resource group is a logical container in Azure that holds related resources for an application or workload and allows you to deploy, manage, and delete them together.
- Idempotent deployment
- An idempotent deployment is one where running the same template or configuration repeatedly results in the same infrastructure state, without unintended side effects.
- Azure Resource Manager (ARM)
- Azure Resource Manager is the deployment and management service for Azure that provides a consistent management layer to create, update, and delete resources across tools like the portal, CLI, PowerShell, ARM templates, and Bicep.
- Role-based access control (RBAC)
- Role-based access control (RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of Azure resources based on roles assigned to users, groups, and service principals.
- Declarative Infrastructure as Code
- A declarative IaC approach describes the desired final state of your infrastructure (which resources and configurations should exist) rather than specifying the exact sequence of steps to create them.