Study Guides/AZ-104/Deploy and Manage Azure Compute Resources
20-25% of exam

Deploy and Manage Azure Compute Resources

Deploy virtual machines, scale sets, containers, and App Service, and automate deployment with ARM templates and Bicep.

Virtual machines: sizing, disks, and availability

A virtual machine's size determines its CPU, memory, and the maximum number and throughput of attached disks — changing size later is possible but requires a restart.

Disk types

  • OS disk: contains the operating system; every VM has exactly one.
  • Data disk: additional managed disk attached for application data; a VM can have several, depending on its size.
  • Temporary disk: local, non-persistent storage that can be lost on reallocation — never store data here that must survive a restart.
  • Disk tiers: Standard HDD, Standard SSD, Premium SSD, and Ultra Disk, trading cost against IOPS and latency.

Availability options

  • Availability Set: groups VMs into fault domains (separate hardware/power) and update domains (separate maintenance windows) within one datacenter.
  • Availability Zone: spreads VMs across physically separate datacenters within a region, protecting against a full datacenter outage.
  • Virtual Machine Scale Set (VMSS): manages a group of identical, load-balanced VMs that can scale in or out automatically based on demand or a schedule.

Common confusion

  • An Availability Set protects against rack-level and maintenance-related failures; only Availability Zones protect against an entire datacenter going offline.

Containers and App Service

Not every compute workload needs a full VM. Azure offers managed options that remove operating-system maintenance entirely.

Container options

  • Azure Container Instances (ACI): runs a single container or container group quickly, without managing an orchestrator — good for short-lived or simple workloads.
  • Azure Kubernetes Service (AKS): a managed Kubernetes cluster for workloads needing orchestration, scaling, and self-healing across many containers.

App Service

  • Hosts web apps, REST APIs, and mobile backends without managing the underlying VM or OS.
  • An App Service Plan defines the underlying compute (size and scaling); multiple apps can share one plan.
  • Deployment slots (for example, staging and production) allow a new version to be validated and then swapped into production with no downtime.
  • Scaling can be manual, scheduled, or rule-based (autoscale) driven by metrics such as CPU or request queue length.

Common confusion

  • Scaling up changes the App Service Plan's tier (more CPU/memory per instance); scaling out changes the instance count. Autoscale rules apply to scaling out, not up.

ARM templates, Bicep, and repeatable deployment

Manually clicking through the Azure portal doesn't scale and isn't repeatable. Infrastructure as code solves this by describing the desired resource state declaratively.

ARM templates

  • JSON documents describing resources, their properties, and dependencies between them.
  • Support parameters (inputs) and variables (computed or reused values) to make templates reusable across environments.
  • Deployments are idempotent — deploying the same template twice converges to the same state rather than duplicating resources.

Bicep

  • A simpler, more readable domain-specific language that compiles down to ARM template JSON.
  • Same deployment engine and capabilities as ARM templates, but with less syntax overhead and better tooling support.

Deployment modes

  • Incremental (default): adds or updates resources defined in the template, leaving unrelated existing resources in the resource group untouched.
  • Complete: adds or updates resources in the template, and deletes any resource in the resource group that isn't defined in it — use with caution.