Bicep syntax and modules in Azure - Deep Dive

Overview - Bicep syntax and modules

What is it?

Bicep is a simple language used to write instructions for creating and managing cloud resources in Microsoft Azure. It helps you describe what you want in a clear and organized way. Modules in Bicep are like building blocks that let you reuse and organize parts of your instructions. Together, Bicep syntax and modules make managing cloud setups easier and less error-prone.

Why it matters

Without Bicep and its modules, managing cloud resources would be like writing long, confusing instructions every time you want to build something. This would lead to mistakes, wasted time, and difficulty in sharing or updating setups. Bicep solves this by making instructions simple, reusable, and easy to understand, so teams can build and change cloud environments quickly and safely.

Where it fits

Before learning Bicep syntax and modules, you should understand basic cloud concepts and how Azure resources work. After mastering this, you can move on to advanced infrastructure automation, integrating Bicep with CI/CD pipelines, and managing complex multi-environment deployments.

Mental Model

Core Idea

Bicep syntax is a clear, human-friendly way to write cloud resource instructions, and modules are reusable pieces that help organize and share these instructions efficiently.

Think of it like...

Think of Bicep syntax as writing a recipe for a meal, where each step is clear and easy to follow. Modules are like pre-made sauce jars you can add to different recipes without making the sauce from scratch every time.

┌─────────────────────────────┐
│        Bicep File           │
│ ┌───────────────┐           │
│ │ Syntax Lines  │           │
│ │ (resource     │           │
│ │ declarations) │           │
│ └───────────────┘           │
│           │                 │
│           ▼                 │
│ ┌─────────────────────────┐ │
│ │       Modules           │ │
│ │ ┌───────────┐           │ │
│ │ │ Module A  │           │ │
│ │ └───────────┘           │ │
│ │ ┌───────────┐           │ │
│ │ │ Module B  │           │ │
│ │ └───────────┘           │ │
│ └─────────────────────────┘ │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Bicep Basic Syntax

Concept: Learn the simple structure and keywords used to declare resources in Bicep.

Bicep files use straightforward lines to declare resources. For example, to create a storage account, you write 'resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = { name: 'mystorage' location: 'eastus' }'. Each resource has a type, API version, and properties inside curly braces.

Result

You can write a basic Bicep file that describes a single Azure resource clearly and simply.

Understanding the basic syntax lets you confidently describe cloud resources without complex code, making your infrastructure instructions readable and maintainable.

2

Foundation

Declaring Variables and Parameters

Concept: Introduce how to use variables and parameters to make Bicep files flexible and reusable.

Parameters let you pass values when deploying, like 'param location string = 'eastus''. Variables store values inside the file, like 'var storageName = 'mystorage123''. Using these, you avoid hardcoding values and can customize deployments easily.

Result

Your Bicep files become adaptable to different environments or needs without rewriting code.

Knowing how to use parameters and variables is key to writing flexible infrastructure code that can adjust to different situations.

3

Intermediate

Using Outputs to Share Information

🤔Before reading on: do you think outputs are only for showing messages or can they pass data between files? Commit to your answer.

Concept: Outputs let you expose information from a Bicep file, such as resource IDs, so other files or users can use them.

You declare outputs like 'output storageId string = storageAccount.id'. This makes the resource ID available after deployment. Outputs are essential when combining multiple Bicep files or modules.

Result

You can share important data from one part of your infrastructure to another, enabling modular design.

Understanding outputs unlocks the ability to connect different parts of your infrastructure cleanly and safely.

4

Intermediate

Creating and Using Modules

🤔Before reading on: do you think modules duplicate code or help reuse it? Commit to your answer.

Concept: Modules are separate Bicep files that you can call from a main file to reuse resource declarations.

You create a module file, for example 'storage.bicep', and then call it in your main file with 'module storageModule './storage.bicep' = { name: 'storage1' params: { location: 'eastus' } }'. This lets you organize and reuse code.

Result

Your infrastructure code becomes cleaner, easier to manage, and reusable across projects.

