Deploy and manage Azure compute resources practice questions

ARM deployments run in one of two modes. Incremental (default) adds or updates resources defined in the template and leaves everything else alone. Complete makes the resource group match the template exactly, deleting resources that exist in the group but are not in the template.

Because the deployment used Complete mode and the template defines only the virtual network, the storage account and VM are not in the desired state and are deleted. 'Left unchanged' describes Incremental mode. The deployment does not error on extra resources — silent deletion is the documented (and dangerous) behavior. There is no recovery resource group or grace period for deleted resources.

1. Before any Complete-mode deployment, list what the template defines and compare it against the resource group's current contents.
2. Run the what-if operation ('az deployment group what-if' or -WhatIf) to preview exactly which resources would be deleted.
3. Only then deploy with '--mode Complete', or keep the default Incremental mode if extra resources must survive.

Exam tip: Complete mode deletes anything in the resource group that the template doesn't define — always preview with what-if first.

Incremental mode is the default for every ARM and Bicep deployment. It treats the template as additive: resources in the template are created or updated to match, and anything else in the resource group is ignored.

With no mode specified, Incremental applies, so the undeclared resources survive and only the template's resources are created or updated. Deleting undeclared resources is Complete-mode behavior and requires an explicit flag. There is no interactive mode prompt, and Incremental deployments have no requirement to describe the entire resource group.

1. Omit the mode parameter (or pass --mode Incremental) to get additive behavior — this is the safe default.
2. Verify with the deployment history in the portal that only template-defined resources were touched.
3. Reserve --mode Complete for cases where the template is intentionally the full source of truth for the group.

Exam tip: Incremental is the default deployment mode — it adds and updates but never deletes undeclared resources.

The what-if operation is ARM's change-preview feature. It evaluates the template against the target scope's live state and lists the effect on each resource — Create, Modify, Delete, NoChange, or Ignore — without applying anything.

What-if is purpose-built for this requirement: a per-resource change preview with no side effects. Validation only confirms the template is deployable, not what it would change. Manual diffs of exported templates are unreliable and not how Resource Manager evaluates changes. Deploying first and reading history violates the 'without changing anything' constraint — and doing so in Complete mode could destroy resources.

1. Run 'az deployment group what-if --resource-group RG --template-file main.bicep' (or add -WhatIf to New-AzResourceGroupDeployment).
2. Review the color-coded output: Create, Modify, and Delete entries show the exact properties that change.
3. Once the preview matches expectations, run the same command without what-if to apply the deployment.

Exam tip: Use what-if to preview a deployment's per-resource changes before applying anything — especially before Complete-mode deployments.

ARM and Bicep deployments run at one of four scopes: resource group, subscription, management group, or tenant. The scope determines which resource types the deployment can create — resource groups themselves and subscription-wide policy assignments are subscription-scope resources.

Creating resource groups and assigning policy across a subscription both require a subscription-scoped deployment, declared with targetScope = 'subscription' and run via 'az deployment sub create' or New-AzSubscriptionDeployment. A resource-group deployment can only place resources inside an existing group. Tenant scope is broader than needed for a single subscription's policy. And scope never escalates automatically — the declared targetScope governs.

1. Set 'targetScope = 'subscription'' at the top of the Bicep file.
2. Define the resource groups (Microsoft.Resources/resourceGroups) and the policy assignment in the file; use modules to deploy resources into the new groups.
3. Deploy with 'az deployment sub create --location <region> --template-file main.bicep' (location stores the deployment metadata).

Exam tip: Match the deployment scope to what the template creates — resource groups and subscription-wide policy require subscription-scope deployments.

An ARM template separates concerns into sections: parameters (deployment-time inputs), variables (internal computed values), resources (what gets deployed), and outputs (values returned after deployment). Functions like concat and resourceId glue them together.

Values supplied by the deployer — environment names, admin usernames, SKU choices — belong in parameters, the only section whose values come from outside the template at deployment time. Variables are derived internally and cannot be overridden at deploy time. Outputs are return values, the opposite direction. Resources declare infrastructure and merely reference the inputs.

1. Declare each input in the parameters section with a type, and add allowed values or defaults where sensible.
2. Reference the input in resources with the parameters() function (or directly by name in Bicep).
3. Supply values at deploy time via --parameters on the CLI or a parameter file per environment.

Exam tip: Parameters are deploy-time inputs, variables are internal calculations, outputs are return values.

Parameter files separate a template's logic from its environment-specific values. One template plus one parameter file per environment is the standard multi-environment pattern for ARM and Bicep (.parameters.json or .bicepparam).

Parameter files achieve the goal directly: a single, unchanging template and a small values file per environment, selected at deploy time. Duplicating the template three times creates drift and triple maintenance. Editing defaults before each deployment is manual toil with no repeatability. Hard-coding conditionals in variables couples environment data to template logic and still needs template edits for value changes.

1. Declare every environment-varying value (VM size, count, prefix) as a parameter in the single Bicep file.
2. Create dev.bicepparam, test.bicepparam, and prod.bicepparam, each supplying that environment's values.
3. Deploy with 'az deployment group create --template-file main.bicep --parameters prod.bicepparam' — the same command pattern for every environment.

Exam tip: One template, one parameter file per environment — never fork the template to vary its values.