Troubleshooting Lab: Modify an existing Bicep file
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator inherits a Bicep file from a previous project and runs the deployment without initial modifications to validate the baseline. The deployment completes successfully. Then, he adds a new parameter and a new Storage Account to the file, saves and runs it again:
az deployment group create \
--resource-group rg-prod-eastus \
--template-file main.bicep \
--parameters env=prod
The command returns the following error:
Error BCP037: The property 'accessTier' is not allowed on objects of type
'StorageAccountPropertiesCreateParameters'.
The administrator verifies that the API version declared for the Storage Account is 2021-02-01, the same used in the original resource that deployed successfully. The resource group is in the East US region. The subscription has a policy that requires the costCenter tag on all resources, and this tag was correctly added to the new resource.
What is the root cause of the error?
A) The tags policy is blocking the deployment because policy validation occurs before API schema validation.
B) The accessTier property is not valid for the Storage Account kind configured in the new resource, even though it's a property recognized by the API version.
C) The API version 2021-02-01 has been deprecated and doesn't accept new deployments, only reads of existing resources.
D) The env parameter is not declared in the Bicep file with the correct type, causing failure in resource property resolution.
Scenario 2 — Action Decision
The cause of the problem has been identified: a Bicep file that manages an App Service Plan and an App Service in production has an outdated App Service API version. A property needed to enable managed identity access was introduced in a later version and is not available in the current version declared in the file.
The environment is production with active SLA. The App Service is receiving traffic. The API version update in the Bicep file has already been tested in the development environment and the deployment worked correctly. The deployment mode configured in the pipeline is Incremental. The change team requires approval for any production changes outside the scheduled window, which occurs in the next 6 hours.
What is the correct action to take at this moment?
A) Execute the deployment immediately in production with the corrected API version, since Incremental mode ensures only the new property will be applied, without risk of interruption.
B) Update the API version directly in the Azure portal via ARM templates editor to bypass the approval process without modifying the Bicep file.
C) Wait for the scheduled change window, submit the change for approval with the development test result as evidence, and execute the deployment in the authorized window.
D) Revert the Bicep file to the previous version and redeploy immediately to ensure consistency between the repository and the current resource state.
Scenario 3 — Root Cause
An administrator modifies a Bicep file to extract repeated values to variables. Before the modification, the deployment worked. After the modification below, Bicep compiles without error with az bicep build, but the deployment fails:
var location = 'eastus'
var appName = 'myapp-${environment}'
resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
name: '${appName}-plan'
location: location
sku: {
name: 'B1'
tier: 'Basic'
}
}
resource appService 'Microsoft.Web/sites@2022-03-01' = {
name: appName
location: location
properties: {
serverFarmId: appServicePlan.id
}
}
The error returned by Azure Resource Manager is:
InvalidTemplate: Deployment template validation failed: 'The template variable
'location' is not valid: The language expression property 'location' cannot be
used within a deployment at scope 'resourceGroup'.
The environment parameter is declared in the file. The subscription and resource group exist and the administrator has Contributor permission. The CI pipeline uses az bicep build to validate the file before deployment.
What is the root cause of the failure?
A) The resourceGroup().location function must be used to determine the location, since Azure doesn't accept literal strings in the location field of resources within a resource group.
B) The location variable conflicts with a reserved word or implicit property of the ARM deployment scope, and the name must be changed to avoid the collision.
C) The az bicep build doesn't detect name conflicts with ARM scope properties because it only validates Bicep syntax, not ARM expression resolution.
D) The location field of a resource doesn't accept variable reference; it must receive a literal value or direct parameter reference.
Scenario 4 — Diagnostic Sequence
An administrator receives the following report: a Bicep file that previously deployed successfully started failing after a modification made by another team member. The error message is generic:
Error: Deployment failed. Check the activity log for details.
The available steps for investigation are:
- Execute
az bicep build --file main.bicepto check for syntax and compilation errors. - Consult the resource group activity log in the portal or via CLI to get the detailed ARM error message.
- Compare the current Bicep file with the previous version in version control history to identify what was changed.
- Execute a what-if deployment with
az deployment group what-ifto visualize the changes that would be applied. - Try executing the deployment in an isolated test resource group to confirm if the error is reproducible.
What is the correct investigation sequence?
A) 3, 1, 2, 4, 5
B) 1, 3, 2, 4, 5
C) 2, 1, 3, 4, 5
D) 5, 3, 1, 2, 4
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The accessTier property is recognized by API version 2021-02-01, but is only valid for Storage Accounts of kind BlobStorage or StorageV2. If the new resource was declared with kind: 'Storage' (legacy), the API rejects the property as invalid for that type, even though the API version is identical to the resource that worked. The message not allowed on objects of type indicates incompatibility between property and type, not between property and version.
The information about the tags policy is purposefully irrelevant: the policy is satisfied and is not the source of the error. Alternative A is a common diagnostic error that confuses policy rejection with schema error. Alternative C is false: ARM API versions are not deprecated for new deployments silently. Alternative D diverts focus to the parameter, which has no relation to the reported schema error. The most dangerous distractor is A, as it could lead the administrator to investigate policies and permissions instead of the resource type.
Answer Key — Scenario 2
Answer: C
The organization's change process requires approval before production changes. The window is close (6 hours), the development environment already validated the change, and Incremental mode doesn't eliminate the risk of impact on a resource with active traffic; it only omits resources absent from the template. Acting outside the process without approval violates change control, regardless of technical confidence in the solution.
Alternative A ignores the process restriction and overestimates the safety of Incremental mode. Alternative B bypasses change control and creates a divergence between the resource state in Azure and the Bicep file in the repository, which is a serious operational risk. Alternative D doesn't make sense in context: the current file in the repository didn't deploy to production with the error; there's no divergence to correct. The most dangerous distractor is A, as it uses a plausible technical argument to justify bypassing the process.
Answer Key — Scenario 3
Answer: B
The ARM error message directly indicates that the location property cannot be used as an expression in the resource group deployment scope. This occurs because location is an implicit property of the resourceGroup() scope object in ARM, and by declaring a Bicep variable with that name, the ARM compiler interprets the reference ambiguously or conflictingly during expression resolution. Renaming the variable to something like deployLocation solves the problem without any other changes.
The confirming clue is in the message: The language expression property 'location' cannot be used within a deployment at scope 'resourceGroup', indicating name collision with scope property, not restriction on literal strings.
Alternative A is incorrect: Azure accepts literal strings in location. Alternative D is incorrect: Bicep accepts variables as location value. The information about Contributor permissions and resource group existence is irrelevant and was included purposefully. The fact that az bicep build doesn't detect the error (alternative C) is true as an observation, but describes a tool limitation, not the root cause. The most dangerous distractor is A, as it leads the administrator to replace variables with resourceGroup().location without understanding that the problem is the variable name.
Answer Key — Scenario 4
Answer: A
The correct sequence is 3, 1, 2, 4, 5 because progressive diagnostic reasoning starts from the most specific available context.
The first step is to identify what changed (3), since the problem arose after a known modification. Next, validate the syntax of the modified file (1) to confirm if the modification introduced a structural error. Then, consult the activity log (2) to get the detailed ARM error message, which is more informative than the generic message. With the hypothetical cause identified, use what-if (4) to validate expected behavior before re-executing. Finally, if there's still doubt, test in an isolated environment (5).
Alternative C (2, 1, 3, ...) reverses the logic: consulting the log before knowing what changed is possible, but inefficient when the modification context is already available. Alternative B (1, 3, ...) compiles before seeing what changed, which can lead to fixing syntax errors without understanding the change intention. Alternative D starts with the isolated test environment, which introduces unnecessary overhead when steps 1 and 3 could already point to the cause.
Troubleshooting Tree: Modify an existing Bicep file
Legend
| Color | Node type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question (binary decision or observable) |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree facing a real problem, start with the root node describing the observed symptom and answer each question based on what you can directly verify: output from az bicep build, activity log message, or comparison with version history. Follow the path that corresponds to what you observe, not what you suppose. Each red node identifies a specific cause that requires its own corrective action; each orange node indicates that diagnosis still needs confirmation before acting.