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.