Discovering Azure Resource Manager

• Structured Summary + Deep Technical Understanding

Primary service:

• Azure Resource Manager

Official documentation:

1️⃣ What Are ARM Templates?#

ARM Templates are:

✔ JSON files ✔ Used for Infrastructure as Code (IaC) ✔ Declarative deployment model ✔ Processed by Azure Resource Manager

They define what your infrastructure should look like — not how to build it step-by-step.

🔹 High-Level Flow#

• ARM Template (JSON) → Submitted to Azure Resource Manager → ARM validates against schema → ARM identifies required Resource Providers → Resources deployed

Example resource types:

• Microsoft.Compute/virtualMachines
• Microsoft.Network/virtualNetworks
• Microsoft.Storage/storageAccounts

2️⃣ Why Use ARM Templates?#

🔹 Core Benefits#

✔ Repeatable deployments ✔ Consistent environments ✔ Automation-ready ✔ Faster recovery ✔ Reduced manual errors ✔ Version-controlled infrastructure

🔹 Real-World Use Case#

Hub-and-Spoke Network Topology:

Instead of manually building:

• VNets
• Subnets
• NSGs
• Route tables
• Peering
• You codify it once → deploy everywhere.
• Dev/Test/Prod can use same template.

3️⃣ Deployment Scopes#

ARM Templates can deploy at:

• Resource Group scope (most common)
• Subscription scope
• Management Group scope
• Tenant scope
• Most basic examples use Resource Group scope.

Docs:

4️⃣ ARM Template Structure (Critical for Exams)#

An ARM template contains structured sections.

🔹 1. $schema (Mandatory)#

Defines:

• Template schema version
• Validation rules
• IntelliSense behavior

Example:

• "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#"

Important:

• Date = schema version
• deploymentTemplate = resource group scope

🔹 2. contentVersion (Mandatory)#

Example:

• "contentVersion": "1.0.0.0"

Purpose:

• Manual template versioning
• Rarely used heavily in real-world
• Git usually handles versioning

🔹 3. parameters (Optional but Powerful)#

Used to:

• ✔ Pass values at deployment time ✔ Make templates reusable ✔ Customize per environment

Example:

• "parameters": {
• "environmentName": {
• "type": "string"
• }
• }

Use cases:

• Dev → dev-webapp Test → test-webapp Prod → prod-webapp
• Same template, different inputs.

Parameter File Example#

Separate file:

• {
• "parameters": {
• "environmentName": {
• "value": "dev"
• }
• }
• }
• Used in CI/CD pipelines.

5️⃣ Built-in vs User-Defined Functions#

ARM supports:

🔹 Built-in Functions#

Examples:

• resourceGroup()
• subscription()
• concat()
• parameters()
• variables()
• uniqueString()

Docs:

🔹 User-Defined Functions (Optional Section)#

Used when:

• Complex logic needed
• Combining multiple built-in functions

Defined under:

• "functions": []
• Less common in basic deployments.

6️⃣ Variables Section#

Variables:

• ✔ Reusable values ✔ Reduce repetition ✔ Improve readability

Example:

• "variables": {
• "location": "eastus"
• }

Or dynamic:

• "variables": {
• "storageAccountName": "[concat('stor', uniqueString(resourceGroup().id))]"
• }

Variables improve:

• Maintainability
• Template clarity

7️⃣ Resources Section (Core of Template)#

• This is the most important section.

Defines:

• ✔ Resource type ✔ API version ✔ Name ✔ Location ✔ Properties ✔ Dependencies

Example:

• "resources": [
• {
• "type": "Microsoft.Storage/storageAccounts",
• "apiVersion": "2022-09-01",
• "name": "[parameters('storageName')]",
• "location": "[resourceGroup().location]",
• "properties": {}
• }
• ]
• Multiple resources can be deployed in one template.

🔹 Dependency Management#

ARM automatically:

• ✔ Detects dependencies ✔ Orders deployment

Or you can explicitly define:

• "dependsOn": []

8️⃣ Outputs Section (Optional but Useful)#

Used to:

• ✔ Return values after deployment ✔ Feed values into pipelines ✔ Chain deployments

Example:

• "outputs": {
• "storageAccountName": {
• "type": "string",
• "value": "[variables('storageAccountName')]"
• }
• }

Common in:

• CI/CD
• Automation
• DevOps workflows

9️⃣ Deployment Modes#

Two deployment modes:

🔹 Incremental (Default)#

Adds/updates resources defined in template Does NOT delete unspecified resources

🔹 Complete#

• Deletes resources not defined in template
• ⚠ Complete mode can remove resources.

Docs:

🔟 Declarative vs Imperative Model#

• ARM Templates are Declarative.

You define:

• Desired state.

ARM figures out:

• Execution order.

Unlike:

• Azure CLI scripts → Imperative (step-by-step).

1️⃣1️⃣ ARM vs Bicep#

• ARM = JSON (verbose) Bicep = Simplified DSL that compiles to ARM

Modern best practice:

• Use Bicep instead of raw ARM.

Docs:

1️⃣2️⃣ Common Exam Pitfalls#

🚩 ARM Templates are imperative → False 🚩 Schema section is optional → False 🚩 Parameters are mandatory → False 🚩 Resources section optional → False 🚩 Outputs required → False 🚩 ARM Templates manage data plane → False

1️⃣3️⃣ Real-World Deployment Example#

Scenario:

Deploy:

• VNet
• Subnets
• VM
• NSG
• Storage account

All defined in:

• Single ARM template.

Benefits:

• ✔ One-click deployment ✔ Dev/Test/Prod reuse ✔ Disaster recovery ready ✔ Git-controlled infrastructure

1️⃣4️⃣ Infrastructure as Code (IaC) Philosophy#

Advantages:

✔ Version control ✔ Auditable changes ✔ CI/CD integration ✔ Reduced configuration drift ✔ Faster environment recreation

1️⃣5️⃣ Mental Model#

Think of ARM template as:

• Blueprint of infrastructure.

You define:

• Inputs (parameters)
• Internal logic (variables/functions)
• Resources
• Outputs
• ARM enforces structure via schema.

1️⃣6️⃣ Final Key Takeaways#

• ✔ ARM Templates = JSON Infrastructure as Code ✔ Declarative model ✔ Repeatable deployments ✔ Schema validates template ✔ Parameters enable reuse ✔ Resources define infrastructure ✔ Outputs enable automation ✔ Deployable at multiple scopes

ARM templates are foundational for:

• AZ-104
• AZ-204
• AZ-305
• DevOps
• Cloud architecture

If you'd like next:

• 🧠 30 ARM template exam questions
• 📄 Full annotated ARM template example
• 🔄 ARM vs Bicep comparison deep dive
• 🚀 CI/CD pipeline example using ARM
• 🏗 Multi-resource production deployment template
• Tell me your goal.