3.1 - Deploy VMs, images and templates (ARM, Bicep)
AZ-104 objective 3.1 covers deploying Azure compute resources and infrastructure as code. To capture a reusable image you first generalize the VM so machine-specific identifiers are stripped: run sysprep on Windows, or the waagent -deprovision command on Linux. For availability, an availability set spreads VMs across fault and update domains inside one datacenter, while deploying across availability zones survives a whole datacenter outage and gives the highest single-region resilience. ARM templates are JSON documents with top-level sections including parameters, variables, resources and outputs, plus a schema property that declares the template language version; the resources element holds the actual Azure resources, a copy loop deploys multiple instances by iterating a count, and the reference and Key Vault reference functions pull secrets at deployment time without hardcoding them. A template that creates a new resource group and then places resources inside it must run at the subscription scope. Bicep is the cleaner, more concise language that compiles down to ARM, supports modules so you can reuse a self-contained deployment defined in a separate .bicep file, and can publish those modules to an Azure Container Registry for sharing. Expect scenarios that ask which image step, availability option or template construct fits.
Generalize before capturing an image = sysprep (Windows) or waagent -deprovision (Linux). Survive a whole datacenter outage = availability zones. Repeat a resource in a template = copy loop. Bicep compiles to ARM and supports reusable modules.
Practice questions
1. You must redeploy the exact same infrastructure repeatedly in a declarative, idempotent way on Azure. Which approach fits best?
- A Bicep or ARM template (correct answer)
- A manually written sequence of Azure CLI commands that an admin runs by hand each time
- A wiki of portal screenshots
- A one-off shell script per resource
Bicep and ARM templates are declarative infrastructure as code: you describe the desired state and Resource Manager makes deployments repeatable and idempotent. Manual CLI runs, screenshots, and one-off scripts are imperative and error-prone.
2. Within an availability set, what does a fault domain represent?
- A group of VMs sharing a common power source and network switch (correct answer)
- A logical grouping used only to schedule and stagger the rollout of planned maintenance and host operating system updates one batch at a time
- A separate Azure region
- A managed disk type
A fault domain is a set of VMs that share a common power source and network switch, so spreading VMs across fault domains protects against a single hardware or power failure. Staggered updates are the job of update domains.
3. Within an availability set, what is the purpose of update domains?
- They copy every VM disk to a paired secondary Azure region so the data survives the complete loss of the primary region during a disaster
- They ensure planned host maintenance reboots only one group of VMs at a time (correct answer)
- They filter inbound network traffic
- They set the VM disk tier
Update domains group VMs so that during planned host maintenance only one update domain is rebooted at a time, keeping the rest of the set running. Geo-replication is unrelated, traffic filtering is an NSG job, and disk tiers are separate.
4. You place VMs in a single availability set inside one datacenter. Against which failure does this design NOT protect?
- A single server rack losing its shared power feed, which is exactly the kind of localized hardware fault that spreading VMs across fault domains is meant to isolate
- The failure of the entire datacenter (correct answer)
- One host being rebooted for planned updates
- A single network switch failing
An availability set spreads VMs across fault and update domains within one datacenter, protecting against rack, switch, and maintenance failures, but not the loss of the whole datacenter. Availability zones are needed for datacenter-level resilience.
5. What are availability zones within an Azure region?
- Physically separate datacenters, each with independent power, cooling, and networking (correct answer)
- Logical racks inside a single datacenter that share the same power feed and cooling system but use different top-of-rack network switches
- Copies of data in a second region
- Different VM size families
Availability zones are physically separate datacenters within a region, each with its own power, cooling, and networking, so spreading VMs across zones survives a full datacenter failure. They are not racks in one building nor a second region.
6. You want the highest single-region availability for a group of VMs so they survive an entire datacenter outage. What should you use?
- An availability set, which only spreads the VMs across fault and update domains but still keeps every one of them inside a single physical datacenter building
- VMs distributed across two or more availability zones (correct answer)
- A single large VM
- A proximity placement group
Spreading VMs across two or more availability zones places them in physically separate datacenters, surviving a datacenter outage. An availability set only protects within one datacenter, one big VM is a single point of failure, and a proximity group reduces latency.