Skip to main content

Technical Lab: Export a deployment as an Azure Resource Manager template or convert an Azure Resource Manager template to a Bicep file

Questions​

Question 1 — Multiple Choice​

An administrator needs to replicate the exact configuration of an existing resource group in a new subscription. He accesses the Azure portal, navigates to the resource group, and uses the Export template option.

What is the most important limitation he should consider before using this exported template directly in production?

A) The exported template never includes network resources, requiring manual reconstruction of VNets.

B) The exported template may contain fixed values instead of parameters, reducing portability and requiring manual editing before reuse.

C) The exported template is generated in Bicep format and needs to be converted to JSON before being deployed via Azure CLI.

D) The Azure portal only allows exporting templates from resource groups with fewer than 10 resources, blocking larger exports.

Question 2 — Technical Scenario​

A team received the following JSON ARM template for review:

{
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2022-09-01",
      "name": "mystorage",
      "location": "eastus",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "StorageV2"
    }
  ]
}

The team wants to convert this file to Bicep to facilitate maintenance. Which command produces the equivalent Bicep file from this JSON?

A) az bicep build --file template.json --outfile template.bicep

B) az bicep decompile --file template.json

C) az deployment group export --template-file template.json --language bicep

D) bicep convert --input template.json --output template.bicep

Question 3 — True or False​

When executing az bicep decompile on a complex ARM template, the generated Bicep file is always functionally equivalent to the original JSON and can be deployed immediately without any manual review.

(True / False)

Question 4 — Technical Scenario​

An engineer exported an ARM template through the Azure portal immediately after creating an Azure Function App that uses a consumption plan. When attempting to redeploy this template to another resource group, the deployment fails with a validation error related to unsupported properties.

What is the most likely cause of this behavior?

A) The Azure portal does not support exporting Microsoft.Web type resources, requiring export exclusively via CLI.

B) The template exported by the portal may capture read-only properties or runtime states that are not valid as input in a new deployment.

C) The consumption plan for Azure Functions cannot be described in ARM templates and requires manual deployment through the portal.

D) The engineer should have used az group export with the --include-parameter-default-value flag to avoid the error.

Question 5 — Multiple Choice​

Considering the available approaches to obtain an ARM template from an existing deployment, what is the functional difference between using Export template on the resource group and accessing the deployment history through the Deployments menu of the same group?

A) Exporting by resource group generates native Bicep, while deployment history generates only JSON.

B) The deployment history preserves the template exactly as it was originally submitted, while resource group export reflects the current inferred state of provisioned resources.

C) Both approaches produce identical templates; the difference is only in the navigation interface used.

D) Deployment history is only available for subscriptions with an active Premier support plan.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Explanation:

  • The Azure portal export mechanism performs reverse engineering of the current resource state. In this process, values that should be parameterized (such as location, names, and SKUs) often appear as fixed literals in the generated JSON. This compromises template reusability without prior editing.
  • Alternative A is false: network resources are normally included in the export. Alternative C reverses the actual behavior: the default export generates JSON, not Bicep. Alternative D does not correspond to any limit documented by Microsoft.
  • Using a template with fixed values in production without review can cause name collisions, deployments in the wrong region, or organizational policy violations.

Answer Key — Question 2​

Answer: B

Explanation:

  • The correct command to convert an ARM JSON template to Bicep is az bicep decompile --file template.json. This command reads the JSON file and generates a .bicep file in the same directory with the same base name.
  • Alternative A describes the reverse process: az bicep build compiles a .bicep file to JSON, not the other way around. Alternative C mixes deployment export commands with non-existent flags. Alternative D uses syntax that doesn't exist in Azure CLI or the bicep executable.
  • Confusing build with decompile is a common operational error and results in immediate command failure or generation of a file in the opposite format to what's desired.

Answer Key — Question 3​

Answer: False

Explanation:

  • Decompilation via az bicep decompile is a best-effort process. The Bicep compiler explicitly warns that the generated file may contain errors, warning comments, or constructs that need manual adjustment, especially in templates with nested resources, complex expressions, copy loops in JSON, or properties without direct mapping in Bicep.
  • Functional equivalence needs to be verified, and the generated file should be reviewed before any deployment. Assuming automatic equivalence is a real operational risk that can cause deployments with different behavior than expected.

Answer Key — Question 4​

Answer: B

Explanation:

  • Portal export captures the state persisted in Azure Resource Manager, which may include computed properties, read-only fields, and runtime attributes automatically inserted by the service. When this template is submitted as input in a new deployment, ARM rejects properties that are not part of the resource's input schema.
  • Alternative A is incorrect: the portal supports exporting Microsoft.Web resources. Alternative C is false: consumption plans have complete representation in ARM and Bicep. Alternative D mentions a real flag (--include-parameter-default-value), but it controls parameter default values and doesn't resolve the read-only properties problem.
  • This behavior reinforces the need to review and clean exported templates before using them as a base for new deployments.

Answer Key — Question 5​

Answer: B

Explanation:

  • Deployment history stores the template exactly as it was sent to ARM at the time of original deployment, including its parameters and structure declared by the author. Resource group export reconstructs a template from the current inferred state of each provisioned resource, which may differ from the original template due to omissions, restructuring, or addition of default properties.
  • Alternative A is incorrect regarding format: both sources produce JSON by default. Alternative C ignores a fundamental and documented difference between the two approaches. Alternative D does not correspond to any real support plan restriction.
  • To reproduce a deployment with maximum fidelity to what was originally applied, deployment history is the most reliable source.