Knowing how to use modules helps you avoid repetition and makes large infrastructure projects manageable.

5

Intermediate

Passing Parameters and Getting Outputs in Modules

🤔Before reading on: do you think modules can only receive parameters or also return outputs? Commit to your answer.

Concept: Modules can accept parameters and return outputs, enabling communication between main files and modules.

Inside a module, you declare parameters and outputs. When calling a module, you pass parameters and can access outputs like 'storageModule.outputs.storageId'. This allows dynamic and connected deployments.

Result

Modules become interactive parts of your infrastructure code, not just static blocks.

Understanding parameter passing and outputs in modules is crucial for building complex, modular infrastructure.

6

Advanced

Managing Module Dependencies and Deployment Order

🤔Before reading on: do you think Bicep automatically handles deployment order or do you need to specify dependencies? Commit to your answer.

Concept: Bicep lets you specify dependencies between modules to control deployment order and ensure resources are created in the right sequence.

You use 'dependsOn' property to tell Bicep that one module depends on another, like 'dependsOn: [storageModule]'. This ensures the storage module deploys before the dependent module.

Result

Your deployments run smoothly without errors caused by missing resources or wrong order.

Knowing how to manage dependencies prevents deployment failures and keeps your infrastructure stable.

7

Expert

Advanced Module Patterns and Parameter Validation

🤔Before reading on: do you think Bicep modules can validate parameters or only accept any input? Commit to your answer.

Concept: Bicep supports advanced patterns like parameter validation, default values, and conditional resource deployment inside modules.

You can add constraints like 'param skuName string { allowed: ['Standard_LRS', 'Premium_LRS'] }' to restrict inputs. You can also use conditions to deploy resources only when needed, improving efficiency.

Result

Modules become robust, safe, and adaptable components suitable for production environments.

Understanding these advanced features helps you build professional-grade infrastructure code that reduces errors and adapts to complex needs.

Under the Hood

Bicep compiles its simple syntax into a detailed JSON template that Azure Resource Manager (ARM) understands. Modules are compiled into nested templates, allowing Azure to deploy resources in the correct order. Parameters and outputs become JSON properties that ARM uses to configure and link resources. This compilation hides complexity and ensures consistent deployments.

Why designed this way?

Bicep was created to simplify the complex and verbose ARM JSON templates. By using a domain-specific language with modules, it improves readability, reusability, and maintainability. The design balances human-friendly syntax with the power of ARM's deployment engine, avoiding reinventing deployment logic.

┌─────────────┐      ┌───────────────┐      ┌───────────────┐
│  Bicep File │─────▶│  Bicep Compiler│────▶│ ARM Template  │
└─────────────┘      └───────────────┘      └───────────────┘
       │                     │                      │
       │                     │                      ▼
       │                     │             ┌─────────────────┐
       │                     │             │ Azure Resource  │
       │                     │             │ Manager (ARM)   │
       │                     │             └─────────────────┘
       │                     │                      │
       │                     │                      ▼
       │                     │             ┌─────────────────┐
       │                     │             │ Azure Resources │
       │                     │             └─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think Bicep modules are compiled separately and deployed independently? Commit to yes or no.

Common Belief: Modules are independent deployments and can be deployed on their own.

Reality: Modules are compiled into nested templates and deployed as part of the main deployment, not independently.

Why it matters: Believing modules deploy independently can lead to confusion about deployment scope and cause errors when expecting separate deployment control.

Quick: Do you think Bicep syntax supports all ARM template features directly? Commit to yes or no.

Common Belief: Bicep can express every ARM template feature exactly as is.

Reality: Bicep covers most common ARM features but some advanced or rare ARM features require workarounds or direct ARM JSON.

Why it matters: Assuming full coverage can cause frustration when certain features are missing or behave differently, leading to deployment issues.

Quick: Do you think parameters in modules must always be provided? Commit to yes or no.

Common Belief: All parameters in a module must be passed every time you use it.

Reality: Parameters can have default values, making them optional when calling modules.

Why it matters: Not knowing this leads to unnecessarily complex calls and less flexible modules.

