Troubleshooting Lab: Export a deployment as an Azure Resource Manager template or convert an Azure Resource Manager template to a Bicep file
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator exported the ARM template from a resource group containing a storage account, an App Service plan, and a Web App. The resource group was created two years ago and never had its resources recreated. The subscription is active, the administrator has the Contributor role on the resource group, and the export completed without error messages in the portal.
When trying to redeploy the template to a new resource group in the same region, the deployment fails immediately during validation, before creating any resources.
The deployment command output is as follows:
$ az deployment group create \
--resource-group rg-destino \
--template-file exported-template.json \
--parameters @exported-parameters.json
ERROR: {"code": "InvalidRequestContent",
"message": "The request content was invalid and could not be deserialized:
'Required property 'properties' not found in JSON.
Path 'resources[2]', line 48, position 5.'"}
The administrator verifies that the file has 3 declared resources and that the first two pass validation. The third resource in the file corresponds to the Web App. The storage account was recently created as part of a separate test and has no relation to the Web App.
What is the root cause of the validation failure?
A) The exported parameters file is referencing values from a different subscription, causing resource ID incompatibility.
B) The exported template included runtime properties from the Web App that are not valid as input in the ARM schema, and the resulting properties block became incomplete or malformed.
C) The Contributor role does not have sufficient permission to redeploy Web Apps from exported ARM templates.
D) The storage account declared in the template conflicts with the Web App because both share the same name namespace in the destination region.
Scenario 2 — Action Decision
The infrastructure team identified that an ARM template in JSON stored in the company repository contains a copy loop to create multiple instances of a NIC. After running az bicep decompile, the generated .bicep file shows the following inline warning:
// WARNING: The following 'copy' loop could not be fully decompiled.
// Review and fix manually before deploying.
resource nic 'Microsoft.Network/networkInterfaces@2022-07-01' = [for i in range(0, nicCount): {
name: 'nic-${i}'
location: location
properties: {
// FIXME: ipConfigurations could not be resolved
}
}]
The cause has already been identified: the copy loop syntax in JSON did not have complete mapping to Bicep during decompilation. The team needs the Bicep file ready for deployment within two hours maximum. The production environment is operational and there is no active maintenance window. The repository uses mandatory pull request review before any merge.
What is the correct action to take at this time?
A) Re-run az bicep decompile with the --force flag to force automatic resolution of the loop and generate a file without warnings.
B) Open the generated .bicep file, manually fill in the ipConfigurations block with the correct Bicep syntax for the loop, validate with az bicep build, and submit via pull request.
C) Revert to the original JSON template and deploy it directly, discarding the Bicep conversion until a maintenance window is available.
D) Run az deployment group validate on the .bicep file with the warning present to check if ARM accepts the deployment even with the incomplete block.
Scenario 3 — Root Cause
An engineer successfully exported the ARM template from a resource group through the Azure portal. When opening the template.json file in VS Code with the Bicep extension installed, she executes the following command to convert the file:
$ az bicep build --file template.json
The command completes without errors and generates a file called template.json.bicep in the same directory. When opening this file, the engineer notices that the content is identical to the original JSON, containing no Bicep syntax.
The environment has the latest version of Azure CLI installed. The Bicep extension is version 0.24.24. VS Code displays no error alerts.
What is the root cause of the observed behavior?
A) The version of the Bicep extension installed in VS Code is incompatible with the az bicep build command, causing the output to be generated in the wrong format.
B) The az bicep build command compiles .bicep files to JSON and does not perform reverse conversion. The engineer used the opposite command to what was needed for the desired operation.
C) The template.json file exported by the portal contains a $schema property that prevents the Bicep tool from processing it correctly, forcing JSON output.
D) The az bicep build command requires the input file to have the .bicep extension. Having received a .json, the tool copied the file without processing.
Scenario 4 — Diagnostic Sequence
An administrator reports that after exporting the ARM template from a resource group and attempting to redeploy it in another region, the deployment fails. He doesn't know at which step of the process the problem was introduced.
The following investigation steps are available, but were listed out of order:
- Execute
az deployment group validateon the template and parameters file to identify schema errors before a new deployment attempt. - Open the exported
template.jsonfile and manually inspect if there are fixed region values in place of parameters or variables. - Check the error message returned by the failed deployment to determine which resource and property the validation failed on.
- Compare the exported template with a functional reference template for the same topology, identifying missing or extra properties.
- Fix the identified problematic values and execute a redeployment in incremental mode to validate the correction.
What is the correct investigation sequence?
A) 1 -> 2 -> 3 -> 4 -> 5
B) 3 -> 2 -> 4 -> 1 -> 5
C) 2 -> 4 -> 1 -> 3 -> 5
D) 3 -> 1 -> 2 -> 4 -> 5
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
Explanation:
- The error message indicates that ARM did not find the required
propertiesproperty in the third resource of the template, which corresponds to the Web App. This behavior is characteristic of exports that capture runtime attributes or computed states of the service, resulting in a malformed or incompletepropertiesblock when inserted as input in a new deployment. - The central clue in the scenario is that "the resource group was created two years ago and never had its resources recreated". Long-lived resources accumulate runtime properties that ARM registers in state but does not accept back as creation parameters.
- The information about the recently created storage account is intentionally irrelevant. The error explicitly points to
resources[2], the third resource, which is the Web App, and the storage account has no relation to it. - Alternative A is a classic diagnostic error: confusing subscription ID problems with schema errors. Alternative C is false because the Contributor role is sufficient for deployments. Acting on alternative D would lead the administrator to look for non-existent name conflicts, wasting time while the real problem remains in the template.
Answer Key — Scenario 2
Answer: B
Explanation:
- The cause is already identified in the scenario: the
copyloop was not decompiled correctly. The correct action is to manually fix the problematic block, validate compilation withaz bicep build, and follow the mandatory pull request flow. This approach respects all constraints: the two-hour deadline is viable for a targeted fix, the production environment is not touched, and the review process is maintained. - Alternative A is technically incorrect: the
--forceflag does not exist in theaz bicep decompilecommand and would not resolve a syntax mapping problem. - Alternative C ignores the time constraint and abandons the conversion objective without technical justification. Alternative D is the most dangerous: submitting to ARM a file with an empty
propertiesblock would result in production deployment failure, violating the premise that the environment is operational. The inline warning is an explicit indication that the file is not ready for deployment.
Answer Key — Scenario 3
Answer: B
Explanation:
- The
az bicep buildcommand has a specific and unidirectional function: compile a.bicepfile to ARM JSON. When receiving a.jsonfile as input, the documented behavior is to generate an output file with the same JSON content, as no decompilation transformation is performed by this command. The correct command for the desired operation, converting JSON to Bicep, isaz bicep decompile. - The most direct clue in the scenario is the generated file name:
template.json.bicep. This naming pattern is exactly whataz bicep buildproduces when receiving a.json: it adds.bicepas a suffix without transforming the content. - The information about the CLI and Bicep extension versions is intentionally irrelevant. The described behavior is the expected and documented behavior of the command, not a version bug.
- Alternative D is plausible but incorrect:
az bicep buildaccepts.jsonfiles as input without error, just without performing decompilation. Acting on alternative C would lead to unnecessary investigations into the exported template content, diverting from the real problem, which is using the incorrect command.
Answer Key — Scenario 4
Answer: B
Explanation:
- The correct sequence starts with the available concrete symptom: the error message from the failed deployment (step 3). This message indicates the problematic resource and property, guiding the investigation. With this information, the next step is to inspect the exported template to identify fixed region values or malformed properties (step 2). Then, comparing with a functional reference template helps confirm which properties are outside expectations (step 4). Before redeploying, validation via
az deployment group validate(step 1) avoids another production failure. Finally, correction and incremental redeployment (step 5) closes the cycle. - Alternative A makes the mistake of starting with validation before reading the original error message, losing the most direct diagnostic information available. Alternative C completely ignores the existing error message, which is the most efficient starting point. Alternative D splits the error message reading and validation into non-contiguous steps, introducing manual inspection in the middle without basis in the message that hasn't been read completely yet.
- The discipline of always starting from the concrete error before inspecting the template is what differentiates efficient diagnosis from a trial-and-error process.
Troubleshooting Tree: Export a deployment as an Azure Resource Manager template or convert an Azure Resource Manager template to a Bicep file
Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom or reported failure |
| Medium blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start with the root node describing the observed failure and answer each diagnostic question based on what you can directly verify in the terminal, portal, or file. Follow the path that corresponds to your scenario until reaching an identified cause node, then execute the corresponding recommended action and confirm the correction at the validation node before considering the problem resolved.