Azure Resource Manager Overview

Azure operations are classified into two main types: control plane and data plane. The control plane helps you manage resources in your subscription, while the data plane allows you to access the capabilities provided by instances of specific resource types.

Control Plane

Azure Resource Manager manages essential functions, such as template-based deployments, role-based access control (RBAC), auditing, monitoring, and tagging, which provides a unified management experience for Azure resources after deployment. When you send a control plane request through any of the Azure APIs, tools, or SDKs, Azure Resource Manager receives the request. All capabilities that are available in the portal are also available through PowerShell, Azure CLI, REST APIs, and client SDKs. These tools use the same API to process requests, ensuring uniform results and capabilities. The Resource Manager authenticates and authorises the request before forwarding it to the appropriate Azure resource provider that completes the operation.

Data Plane

The data plane is where the actual data operations occur, and Azure Policy ensures that the resources you interact with in the data plane are compliant with your policies. Data plane operations involve direct interaction with the data stored in a resource. Data plane operations aren't limited to the REST API — requests are made directly to the data endpoints of services (for example, accessing data in Azure Storage, querying a SQL database, or reading secrets from Azure Key Vault). Each Azure service handles these requests internally, bypassing Azure Resource Manager, and directly managing the data through its resource provider. Service-specific access controls, such as RBAC or access control lists (ACLs), often manage data plane permissions. The service responds with the data or result of the data operation, ensuring that the requester has the correct permissions.

Greenfield and Brownfield Scenarios

Azure Resource Manager includes two scenarios for handling Azure requests: Greenfield and Brownfield. As you deploy resources, Azure Resource Manager understands when to create new resources and when to update existing resources. Greenfield refers to a scenario where an Azure Policy (policy-first) exists, and when you're creating or updating an Azure resource. In Azure Resource Manager, the request goes through different layers, including role-based access control (RBAC) and Azure Policy. These are only two of many layers involved, but it's important to understand that Azure Policy comes after RBAC: if you don't have permissions to run a given operation, Azure Policy isn't considered or called, because the request would already fail at the RBAC stage. If you have permissions, the request goes through Azure Policy and is evaluated against any assigned policy. Brownfield is the scenario where the resources already exist (resource-first), and you're assigning a new Azure Policy to those resources.

Azure Resource Manager (ARM) Templates

Azure Resource Manager (ARM): The deployment and management layer for Microsoft Azure. All resource deployments, regardless of interface (portal, SDK, REST API), are processed through ARM.
ARM Templates: JSON files that define the resources to be deployed. They provide a declarative way to define infrastructure, promoting consistency and repeatability.
Template Structure: ARM templates consist of properties like $schema, parameters, variables, resources, and outputs. These properties define the template's configuration, input parameters, and resulting outputs. To pass an array as an inline parameter during the deployment of a local template, you should provide the array values via the --parameters switch in the deployment command. Otherwise, upload them separately.
Template Specs: A first-class Azure resource type that encapsulates ARM templates and associated parameters. They offer improved version control, sharing, and access control compared to traditional templates, and are the recommended approach moving forward.
Declarative vs. Imperative: Both Bicep and ARM templates are declarative — they define the desired state of the infrastructure, and Azure Resource Manager figures out how to achieve that state. This contrasts with imperative approaches, where you explicitly specify the exact steps to be taken.
Idempotency: In the context of ARM templates, idempotency means that applying the same template multiple times has the same effect as applying it once. ARM templates achieve this by comparing the desired state in the template against the current state of existing resources with matching names and properties, before creating or modifying them. This is critical for reliable automation and preventing unintended changes: running the same template twice, with no changes to its content, means Azure Resource Manager makes no changes to the already-deployed resources.
Bicep: Bicep is a domain-specific language (DSL) created by Microsoft designed to simplify the creation of ARM templates. It provides a more human-readable, concise syntax with features like parameters, variables, and modularity, and compiles to an ARM template at deployment time.
Compilation: The process of converting a Bicep file into an ARM template for deployment to Azure.
Decompilation: The reverse process of compilation — converting an ARM template (JSON) into a Bicep file. This is possible because Bicep is designed to be largely compatible with ARM template functionality.

Template Elements

ARM template files are made up of the following elements:

Element	Description
`$schema`	A required section that defines the location of the JSON schema file that describes the structure of the JSON data. The version number you use depends on the scope of the deployment and your JSON editor.
`contentVersion`	A required section that defines the version of your template (such as `1.0.0.0`). You can use this value to document significant changes in your template to ensure you're deploying the right one.
`apiProfile`	An optional section that defines a collection of API versions for resource types, so you don't have to specify an API version for each resource in the template.
`parameters`	An optional section where you define values that are provided during deployment. You can provide these values in a parameter file, via command-line parameters, or in the Azure portal.
`variables`	An optional section where you define values used to simplify template language expressions.
`functions`	An optional section where you can define user-defined functions available within the template. These can simplify your template when complicated expressions are used repeatedly.
`resources`	A required section that defines the actual items you want to deploy or update in a resource group or subscription.
`outputs`	An optional section where you specify the values that are returned at the end of the deployment.