Quick: Do you think outputs from modules are only for human reading? Commit to yes or no.

Common Belief: Module outputs are just for displaying information after deployment.

Reality: Outputs are used to pass data between modules and main files, enabling dynamic resource linking.

Why it matters: Ignoring outputs' role in data passing limits modular design and causes duplicated or hardcoded values.

Expert Zone

1

Modules can be nested multiple levels deep, but excessive nesting can complicate deployments and debugging.

2

Parameter validation in Bicep helps catch errors early but can increase template complexity and deployment time slightly.

3

Bicep's compilation to ARM templates means understanding ARM behavior is still important for troubleshooting.

When NOT to use

Avoid using Bicep modules for extremely dynamic or conditional resource creation that changes frequently at runtime; consider using ARM templates with deployment scripts or Terraform for such cases.

Production Patterns

In production, teams use Bicep modules to standardize resource creation, enforce naming conventions, and manage multi-environment deployments by passing parameters for each environment. Modules are version-controlled and shared across teams to ensure consistency.

Connections

Terraform Modules

Similar pattern of reusable infrastructure code blocks.

Understanding Bicep modules helps grasp Terraform modules, as both promote code reuse and modular infrastructure management.

Software Functions and Libraries

Modules in Bicep are like functions or libraries in programming languages that encapsulate reusable logic.

Seeing modules as code libraries clarifies why modular design improves maintainability and reduces errors.

Manufacturing Assembly Lines

Modules resemble assembly line stations where parts are built separately and combined later.

This connection shows how modular infrastructure deployment improves efficiency and quality control, just like in manufacturing.

Common Pitfalls

#1 Hardcoding values instead of using parameters.

Wrong approach:

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = { name: 'mystorageeastus' location: 'eastus' }

Correct approach:

param location string = 'eastus'
param storageName string
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-04-01' = { name: storageName location: location }

Root cause:

Not understanding how parameters make code reusable and flexible.

#2 Calling a module without passing required parameters.

Wrong approach:

module storageModule './storage.bicep' = { name: 'storage1' }

Correct approach:

module storageModule './storage.bicep' = { name: 'storage1' params: { location: 'eastus' storageName: 'mystorage' } }

Root cause:

Forgetting that modules require parameters to configure resources inside.

#3 Ignoring module outputs and duplicating resource IDs.

Wrong approach:

resource dependentResource 'Microsoft.Example/resource@2021-01-01' = { name: 'dep1' properties: { storageId: '/subscriptions/.../storageAccounts/mystorage' } }

Correct approach:

resource dependentResource 'Microsoft.Example/resource@2021-01-01' = { name: 'dep1' properties: { storageId: storageModule.outputs.storageId } }

Root cause:

Not using outputs to share resource information leads to hardcoded and error-prone references.

Key Takeaways

Bicep syntax simplifies writing Azure infrastructure code by using clear, human-friendly instructions.

Modules in Bicep enable code reuse and better organization by encapsulating resource declarations.

Parameters and outputs are essential for making modules flexible and for sharing data between parts of your infrastructure.

Managing dependencies between modules ensures resources deploy in the correct order, preventing errors.

Advanced features like parameter validation and conditional deployment make modules robust for production use.

Practice

1. What is the main purpose of a module in Bicep?

easy

A. To reuse and organize infrastructure code by calling other Bicep files

B. To define variables inside a Bicep file

C. To store output values only

D. To create a new Azure subscription

Solution

1. Step 1: Understand what a module does

   A module in Bicep is a way to include and reuse other Bicep files, helping organize code.

2. Step 2: Compare options to the definition

   Only To reuse and organize infrastructure code by calling other Bicep files correctly describes modules as reusable code blocks. Variables and outputs are different concepts, and creating subscriptions is unrelated.

3. Final Answer:

   To reuse and organize infrastructure code by calling other Bicep files -> Option A

4. Quick Check:

   Module = reusable code block [OK]

Hint: Modules call other files to reuse code easily [OK]

Common Mistakes:

