Skip to main content

Technical Lab: Interpret an Azure Resource Manager template or a Bicep file

Questions​

Question 1 — Multiple Choice​

An administrator analyzes the following ARM template snippet:

"parameters": {
  "storageAccountName": {
    "type": "string",
    "defaultValue": "mystorage",
    "allowedValues": [
      "mystorage",
      "prodstorage"
    ]
  }
}

During deployment, the operator passes the value "devstorage" via command line. What is the expected behavior?

A) The deployment completes with the value "devstorage", because parameters passed at runtime always override defaultValue and allowedValues.

B) The deployment fails validation, because the provided value is not in the allowedValues list.

C) The deployment uses "mystorage" as a fallback, ignoring the invalid value passed by the operator.

D) The deployment fails only if "devstorage" contains invalid characters for the string type.

Question 2 — Technical Scenario​

A team needs to deploy multiple environments (dev, staging, prod) using the same ARM template. The only difference between environments is the App Service plan SKU. The current template hardcodes the value "S1" directly in the sku property:

"sku": {
  "name": "S1",
  "tier": "Standard"
}

The team wants the SKU to be defined at deployment time without modifying the template. What is the correct approach?

A) Create three separate templates, one per environment, substituting the SKU value in each one.

B) Replace the hardcoded value with a parameter reference and pass the value during deployment.

C) Use the variables() function to dynamically define the SKU based on the resource group name.

D) Use the environment() function to automatically select the SKU based on the detected Azure environment.

Question 3 — True or False​

In a Bicep file, it is possible to reference the output value of a child module directly in another resource of the parent file, as long as the child module has declared that value in the output section.

True or False?

Question 4 — Technical Scenario​

An engineer reviews the following ARM template snippet and receives a validation error when deploying:

"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2022-09-01",
    "name": "[parameters('storageName')]",
    "location": "[resourceGroup().location]",
    "sku": {
      "name": "Standard_LRS"
    },
    "kind": "StorageV2"
  },
  {
    "type": "Microsoft.Web/sites",
    "apiVersion": "2022-03-01",
    "name": "[parameters('appName')]",
    "location": "[resourceGroup().location]",
    "properties": {
      "storageEndpoint": "[reference(parameters('storageName')).primaryEndpoints.blob]"
    }
  }
]

The error indicates that the storageEndpoint property cannot be resolved. What is the most likely cause?

A) The reference() function can only be used within outputs, not in properties of other resources.

B) The Microsoft.Web/sites resource does not declare an explicit dependency on the storage account, and ARM may try to resolve the reference before the resource exists.

C) The reference() function requires the complete resourceId() as an argument; using only the parameter name is invalid in all contexts.

D) The storageEndpoint property is not supported by the Microsoft.Web/sites type and the template is syntactically invalid.

Question 5 — Multiple Choice​

When interpreting a Bicep file, an analyst finds the following snippet:

var location = resourceGroup().location

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

output blobEndpoint string = storageAccount.properties.primaryEndpoints.blob

Which statement correctly describes the behavior of the output block in this file?

A) The blobEndpoint value is evaluated during Bicep compilation to ARM JSON, before deployment.

B) The blobEndpoint value is only available after deployment completion, as it depends on a property resolved at runtime by Azure.

C) The output block forces the storageAccount resource to be created before any other resource in the same template.

D) The output block is optional in Bicep files and, if removed, the storageAccount resource will not be deployed.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

The allowedValues field defines a restricted set of accepted values for the parameter. When a value is passed during deployment, ARM validates it against this list before starting any deployment. Since "devstorage" is not in ["mystorage", "prodstorage"], the deployment fails during template validation phase, not during resource creation.

The core conceptual error of the distractors is treating allowedValues as a suggestion or as a silent fallback. In reality, it is a validation constraint applied by Azure before deployment begins. The defaultValue is only used when no value is provided by the operator, not as a substitute for an invalid value.

Answer Key — Question 2​

Answer: B

The correct way to parameterize values that vary between environments is to declare a parameter in the template and reference that parameter with [parameters('paramName')] in place of the hardcoded value. This way, the same template can be reused with different values passed via -TemplateParameterObject, parameter file, or command line.

Alternative C confuses the role of variables(): variables are calculated internally within the template and do not receive external input. Alternative D uses environment() incorrectly; this function returns metadata about the Azure environment (like sovereign cloud endpoints), not select SKUs based on business context.

Answer Key — Question 3​

Answer: True

In Bicep, when a module declares values in the output section, those values become accessible in the parent file through the syntax moduleName.outputs.outputName. The parent file can use this value as input for another resource or module, provided the dependency is correctly inferred or made explicit.

This mechanism is central to modular composition in Bicep and is a significant difference from pure ARM JSON, where chaining outputs between nested resources requires more verbosity. The dependency between the child module and the parent resource consuming the output is automatically inferred by the Bicep compiler.

Answer Key — Question 4​

Answer: B

ARM deploys resources in parallel by default when there is no declared dependency. In the presented template, the Microsoft.Web/sites resource uses reference() to access a storage account property, but does not declare "dependsOn" pointing to it. Without this declaration, ARM may try to resolve the reference before the storage account exists, causing the error.

The solution is to add "dependsOn": ["[resourceId('Microsoft.Storage/storageAccounts', parameters('storageName'))]"] to the Web resource. Alternative C is partially true in some contexts, but is not the cause of the error here: reference() accepts simple names when the resource is in the same template and same resource group. Alternative A is false; reference() is widely used in properties.

Answer Key — Question 5​

Answer: B

Values declared in output that depend on resource properties, such as primaryEndpoints.blob, are only resolved after deployment completion. These properties are generated by Azure during resource creation and do not exist beforehand. The output block instructs ARM to capture and return this value at the end of deployment.

Alternative A represents a frequent misconception: confusing Bicep compilation to ARM JSON (which is static and local) with runtime value resolution done by Azure. Compilation transforms syntax but does not execute or evaluate resource properties. Alternatives C and D are false: output does not control creation order and has no relationship to the decision to deploy a resource or not.