Skip to main content

Technical Lab: Modify an existing Bicep file

Questions​

Question 1 — Multiple Choice​

An administrator needs to add a mandatory tag to all resources in an existing Bicep template without duplicating the declaration in each resource individually. The file already has a main module that instantiates multiple resources.

Which approach is most suitable for centralizing the tag definition in this scenario?

A) Declare the tag directly in the resource block of each resource, as Bicep doesn't offer a tag inheritance mechanism.

B) Define the tag as a param at the file level and reference the parameter in the tags block of each resource.

C) Use a var at the file level with the tags object and reference the variable in the tags block of each resource.

D) Create a separate .bicepparam file and import the tags via using.

Question 2 — Technical Scenario​

An administrator is modifying the following snippet from an existing Bicep file to add a new property to the resource:

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

When adding allowBlobPublicAccess: false inside properties, the deployment returns the error:

The resource type 'storageAccounts' does not support property 'allowBlobPublicAccess' in api-version '2023-01-01'.

What is the cause and the appropriate correction?

A) The allowBlobPublicAccess property was removed from the API; use publicNetworkAccess: 'Disabled' as a substitute.

B) The API version declared in the resource type doesn't support the property; update the API version to one that includes this property.

C) Bicep doesn't allow adding boolean properties inside properties; the property must be moved to the root level of the resource.

D) The error indicates that the Bicep file is corrupted and needs to be recompiled with az bicep build before deployment.

Question 3 — True or False​

Statement: When modifying a Bicep file to change the value of a property marked as immutable in the Azure API (such as the kind of a Storage Account), the az deployment group create command with the --mode Incremental flag will fail, as Azure doesn't allow changing immutable properties even in incremental deployments.

Is the statement true or false?

Question 4 — Technical Scenario​

An administrator inherits the Bicep file below and needs to make the Storage Account SKU configurable by environment, without changing the existing deployment logic:

param environment string = 'prod'

var skuName = 'Standard_LRS'

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'staccount${environment}'
  location: resourceGroup().location
  sku: {
    name: skuName
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
  }
}

The requirement is: in prod, use Standard_GRS; in any other environment, use Standard_LRS. Which modification to the file meets the requirement with the smallest structural change?

A) Replace var skuName = 'Standard_LRS' with param skuName string and pass the correct value at deployment time.

B) Replace var skuName = 'Standard_LRS' with var skuName = environment == 'prod' ? 'Standard_GRS' : 'Standard_LRS'.

C) Add a second parameter param skuName string = 'Standard_GRS' and use an if in the resource block to select the SKU.

D) Create a .bicepparam parameter file with two profiles and reference the skuName variable via using.

Question 5 — Multiple Choice​

When modifying an existing Bicep file, an administrator needs to reference the id of a resource that already exists in the subscription, but is not declared in the current Bicep file. The resource is a Virtual Network in another resource group.

What is the correct way to reference this existing resource in Bicep?

A) Declare the resource normally with resource vnet 'Microsoft.Network/virtualNetworks@...' = { ... } and omit the required properties.

B) Use the resourceId() function with the correct resource group to construct the ID directly as a string.

C) Declare the resource with the existing keyword and, if it's in another resource group, use the scope with resourceGroup().

D) Import the resource via a Bicep module pointing to an empty .bicep file that declares only the id output.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: C

Using a var of object type centralizes the tag definition at a single point in the file. Any resource can reference tags: tagObject without duplication. This is the idiomatic approach in Bicep for reusable values that don't need to be exposed as external parameters.

Alternative B would also work technically, but exposes tags as external input, which isn't appropriate for fixed and internal template tags. Alternative D (bicepparam) is used to provide parameter values at deployment time, not to centralize internal template logic. Alternative A is incorrect: Bicep does allow variables and parameters to be reused across multiple resource blocks.

Answer Key — Question 2​

Answer: B

The error explicitly indicates that the API version used (2023-01-01) doesn't recognize the allowBlobPublicAccess property. Each Azure Resource Manager API version exposes a specific set of properties; properties introduced in later versions aren't available in earlier versions. The fix is to update the API version in the resource type to one that includes this property.

Alternative A is a common confusion: publicNetworkAccess controls network access, not blob public access specifically. Alternative C is wrong: Bicep supports boolean properties at any level. Alternative D has no technical basis: az bicep build compiles the Bicep file to ARM JSON, but doesn't resolve API version incompatibilities.

Answer Key — Question 3​

Answer: True

The Azure Resource Manager Incremental mode only applies changes defined in the template, but still attempts to update the declared properties. If a property is immutable in the API (such as kind in Storage Accounts), the Azure API will reject the operation with an error, regardless of deployment mode. Incremental mode doesn't ignore API validation errors; it only omits resources not declared in the template. This is an important distinction: Incremental versus Complete defines what happens to resources missing from the template, not how the API handles immutable properties.

Answer Key — Question 4​

Answer: B

Replacing the var with a ternary expression that evaluates the existing environment parameter is the smallest possible structural change. The environment parameter is already declared, the skuName variable is already referenced in the resource; just change the variable value to a conditional expression. No new declarations are needed.

Alternative A turns the logic into external responsibility (whoever deploys needs to know which SKU to use per environment), which violates the requirement to keep decision logic in the template. Alternative C introduces an unnecessary second parameter and uses if incorrectly, as Bicep uses the ternary operator ? : for conditional expressions in property values, not if blocks. Alternative D introduces unnecessary complexity for a simple conditional logic requirement.

Answer Key — Question 5​

Answer: C

The existing keyword instructs Bicep to reference an already provisioned resource without trying to create or modify it. For resources in other resource groups, combine existing with the scope property pointing to resourceGroup('<rg-name>'). After this declaration, the id, name, and other resource properties become accessible via the symbolic reference.

Alternative A would cause an attempt to deploy the resource, which would fail without the required properties. Alternative B works to construct the ID as a string, but loses typing and the ability to safely access other resource properties; additionally, it's not the recommended approach when Bicep offers existing natively. Alternative D is technically impractical and doesn't represent a pattern supported by Bicep.