• Confusing modules with variables
• Thinking modules only store outputs
• Believing modules create Azure subscriptions

2. Which of the following is the correct syntax to declare a module in Bicep?

easy

A. module myModule = 'module.bicep' {}

B. module myModule 'module.bicep' = {}

C. module 'myModule' = module.bicep {}

D. module 'myModule' 'module.bicep' {}

Solution

1. Step 1: Recall module declaration syntax

   The correct syntax is: module <name> '<path>' = {}.

2. Step 2: Match options to syntax

   module myModule 'module.bicep' = {} matches the correct syntax exactly. Other options have misplaced quotes or assignment operators.

3. Final Answer:

   module myModule 'module.bicep' = {} -> Option B

4. Quick Check:

   module name 'file' = {} [OK]

Hint: Use: module name 'file.bicep' = {} [OK]

Common Mistakes:

• Putting quotes around the module name
• Using = before the file path
• Omitting the equals sign

3. Given this Bicep code snippet, what will be the output value of moduleOutput?

module storageModule 'storage.bicep' = {
  name: 'storage1'
}

output moduleOutput string = storageModule.outputs.storageAccountName

medium

A. An error because outputs cannot be accessed from modules

B. The module file path 'storage.bicep'

C. The name of the storage account defined inside storage.bicep

D. The string 'storage1'

Solution

1. Step 1: Understand module outputs

   Modules can expose outputs which can be accessed using moduleName.outputs.outputName.

2. Step 2: Analyze the code snippet

   The output moduleOutput gets the value of storageAccountName from the module's outputs, which is the storage account name defined inside storage.bicep.

3. Final Answer:

   The name of the storage account defined inside storage.bicep -> Option C

4. Quick Check:

   module.outputs = module data access [OK]

Hint: Access module outputs with moduleName.outputs.outputName [OK]

Common Mistakes:

• Thinking outputs can't be accessed from modules
• Confusing module name with file path
• Assuming output is the module instance name

4. Identify the error in this Bicep module usage:

module webAppModule 'webapp.bicep' = {
  name: 'webApp1'
  params: {
    location: 'eastus'
  }
}

medium

A. Incorrect keyword 'params' should be 'parameters'

B. Module name cannot contain numbers

C. Module file path must be absolute

D. Missing equals sign after 'name'

Solution

1. Step 1: Check parameter passing syntax in modules

   In Bicep, module parameters can be passed directly as properties (e.g., location: 'eastus') or nested under parameters: { ... }. params is not a valid keyword.

2. Step 2: Identify the error

   The code uses invalid params:, which should be parameters: for nested parameters.

3. Final Answer:

   Incorrect keyword 'params' should be 'parameters' -> Option A

4. Quick Check:

   parameters: { } for nested params [OK]

Hint: Use 'parameters:' not 'params' for nested params [OK]

Common Mistakes:

• Using 'params' instead of 'parameters'
• Thinking module names cannot contain numbers
• Believing file paths must be absolute

5. You want to create a reusable Bicep module for a virtual network that accepts a parameter for the address prefix and outputs the subnet ID. How should you define the module's parameter and output to follow best practices?

hard

A. Declare the address prefix as an output and subnet ID as a parameter

B. Use a variable for address prefix and no output since subnet ID is internal

C. Hardcode the address prefix and output the subnet name instead of ID

D. Declare a param addressPrefix string and an output subnetId string in the module file

Solution

1. Step 1: Define parameters for input values

   Best practice is to declare inputs as parameters so the module is flexible. Here, param addressPrefix string allows passing different address prefixes.

2. Step 2: Define outputs for important results

   Outputs share useful info back to the caller. The subnet ID is important to output as output subnetId string.

3. Final Answer:

   Declare a param addressPrefix string and an output subnetId string in the module file -> Option D

4. Quick Check:

   Parameters input, outputs share results [OK]

Hint: Use param for inputs, output for results [OK]

Common Mistakes:

• Using variables instead of parameters for inputs
• Not outputting needed resource IDs
• Mixing parameters and outputs roles