Bicep syntax and modules in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Bicep Module Outputs

You have a Bicep module that deploys a storage account and outputs its resource ID. What will be the value of storageAccountId after deployment?

module storageModule './storage.bicep' = {
  name: 'storageDeploy'
  params: {
    storageName: 'mystorage123'
  }
}

var storageAccountId = storageModule.outputs.storageAccountId

A /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/mystorage123

B mystorage123

C outputs.storageAccountId

D Undefined variable error

💡 Hint

Module outputs are accessed using moduleName.outputs.outputName and usually contain full resource IDs if defined that way.

The module storageModule outputs the full resource ID of the storage account. Accessing storageModule.outputs.storageAccountId returns the full resource ID string, not just the name.

❓ Configuration

intermediate

Correct Bicep Module Declaration Syntax

Which of the following Bicep module declarations is syntactically correct to deploy a module named network.bicep with a parameter vnetName set to myVnet?

A

module networkModule './network.bicep' {
  name: 'netDeploy'
  params: {
    vnetName: 'myVnet'
  }
}

B

module networkModule './network.bicep' = {
  vnetName: 'myVnet'
}

C

module networkModule = './network.bicep' {
  name: 'netDeploy'
  params: {
    vnetName: 'myVnet'
  }
}

D

module networkModule './network.bicep' = {
  name: 'netDeploy'
  params: {
    vnetName: 'myVnet'
  }
}

💡 Hint

Remember the module declaration syntax requires the module keyword, a symbolic name, the path in quotes, an equals sign, and a block with name and params.

Option D correctly uses the syntax: module symbolicName 'path' = { name: 'deploymentName' params: { ... } }. Other options miss the equals sign or have incorrect structure.

❓ Architecture

advanced

Best Practice for Reusing Bicep Modules Across Environments

You want to deploy the same Bicep module for multiple environments (dev, test, prod) with different parameters. Which approach ensures clean, maintainable code?

A Manually edit the module file parameters before each deployment to match the environment.

B Create separate copies of the module file for each environment with hardcoded parameters.

C Use a single module file and pass environment-specific parameters from a main Bicep file for each deployment.

D Deploy the module only once and manually change resource properties in Azure portal for each environment.

💡 Hint

Think about how to avoid duplication and manual changes while keeping deployments consistent.

Using a single module file with parameterization allows reuse and cleaner management. Passing parameters from a main Bicep file per environment avoids duplication and errors.

❓ security

advanced

Handling Secrets in Bicep Modules Securely

You need to pass a database password to a Bicep module. Which method is the most secure to handle this secret?

A Use Azure Key Vault references in the Bicep module to retrieve the password at deployment time.

B Pass the password as a plain text parameter from the main Bicep file.

C Hardcode the password directly in the Bicep module parameters.

D Store the password in a public GitHub repository and reference it in the module.

💡 Hint

Consider how to avoid exposing secrets in code or parameters.

Using Azure Key Vault references allows secure retrieval of secrets during deployment without exposing them in code or parameters.

❓ service_behavior

expert

Effect of Module Scope on Resource Deployment

Consider a Bicep module declared with scope set to a subscription level. What is the effect on resources declared inside this module?

A Resources inside the module deploy to a random resource group in the subscription.

B Resources inside the module are deployed at the subscription scope, not limited to the resource group of the main deployment.

C The module deployment fails because scope can only be set at the main Bicep file level.

D Resources inside the module ignore the scope and deploy to the resource group of the main Bicep file.

💡 Hint

Think about how scope changes the deployment target of resources inside modules.

Setting scope on a module changes the deployment target for all resources inside it to that scope, such as subscription or management group, overriding the main deployment's resource group.

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