Deploy and manage Azure compute resources
This domain tests selecting and operating compute: virtual machines, scale sets, App Service, and containers, plus repeatable deployment with ARM or Bicep.
VM availability and disks
Availability sets protect against host failure using fault domains and update domains, with a 99.95% SLA; availability zones place VMs in separate datacenters for 99.99%. A VM belongs to one or the other, not both. Managed disks are the default; the temporary disk is not persistent. Resizing a VM may require deallocation. Extensions such as Custom Script and DSC handle post-deployment configuration. Proximity placement groups reduce network latency within a datacenter.
Deployment and platform services
ARM templates and Bicep are declarative and idempotent. Incremental mode leaves unmanaged resources alone; complete mode deletes resources in the scope that are not in the template, so use what-if first. App Service plans define compute. Deployment slots allow swap with warm-up, and slot settings stay with the slot. VM scale sets support autoscale, spot instances, and manual, automatic, or rolling upgrades. ACI runs single containers quickly; AKS orchestrates at scale; ACR stores images.
Worked example
An internet app needs 99.99% availability and zero-downtime releases. Deploy a VM scale set across three availability zones with a rolling upgrade policy, or use App Service with a staging slot and swap. Reasoning: zones address datacenter failure; rolling upgrades and slot swaps address deployment downtime. A single VM or an availability set cannot meet the zone-level SLA.
Traps
Availability sets cannot span zones. Stopping a VM in the guest OS may not stop billing; deallocate instead. Complete-mode deployments can delete resources. Swapping slots does not swap slot-specific settings. Scale set instance repair needs a health probe or the application health extension.