A template is also subject to some hard limits: 256 parameters, 512 variables, 800 resources (including copy count), and 64 output values.

Sensitive Data in Templates

Sensitive information like passwords or secrets — such as a domainPassword — should be placed in a resource's protectedSettings section rather than its plain settings. This applies specifically to VM extensions (for example, the Custom Script Extension or DSC), and ensures the sensitive values are securely encrypted and not exposed in plaintext when the deployment or resource is viewed or logged.

Deploying an ARM Template

You can deploy an ARM template to Azure in one of the following ways:

Deploy a local template.
Deploy a linked template: Use linked templates to deploy complex solutions. You can break a template into many templates and deploy them through a main template — when you deploy the main template, it triggers the linked templates' deployment. You can store and secure a linked template using a SAS token.
Deploy in a continuous deployment pipeline: A CI/CD pipeline automates the creation and deployment of development projects, including ARM template projects. The two most common pipelines used for template deployment are Azure Pipelines or GitHub Actions.

ARM Template Parameters

ARM template parameters let you customize a deployment by providing values tailored to a particular environment — for example, passing in different values depending on whether you're deploying to development, test, or production. For instance, if a template uses the Standard_LRS storage account SKU, you can reuse that template for other deployments by making the SKU name a parameter, then passing in the SKU you want at deployment time, either at the command line or via a parameter file.

In the parameters section of the template, you specify which values can be supplied when you deploy the resources. Parameter definitions can use most template functions.

Deploying ARM Templates Programmatically

You can use the -TemplateUri parameter to specify a web-based location, such as GitHub or an Azure Blob Storage account. You can use -TemplateFile to specify a local file. You can use -TemplateSpecId to specify a template that was saved to Azure as a template spec.

Uploading a template and parameters to Cloud Shell: Transfer the template.json and parameters.json files from your local machine to Azure Cloud Shell using the Cloud Shell upload feature (the icon with up/down arrows). The ARM template and parameters file need to be accessible within the Cloud Shell environment to initiate the deployment.

Verifying resource restoration: Refresh the resource group in the Azure portal to confirm that a deleted virtual machine and its associated resources have been restored without conflict. This verifies that the idempotency of the ARM template deployment worked as expected — the previously deleted resources are recreated, demonstrating the ability to restore infrastructure using the same template.

Getting a template from an existing deployment: Use the Save-AzResourceGroupDeploymentTemplate cmdlet to retrieve the template used for a specific past deployment in a resource group. You can then redeploy it with the New-AzResourceGroupDeployment cmdlet. If instead you want a template reflecting the current live state of a resource group (including any manual changes made since the original deployment), use Export-AzResourceGroup — these are two different jobs and pull from two different sources.

Save-AzDeploymentScriptLog is used to save the log of a deployment script execution to disk; the related Get-AzDeploymentScriptLog retrieves it without saving, and Remove-AzDeploymentScript cleans up a deployment script and its supporting resources.

Decompiling ARM Templates to Bicep

Decompile using Azure CLI: Initiate the decompilation process from the command line:

az bicep decompile --file <path_to_arm_template.json>

This command uses the az bicep decompile function to convert the specified ARM template JSON file into a corresponding Bicep file. The output Bicep file is created in the same directory as the original ARM template.

Decompile using VS Code.

Common Issues and Troubleshooting

Template Validation Errors: If the ARM template is malformed or doesn't adhere to the schema, deployment will fail. Solution: Use the Azure portal or Azure CLI to validate the template before deploying.
Parameter Mismatches: If the provided parameters don't match the defined parameters in the template, deployment will fail. Solution: Double-check the parameter names and data types in the template and ensure the provided values are correct.
Resource Dependencies: If a resource depends on another resource that hasn't been created yet, deployment will fail.
Long Deployment Times: Complex templates with many resources can take a long time to deploy.
Lack of Parameter File Import: The Azure portal doesn't currently offer a built-in feature to import a parameter file for ARM template deployments via Template Specs. Solution: Manually copy and paste parameter values from the JSON file into the deployment form. This is a known limitation.
IP Address Dependency Removed: The instructor notes that the IP address is no longer a dependency within the template. Explanation: This change likely reflects an update to the template, moving away from hardcoded or dependent IP addresses for greater flexibility and dynamic allocation.
Preview Features: If the ARM template uses preview features, ensure those features are also available and supported within Bicep before deploying the generated Bicep file.
Error Messages: If the decompilation process fails, pay close attention to any error messages, which typically provide clues about where to start troubleshooting. Common causes include incorrect file paths or invalid JSON formatting in the ARM template.