Skip to main content

Technical Lab: Deploy resources by using an Azure Resource Manager template or a Bicep file

Questions​

Question 1 — Multiple Choice​

During a deployment pipeline review, an engineer analyzes the following snippet from an ARM template:

{
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2022-09-01",
      "name": "[parameters('storageName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "StorageV2",
      "dependsOn": [
        "[resourceId('Microsoft.Network/virtualNetworks', parameters('vnetName'))]"
      ]
    }
  ]
}

The template deploys the storage account and a VNet as separate resources. The deployment fails with a circular dependency error. What is the most likely cause?

A) The dependsOn field is not supported for Microsoft.Storage/storageAccounts resource types.

B) The VNet resource, at another point in the template, also declares dependsOn pointing to the storage account, creating a mutual dependency.

C) ARM resolves dependencies implicitly via reference() and ignores explicit dependsOn, generating internal conflict.

D) The resourceId() function within dependsOn is invalid; the correct value would be the resource name directly as a string.

Question 2 — Technical Scenario​

A team needs to deploy the same infrastructure across three distinct environments: dev, staging, and prod. Each environment should use different SKUs for the resources. The team opted for Bicep and created a single main.bicep file. To differentiate the environments, the tech lead proposes two approaches:

Approach X: Use an env parameter of type string and, within the file, use conditional expressions with the ternary operator to define SKUs based on the received value.

Approach Y: Create three separate .bicepparam files, each providing appropriate parameter values for its respective environment, and reference the same main.bicep.

Considering best practices for reusability, traceability, and Bicep code maintenance, which statement best describes the relationship between the two approaches?

A) Approach X is preferable because it centralizes all logic in the main file, eliminating the need for additional files.

B) Approach Y is the only technically valid option; .bicepparam files are mandatory for multi-environment deployments in Bicep.

C) Both approaches are functionally equivalent, but Approach Y favors separation between infrastructure logic and configuration values, which improves traceability per environment.

D) Approach X is not supported by Bicep; the ternary operator is only available in ARM templates in JSON format.

Question 3 — True or False​

Statement: In an ARM template, when two resources have no explicitly declared dependency via dependsOn and neither references the other with the reference() or resourceId() function within their properties, Azure Resource Manager necessarily deploys them in sequence, waiting for the first to complete before starting the second.

True or False?

Question 4 — Technical Scenario​

An administrator runs the following command to deploy a Bicep file:

az deployment group create \
  --resource-group rg-production \
  --template-file main.bicep \
  --mode Complete

After the successful deployment, the administrator notices that two resources that existed in the resource group before execution were deleted, even though they were not defined in the main.bicep file. No error was returned.

What is the correct explanation for this behavior?

A) The Complete mode deletes resources from the resource group that are not declared in the template, which is the expected and documented behavior.

B) The command presents a known bug in Azure CLI; the Complete mode should be ignored in resource group deployments.

C) The Complete mode only deletes resources if the --confirm-with-what-if parameter is omitted; the administrator should have included it to avoid deletion.

D) The resources were deleted because the template contained an outputs block that referenced only the defined resources, signaling to ARM that the others should be removed.

Question 5 — Multiple Choice​

An operations team needs to deploy a set of network resources across multiple resource groups within the same subscription. They have a single Bicep file that describes all resources. Which deployment scope and command are most appropriate for this need?

A) resourceGroup scope; the team should execute az deployment group create once per resource group, passing the same Bicep file with different parameters.

B) subscription scope; the team should use az deployment sub create and declare targetScope = 'subscription' in Bicep, using modules with explicit scope pointing to each resource group.

C) managementGroup scope; it's the only scope that allows deploying resources to multiple resource groups simultaneously within a subscription.

D) tenant scope; deployments that cross resource groups require tenant-level permissions and the az deployment tenant create command.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

ARM detects circular dependency when two or more resources mutually reference each other as prerequisites. If the VNet resource, in another section of the same template, declares dependsOn pointing to the storage account, and the storage account declares dependsOn pointing to the VNet, the orchestration engine cannot determine a valid creation order and fails.

The main misconception represented by the distractors is attributing the failure to syntactic or function restrictions: dependsOn is supported for any resource type, resourceId() within dependsOn is correct and documented usage, and ARM does not ignore dependsOn when reference() is also present. Choosing alternative A or D would lead the engineer to modify valid syntax without solving the actual template design problem.

Answer Key — Question 2​

Answer: C

.bicepparam files were introduced precisely to separate environment-specific parameter values from the infrastructure logic contained in the .bicep file. This allows main.bicep to remain environment-agnostic and each .bicepparam file to be versioned, reviewed, and audited independently.

Approach X is technically functional, and the ternary operator is valid in Bicep. However, centralizing SKU selection logic within the main file mixes responsibilities and makes it difficult to audit what exactly was deployed in each environment. Alternative B is wrong because .bicepparam files are not mandatory; they are a recommended practice. Choosing A would lead to code that is harder to maintain as the number of environments or variations grows.

Answer Key — Question 3​

Answer: False

When there is no explicit or implicit dependency between resources, ARM deploys them in parallel, not in sequence. ARM's orchestration engine is designed to maximize parallelization, starting all resources without declared dependencies simultaneously. Assuming sequential deployment as default is a common misconception that leads to templates with unnecessary dependsOn, increasing total deployment time without any benefit. Sequence is only guaranteed when there is a declared or inferred dependency through the use of reference() or resourceId() within a resource's properties.

Answer Key — Question 4​

Answer: A

The Complete mode instructs ARM to treat the template as the complete and desired definition of the resource group. Any resource present in the group that is not declared in the template is deleted at the end of a successful deployment. This is the documented and intentional behavior, designed to maintain environment state in strict compliance with the template.

The Incremental mode, which is the default, only adds or updates resources declared in the template, without removing those not listed in it. Confusion between the two modes is one of the most common causes of accidental deletions in production. The --confirm-with-what-if parameter does not change the deployment mode; it only simulates changes before executing them, being a good security practice, but not an automatic protection mechanism.

Answer Key — Question 5​

Answer: B

To deploy resources across multiple resource groups within the same subscription from a single Bicep file, the correct scope is subscription. The file should declare targetScope = 'subscription' and use Bicep modules with the scope attribute explicitly pointing to each target resource group. The corresponding command is az deployment sub create.

The resourceGroup scope would require independent command executions, which does not satisfy the premise of a coordinated deployment from a single file. The managementGroup scope operates above subscriptions and is used to deploy resources across multiple subscriptions, not to cross resource groups within the same subscription. The tenant scope is reserved for tenant-level resources, such as global policy definitions, and does not solve the described scenario.