Task 3.1: Automate deployment of resources by using Azure Resource Manager (ARM) templates or Bicep files

• A@metadata({ allowedValues: [ 'Standard_D2s_v5', 'Standard_D4s_v5' ] })

  Incorrect

  @metadata only attaches descriptive data to the parameter; Resource Manager doesn't validate values against it.

• B@minLength(15)

  Incorrect

  A length limit checks how long the string is, not whether it's one of the two permitted sizes.

• C@description('Standard_D2s_v5 or Standard_D4s_v5')

  Incorrect

  A description documents the parameter for users and tools; it doesn't reject other values.

• D@allowed([ 'Standard_D2s_v5', 'Standard_D4s_v5' ])

  Correct

  @allowed defines the permitted values, and a deployment with any other value fails validation.

Parameter decorators in Bicep add constraints and metadata. @allowed lists the values a parameter accepts; @minLength, @maxLength, @minValue and @maxValue bound it; @description and @metadata only document it.

• AThe deployment ran in incremental mode

  Incorrect

  Incremental mode, the default, leaves resources that aren't in the template unchanged.

• BThe deployment used a parameters file from another environment

  Incorrect

  Parameter values change settings of the listed resources; they don't remove resources the template doesn't list.

• CThe template's storage account used the existing keyword

  Incorrect

  The existing keyword references a resource without deploying it; it can't delete other resources.

• DThe deployment ran in complete mode

  Correct

  In complete mode, Resource Manager deletes resources in the resource group that the template doesn't specify.

Incremental mode adds or updates what the template defines and leaves the rest. Complete mode deletes resources not in the template; Microsoft recommends deployment stacks for deletions.

• Aaz bicep build --file main.json

  Incorrect

  bicep build goes the other way: it compiles a Bicep file into an ARM JSON template.

• Baz deployment group export --name main.json

  Incorrect

  Exporting writes the template of a past deployment as JSON; it doesn't convert anything to Bicep.

• Caz bicep decompile --file main.json

  Correct

  decompile converts an ARM JSON template into a Bicep file on a best-effort basis, which you then review and fix.

• Daz bicep format --file main.json

  Incorrect

  bicep format tidies the layout of a Bicep file; it doesn't read JSON templates.

Decompiling turns ARM JSON into Bicep as a starting point. The result can need fixes, such as names and expressions the converter can't infer, so review it before deploying.

• AThree different names, because uniqueString is random on each run

  Incorrect

  uniqueString isn't random; it's a hash of its inputs, so the same input gives the same result.

• BOne name for both RG-A deployments, another name in RG-B

  Correct

  The hash of RG-A's ID is the same both times, so the second deployment updates the same account; RG-B's ID hashes differently.

• COne name for the three, because the subscription is the same

  Incorrect

  resourceGroup().id includes the resource group name, so RG-A and RG-B produce different hashes.

• DNo name, because concat can't take a function as an argument

  Incorrect

  Template functions can be nested, and concat accepts the string uniqueString returns.

uniqueString returns a 13-character deterministic hash of its parameters. Seeding it with resourceGroup().id gives a name that's stable for repeat deployments to one resource group and different in each resource group.

• Aoutput blobEndpoint string = stg.properties.primaryEndpoints.blob

  Correct

  Outputs return values from the deployment, which the pipeline can read.

• Bresource blobEndpoint 'Microsoft.Storage/storageAccounts@2023-05-01' existing

  Incorrect

  existing references a resource; it doesn't return a value to the caller.

• Cparam blobEndpoint string = stg.properties.primaryEndpoints.blob

  Incorrect

  Parameters are inputs given before deployment; they can't read deployed values.

• Dvar blobEndpoint = stg.properties.primaryEndpoints.blob

  Incorrect

  Variables are internal to the file and aren't returned.

Use output to return values such as endpoints or IDs from a deployment. The pipeline reads them from the deployment results.

• AThe history is unlimited and isn't trimmed

  Incorrect

  There's a limit of 800 per resource group.

• BOld entries are deleted automatically as the history nears 800

  Correct

  The history is limited to 800 deployments per resource group, and older ones are removed automatically.

• CDeployments fail once the history holds 800 entries

  Incorrect

  Azure deletes old entries automatically as the limit nears, so deployments keep working.

• DEach deployment overwrites the previous one in the history

  Incorrect

  Deployments are kept as separate entries up to the limit.

Deployment history per resource group is limited to 800 deployments. As the limit nears, Azure deletes older deployments from the history automatically.

• A"location": { "type": "securestring" }

  Incorrect

  This type changes how the value is handled, not its default, and location isn't secret.

• B"location": { "type": "string", "defaultValue": "westeurope" }

  Incorrect

  A fixed default ignores the resource group's region.

• C"location": { "type": "string", "defaultValue": "[resourceGroup().location]" }

  Correct

  resourceGroup().location returns the region of the target resource group as the default.

• D"location": { "type": "string", "allowedValues": [ "[resourceGroup().location]" ] }

  Incorrect

  allowedValues lists permitted values and doesn't provide a default.

Parameters can take a defaultValue expression. Using resourceGroup().location keeps resources in the group's region while still letting a caller override it.

• AExport supports 100 resources; export each resource separately

  Incorrect

  The limit is 200 resources, not 100.

• BExport needs the resource group to be locked first

  Incorrect

  Locks have nothing to do with exporting a template.

• CExport needs resources that were deployed by templates

  Incorrect

  Export from the resource group captures the current state of resources, whatever created them.

• DExport supports up to 200 resources; export a subset of them

  Correct

  Export from a resource group has a 200-resource limit, so select fewer resources or export them in batches.

Exporting a template from a resource group is limited to 200 resources, and the exported template may lack some password parameters you must add before redeploying. Exporting from deployment history returns the original template instead.