Bicep syntax and modules in Azure - Step-by-Step Execution

Process Flow - Bicep syntax and modules

Start Bicep file

↓

Define parameters

↓

Define variables

↓

Use modules to call other Bicep files

↓

Define resources

↓

Output values

↓

Deploy Bicep template

This flow shows how a Bicep file is structured: starting with parameters and variables, then calling modules, defining resources, and finally outputs before deployment.

Execution Sample

Azure

param location string = 'eastus'
module storageModule './storage.bicep' = {
  name: 'storageDeploy'
  params: {
    location: location
  }
}
output storageId string = storageModule.outputs.storageAccountId

This Bicep code defines a location parameter, calls a storage module passing the location, and outputs the storage account ID from the module.

Process Table

Step	Action	Evaluation	Result
1	Read parameter 'location'	Default 'eastus'	location = 'eastus'
2	Call module './storage.bicep'	Pass param location='eastus'	Module deployment started
3	Module './storage.bicep' deploys storage account	Uses location='eastus'	Storage account created
4	Module outputs 'storageAccountId'	Captured as storageModule.outputs.storageAccountId	Value available
5	Define output 'storageId'	Assign storageModule.outputs.storageAccountId	Output ready
6	Bicep deployment completes	All resources and outputs defined	Deployment successful

💡 Deployment ends after all resources and outputs are processed successfully.

Status Tracker

Variable	Start	After Module Call	Final
location	'eastus'	'eastus'	'eastus'
storageModule.outputs.storageAccountId	undefined	assigned after module deploy	assigned after module deploy
storageId	undefined	undefined	storageModule.outputs.storageAccountId

Key Moments - 2 Insights

Why do we pass parameters to modules instead of hardcoding values?

Passing parameters allows modules to be reusable and flexible. As shown in step 2 of the execution_table, the location parameter is passed to the module, so it can deploy resources in different locations without changing the module code.

How do outputs from modules become available in the main Bicep file?

Outputs from modules are accessed via the module's outputs property. In step 4, the storageAccountId output from the module is captured and then assigned to the main output in step 5.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of 'location' after step 1?

A 'westus'

B 'eastus'

C undefined

D 'centralus'

💡 Hint

Check the 'Evaluation' column in step 1 where 'location' is set to 'eastus'.

At which step does the module './storage.bicep' complete creating the storage account?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Look at the 'Action' and 'Result' columns in step 3 describing module deployment.

If the parameter 'location' was changed to 'westus', which step's evaluation would change?

A Step 5 only

B Step 1 only

C Step 2 and Step 3

D No steps would change

💡 Hint

Refer to steps 2 and 3 where the location parameter is passed and used in the module deployment.

Concept Snapshot

Bicep files start with parameters and variables.
Modules are called with 'module' keyword and accept parameters.
Modules deploy resources and return outputs.
Outputs from modules are accessed via 'moduleName.outputs'.
This structure enables reusable, clean infrastructure code.

Full Transcript

This lesson shows how Bicep syntax organizes infrastructure as code. First, parameters like 'location' are defined with default values. Then, modules are called using the 'module' keyword, passing parameters to them. The module deploys resources, such as a storage account, using the passed parameters. After deployment, the module outputs values like the storage account ID. These outputs are accessed in the main Bicep file through the module's outputs property and can be assigned to outputs for use after deployment. This approach helps keep code modular and reusable. The execution table traces each step from reading parameters, calling modules, deploying resources, capturing outputs, and completing deployment. Variables like 'location' and module outputs change state as deployment progresses. Key moments clarify why parameters are passed to modules and how outputs are accessed. The quiz tests understanding of variable values, deployment steps, and parameter effects. The snapshot summarizes the core syntax and behavior of Bicep modules.