Use ARM Templates and Bicep Deployment Workflows for AZ-104

AZ-104 does not expect you to be a full-time infrastructure engineer, but it does expect you to read and adjust deployment definitions without getting lost. That is why ARM templates and Bicep appear in the official study guide.

What Microsoft explicitly tests

The core tasks are interpreting a template or Bicep file, modifying existing files, deploying resources, and exporting a deployment as an ARM template or converting an ARM template to Bicep. In other words, you need to understand deployment structure well enough to review, tweak, and execute it safely.

Objective coverage inside this page

This lesson is responsible for the full ARM/Bicep objective group:

• interpret an ARM template or Bicep file
• modify an existing ARM template
• modify an existing Bicep file
• deploy resources by using ARM or Bicep
• export a deployment as ARM or convert ARM JSON to Bicep

That makes this page less about memorizing syntax and more about recognizing the full admin workflow from inspection through safe rollout.

The right level of understanding

Know how parameters, variables, resources, outputs, and dependencies affect the result. Also understand the difference between an authored deployment file and a portal-exported template. Exported templates can help you inspect what Azure built, but they are not always the cleanest starting point for repeatable operations.

ARM versus Bicep in exam terms

If a question asks which format is better for ongoing authoring, Bicep is usually the cleaner operational answer. If it asks what Azure Resource Manager ultimately deploys, remember that Bicep is compiled into ARM-under-the-hood behavior.

Common traps

Candidates often focus on syntax fragments instead of deployment intent. The better exam habit is to ask what the template is supposed to create, which values change between environments, and which resource dependencies must exist before the deployment can succeed.

Lab moves worth practicing

• open a working Bicep file and change a parameter or SKU safely
• deploy an ARM or Bicep file and confirm the result in the portal
• export an existing deployment and compare it with a cleaner authored definition

What to notice first in a deployment file

The workflow AZ-104 wants you to recognize

Most real admin scenarios follow a simple control flow even if the exam wraps it in portal screenshots or partial code snippets.

    flowchart LR
	  A["Read template or Bicep file"] --> B["Identify parameters, resources, and dependencies"]
	  B --> C["Adjust the values or properties that really changed"]
	  C --> D["Preview impact with What-If or equivalent review"]
	  D --> E["Deploy at the intended scope"]
	  E --> F["Export or convert for reuse, cleanup, or review"]

The important habit is not “write infrastructure as code from scratch.” The habit is “inspect safely, change deliberately, deploy at the right scope, and verify what changed.”

Mini Bicep example

The exam does not require deep Bicep authorship, but you should be comfortable reading a file like this and explaining what can change safely.

 1param storageAccountName string
 2param location string = resourceGroup().location
 3param skuName string = 'Standard_LRS'
 4
 5resource stg 'Microsoft.Storage/storageAccounts@2023-05-01' = {
 6  name: storageAccountName
 7  location: location
 8  sku: {
 9    name: skuName
10  }
11  kind: 'StorageV2'
12  properties: {
13    minimumTlsVersion: 'TLS1_2'
14    allowBlobPublicAccess: false
15  }
16}
17
18output blobEndpoint string = stg.properties.primaryEndpoints.blob

AZ-104-style questions usually care less about the syntax itself and more about what each block controls:

• param values are the safe environment-specific levers
• the resource block shows the Azure object being created
• properties holds the operational defaults you are enforcing
• output exposes a value another admin or deployment step may need

CLI workflow: preview, deploy, export, and convert

Microsoft’s current CLI reference makes the following workflow valid and exam-relevant:

 1# Preview a resource-group deployment before you apply it
 2az deployment group what-if \
 3  --resource-group app-rg \
 4  --name exam-preview \
 5  --template-file main.bicep \
 6  --parameters storageAccountName=examstg123
 7
 8# Deploy the Bicep file at resource-group scope
 9az deployment group create \
10  --resource-group app-rg \
11  --name exam-rollout \
12  --template-file main.bicep \
13  --parameters storageAccountName=examstg123
14
15# Export the current resource-group state as Bicep
16az group export \
17  --resource-group app-rg \
18  --export-format bicep
19
20# Convert an existing ARM JSON template to Bicep
21az bicep decompile --file azuredeploy.json

What to notice in this flow:

• what-if is the safe preview habit, even though the core objective is still “interpret and deploy”
• az deployment group create accepts a local template file or Bicep file
• az group export is about capturing current deployed state, not producing perfect long-term source code automatically
• az bicep decompile helps move an ARM JSON starting point into a cleaner authoring format

Failure patterns worth recognizing

Exported template versus authored template

Portal-exported ARM templates are useful for inspection because they show how Azure sees the deployed state. Authored templates or Bicep files are usually cleaner for repeatable administration because they remove noise, make parameters clearer, and are easier to review over time. If the exam asks which file is better for consistent reuse, the cleaner authored definition is usually the stronger answer.

Quiz

Next, move to Virtual Machines, Disks, and Scale Sets so deployment logic connects to actual runtime administration.