Domain 3: Deploy and Manage Azure Compute Resources

Exam weight: 20–25% — the highest-weight domain

Compute tests your ability to deploy and operate Azure's virtual machines, scale sets, App Service, and understand ARM templates. The live lab tasks most frequently involve compute operations — deploying VMs, configuring availability, and scaling.

3.1 Virtual Machines

VM Size Families

You don't need to memorize every VM size, but you need to know the families:

Exam tip: If a question says "cost-effective for workloads with variable CPU that don't run at 100% constantly," the answer is B-series (burstable).

VM Disks

Managed disk SKUs:

Exam trap: The temporary disk is lost when a VM is stopped (deallocated), resized, or the underlying host is patched. Never store anything important on the temp disk. The D: drive (Windows) or /dev/sdb (Linux) is typically the temp disk.

VM Extensions

Extensions run post-deployment scripts or install agents. Common ones:

• Custom Script Extension — run a shell/PowerShell script after deployment
• Azure Monitor Agent — collect metrics and logs
• Azure AD / SSH login — passwordless login with Entra credentials

3.2 VM Availability

This is the most confusing part of Domain 3. Three mechanisms, very different guarantees.

Availability Sets

Groups VMs across Fault Domains (FDs) and Update Domains (UDs) within a single datacenter.

Guarantee: 99.95% SLA. Does NOT protect against datacenter-level failure (fire, flood, power outage for the entire DC).

Exam trap: Availability sets are configured at VM creation — you cannot add a running VM to an availability set. A VM in an availability set cannot use Ultra Disk or Premium SSD v2.

Availability Zones

Physically separate datacenters within a region, each with independent power, cooling, and networking.

• 3 zones per region (where available).
• VMs in different zones are protected against datacenter-level failures.
• SLA: 99.99% (higher than availability sets).

Exam trap: Availability zones and availability sets are mutually exclusive for a given VM — choose one or the other.

Virtual Machine Scale Sets (VMSS)

Automatically deploy and manage a group of identical VMs, scaling in/out based on demand.

Exam trap: VMSS with Uniform orchestration requires all VMs to use the same image and size. Flexible orchestration allows heterogeneous VMs and is the recommended mode for new deployments.

Comparison

3.3 Azure Bastion

Azure Bastion provides browser-based SSH/RDP access to VMs without a public IP on the VM.

• Deployed into a dedicated subnet named exactly AzureBastionSubnet with a minimum /26 CIDR.
• Requires a Standard SKU Public IP.
• No VPN, no public IP on the VM, no NSG changes needed on the VM subnet.

Exam trap: The subnet must be named exactly AzureBastionSubnet — any other name causes deployment to fail.

Bastion SKUs:

3.4 ARM Templates

ARM templates are JSON files that declare Azure resources. They enable Infrastructure as Code (IaC) for repeatable deployments.

Template Structure

{
  "$schema": "...",
  "contentVersion": "1.0.0.0",
  "parameters": {         // User inputs at deploy time
    "vmName": {
      "type": "string",
      "defaultValue": "myVM"
    }
  },
  "variables": {          // Computed values reused within the template
    "nicName": "[concat(parameters('vmName'), '-nic')]"
  },
  "resources": [          // The actual resources to deploy
    {
      "type": "Microsoft.Compute/virtualMachines",
      "apiVersion": "2023-03-01",
      "name": "[parameters('vmName')]",
      "location": "[resourceGroup().location]",
      "properties": { ... }
    }
  ],
  "outputs": {            // Values returned after deployment
    "vmId": {
      "type": "string",
      "value": "[resourceId('Microsoft.Compute/virtualMachines', parameters('vmName'))]"
    }
  }
}

Key ARM Functions (exam-tested)

Deployment Commands

# Deploy to a resource group
az deployment group create \
  --resource-group rg-prod \
  --template-file azuredeploy.json \
  --parameters @azuredeploy.parameters.json

# What-if (preview changes without deploying)
az deployment group what-if \
  --resource-group rg-prod \
  --template-file azuredeploy.json

# Validate (syntax check only)
az deployment group validate \
  --resource-group rg-prod \
  --template-file azuredeploy.json

3.5 Bicep

Bicep is Azure's domain-specific language for IaC — it compiles to ARM JSON. It's simpler syntax, better IntelliSense, and the recommended approach for new deployments.

param location string = resourceGroup().location
param vmName string = 'myVM'

resource vm 'Microsoft.Compute/virtualMachines@2023-03-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

Key commands:

az bicep build --file main.bicep          # Compile to ARM JSON
az deployment group create \
  --resource-group rg-prod \
  --template-file main.bicep             # Deploy Bicep directly (CLI handles compilation)

Exam tip: The exam may show both ARM JSON and Bicep snippets. Know what each section does (parameters, variables, resources, outputs) and how to reference parameter values with [parameters('name')] (ARM) or just paramName (Bicep).

3.6 Azure App Service

App Service is a fully managed PaaS for web apps, REST APIs, and mobile backends.

App Service Plans

The plan defines the compute resources for all apps hosted on it.

Exam trap: Deployment slots (blue/green) require Standard tier or above. Free and Basic plans do not support slots.

Exam trap: Auto-scaling requires Standard tier or above. Basic only supports manual scaling.

Deployment Methods

Deployment Slots

A staging slot is a separate running instance of your app — deploy to staging, test, then swap to production. Swap is near-instant with no downtime.

# Create a staging slot
az webapp deployment slot create \
  --name myapp \
  --resource-group rg-prod \
  --slot staging

# Swap staging → production
az webapp deployment slot swap \
  --name myapp \
  --resource-group rg-prod \
  --slot staging \
  --target-slot production

3.7 Azure Container Instances (ACI)

ACI runs containers without managing VMs — the simplest way to run a container in Azure.

• No cluster management, no orchestration
• Billed per second of CPU/memory used
• Supports Linux and Windows containers
• Can mount Azure File shares as volumes
• Suitable for: CI/CD jobs, batch tasks, simple stateless APIs

Exam tip: The exam often presents a scenario with a short-lived container workload (data processing job, nightly batch) and asks which compute service to use. ACI is the answer for simple container tasks; AKS for long-running containerized apps at scale.

Section Takeaways

Confusing Points — Clarified

Q: Can I move a VM from one availability set to another? A: No. Availability set membership is set at VM creation and cannot be changed. You'd need to delete and recreate the VM.

Q: What's the difference between stopping (deallocated) and stopping (stopped/not deallocated)? A: A deallocated VM releases the underlying hardware — you are not billed for compute. The public IP (if dynamic) is released. A stopped (not deallocated) VM keeps the hardware reserved — you still pay. In the portal, clicking "Stop" deallocates by default.

Q: Does a VMSS automatically scale in (remove instances) as well as out? A: Yes, if you configure autoscale rules for both scale-out and scale-in. By default, you can set a minimum instance count so it never scales in below that threshold.

Q: When I swap a deployment slot, does the connection string also swap? A: By default, yes — all settings swap. But settings marked as slot settings (sticky) stay with their slot and don't swap. Use sticky settings for things like connection strings pointing to each environment's specific database.