Technical Lab: Modify an existing Azure Resource Manager template
Questions
Question 1 — Multiple Choice
You have the following snippet from an ARM template and need to make the storage account name configurable at deployment time, without changing the current default behavior:
{
"type": "Microsoft.Storage/storageAccounts",
"name": "minhaconta2024",
"apiVersion": "2023-01-01",
"location": "[resourceGroup().location]",
"sku": {
"name": "Standard_LRS"
},
"kind": "StorageV2"
}
Which modification correctly meets this requirement?
A) Replace "minhaconta2024" with "[variables('storageAccountName')]" and define the variable with the value "minhaconta2024" in the variables section.
B) Replace "minhaconta2024" with "[parameters('storageAccountName')]" and add the parameter in the parameters section with "defaultValue": "minhaconta2024".
C) Replace "minhaconta2024" with "[parameters('storageAccountName')]" and add the parameter in the parameters section without defaultValue.
D) Add an entry in the outputs section that exposes the current name and reuse it via "[outputs('storageAccountName').value]" in the name field.
Question 2 — Technical Scenario
A team received the ARM template below to deploy a virtual machine. During review, an engineer identified that the deployment will fail before even reaching VM provisioning.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"adminPassword": {
"type": "string"
}
},
"variables": {
"vmName": "prod-vm-01"
},
"resources": [
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2023-03-01",
"name": "[variables('vmName')]",
"location": "[resourceGroup().location]",
"properties": {
"osProfile": {
"adminUsername": "azureadmin",
"adminPassword": "[parameters('adminPassword')]"
}
}
}
]
}
What is the problem that will cause the failure?
A) The adminPassword parameter doesn't declare "type": "securestring", which is rejected by Azure Resource Manager for password fields.
B) The [variables('vmName')] function cannot be used in the name field of a resource; the name must be a literal value or derived from parameters.
C) The properties.osProfile section is incomplete because it doesn't contain the mandatory computerName field.
D) The apiVersion value is incorrect for the Microsoft.Compute/virtualMachines type and will cause a schema validation error.
Question 3 — True or False
The copyIndex() function in an ARM template, when used within a copy loop without an argument, always returns a value starting at 0 and can be combined with copyIndex(1) to start counting at 1, without affecting the total number of iterations defined in count.
Question 4 — Technical Scenario
You need to modify an existing ARM template so that a Microsoft.Network/publicIPAddresses resource is deployed only when a boolean parameter deployPublicIP has the value true. The current resource snippet is:
{
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2023-05-01",
"name": "pip-prod",
"location": "[resourceGroup().location]",
"sku": { "name": "Standard" },
"properties": {
"publicIPAllocationMethod": "Static"
}
}
Which modification correctly implements conditional deployment?
A) Add "dependsOn": ["[parameters('deployPublicIP')]"] to the resource to create a conditional dependency.
B) Wrap the resource object in an if statement at the JSON level, like "if": "[parameters('deployPublicIP')]": { ... }.
C) Add the property "condition": "[parameters('deployPublicIP')]" directly to the resource object.
D) Move the resource to the outputs section and use "condition" within the output to control its creation.
Question 5 — Multiple Choice
When modifying an ARM template to reference a resource that will be created in the same deployment, which of the following approaches ensures that Azure Resource Manager resolves the dependency correctly and deploys the resources in the proper order?
A) Use "dependsOn" with the complete resourceId() of the dependent resource, including subscription and resource group.
B) Use "dependsOn" with the format "[resourceId('type/resource', 'name')]" or simply with the symbolic name of the resource.
C) Use the reference() function in the properties field of the dependent resource, which implicitly creates a dependency without needing dependsOn.
D) Declare resources in the correct order within the resources array, as ARM respects declaration order by default.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Using parameters with "defaultValue" is the only approach that meets both requirements simultaneously: makes the name configurable at deployment time and maintains the current default behavior with the value "minhaconta2024".
Alternative A uses variables, which are static and calculated within the template itself. They cannot be overridden at deployment time via input parameter, therefore they don't make the resource "configurable" by the operator executing the deployment.
Alternative C would be correct regarding configurability, but by omitting defaultValue it breaks the default behavior: any deployment without the explicit parameter will now fail due to missing required field.
Alternative D represents a fundamental misunderstanding: outputs serves to expose values after deployment and cannot be referenced as a value source within the same template.
Answer Key — Question 2
Answer: C
The computerName field within osProfile is mandatory by the Microsoft.Compute provider. Its absence is detected by ARM during payload validation before provisioning, causing immediate failure.
Alternative A describes a security best practice (securestring), but not a rule that causes automatic rejection by ARM during schema validation. The deployment won't fail for this reason alone.
Alternative B is technically incorrect: variables() is perfectly valid in the name field of a resource.
Alternative D is a plausible distractor, but API versions are validated less rigidly during submission; apiVersion errors typically result in control plane failures at the provider level, not immediate schema rejection.
Answer Key — Question 3
Answer: True
The statement is true. copyIndex() without an argument returns 0 on the first iteration. copyIndex(1) is the documented way to offset the return value by n positions, useful for naming resources starting from 1 instead of 0. This offset is purely cosmetic for the value returned by the function and doesn't interfere with the number of iterations, which is controlled exclusively by the count field of the copy object.
The common misconception is believing that copyIndex(1) would start the second iteration or skip the first, which doesn't happen. The loop always executes exactly count times, regardless of the argument passed to copyIndex().
Answer Key — Question 4
Answer: C
The "condition" property is ARM's native mechanism for conditional resource deployment. When its value evaluates to false, the resource is ignored during deployment without causing an error.
Alternative A confuses dependsOn with conditional logic. dependsOn defines creation order between resources that will be created; it doesn't serve to suppress resource creation.
Alternative B describes a syntax that doesn't exist in ARM. There's no if statement at the resource object level with that JSON structure.
Alternative D represents a misunderstanding about the role of outputs. The outputs section is used to expose values after deployment and has no capability to control resource creation.
Answer Key — Question 5
Answer: C
When the reference() function is used within properties of a resource to access attributes of another resource from the same deployment, ARM automatically infers a dependency between them. This implicit dependency is sufficient to guarantee provisioning order, making explicit use of dependsOn redundant in this case.
Alternative B is partially correct in describing valid dependsOn syntax, but the question asks about the approach that ensures correct resolution when using reference(), making C the more precise and complete answer.
Alternative A is wrong because resourceId() with complete subscription and resource group is used to reference resources in external scopes, not within the same deployment.
Alternative D represents the most common misconception: ARM does not respect declaration order in the resources array. The deployment engine analyzes declared and inferred dependencies to determine execution order.