AZ-104 compute resources explained
Deploy and manage Azure compute resources is one of the two largest AZ-104 domains at 20–25%, and it has the most objectives. It covers four areas: automating deployments with ARM templates and Bicep, virtual machines and scale sets, containers in the portal, and Azure App Service. The questions range from reading a template to choosing between availability sets and zones.
ARM templates and Bicep
Reading a template
An ARM template is JSON with a fixed set of sections: parameters (values supplied at deployment), variables (values computed inside the template), resources (what gets deployed) and outputs (values returned afterwards). Bicep describes the same resources in a shorter syntax and compiles to ARM JSON.
The exam objectives use the verbs interpret and modify. Expect a snippet and a question such as “what will be deployed”, “which parameter must you change” or “why did the deployment fail”.
Deploying, exporting and converting
- Deploy with
az deployment group createorNew-AzResourceGroupDeployment, pointing at a template or Bicep file and a parameter file. - Incremental mode, the default, adds and updates resources and leaves others alone. Complete mode deletes resources in the resource group that are not in the template.
- Export an existing resource group or a past deployment as an ARM template from the portal.
- Convert ARM JSON to Bicep with
az bicep decompile. The result often needs tidying.
Virtual machines
Sizes and disks
VM sizes are grouped by series for general purpose, compute, memory, storage and GPU workloads. Resizing restarts the VM, and if the new size is not available on the current hardware cluster you must deallocate it first.
Managed disk types, from cheapest to fastest: Standard HDD, Standard SSD, Premium SSD, Premium SSD v2 and Ultra Disk. The OS disk and data disks are separate resources. You can attach and detach data disks, resize them up but not down, and take snapshots.
Encryption at host
Encryption at host encrypts the temporary disk and disk caches as well as the disks at rest. The feature must first be registered on the subscription, and the VM must be deallocated to enable it on an existing machine.
Moving VMs
| Target | How |
|---|---|
| Another resource group | Move the VM with its dependent resources, such as disks and NICs |
| Another subscription | Same, within the same Entra tenant |
| Another region | Azure Resource Mover or Azure Site Recovery |
Moving between resource groups or subscriptions does not change the region, and the VM keeps running in most cases.
Availability
| Option | Protects against |
|---|---|
| Availability set | Hardware and maintenance failures within one datacenter, using fault and update domains |
| Availability zones | Failure of a whole datacenter within a region |
A VM’s availability set is chosen at creation and cannot be changed later without recreating the VM. When a scenario mentions a datacenter failure, the answer is zones.
Virtual Machine Scale Sets
Scale sets run many identical or mixed VMs and scale on metrics or schedules. Autoscale rules need a scale-out rule and a matching scale-in rule, with sensible minimum, maximum and default instance counts. Scale sets can span availability zones.
Containers in the portal
| Service | Reach for it when |
|---|---|
| Azure Container Registry | Storing and versioning private images |
| Azure Container Instances | A single container or small group, quick to start, billed per second |
| Azure Container Apps | Microservices and APIs that need scaling, revisions and ingress |
ACR has Basic, Standard and Premium tiers; geo-replication needs Premium. In Container Instances, a container group shares a lifecycle and network, and you set CPU and memory per container. Container Apps scales with rules on HTTP traffic, events or CPU, and can scale to zero.
Azure App Service
Plans and scaling
The App Service plan defines region, operating system, tier and instance size. All apps in a plan share its resources. Scale up changes the tier or size; scale out changes the instance count, manually or with autoscale. Autoscale and deployment slots need the Standard tier or higher.
Domains, certificates and TLS
To map a custom domain you prove ownership with a TXT record, then point a CNAME (for a subdomain) or an A record (for the apex) at the app. TLS then needs a certificate bound to the domain: an App Service managed certificate, an imported one, or one from Key Vault. You can also enforce HTTPS only and set a minimum TLS version.
Backup, networking and slots
App Service backups copy the app’s content and configuration to a storage account. Networking settings include access restrictions, private endpoints for inbound traffic and virtual network integration for outbound traffic.
Deployment slots are live apps with their own hostnames. You deploy to staging, warm it up, then swap it with production. Settings marked as slot settings stay with the slot; all others move with the code.
Sample questions
Question 1. You redeploy an ARM template to a resource group to update one storage account. After the deployment, a virtual machine in the same resource group that is not in the template has been deleted. What caused this?
- A. The template was deployed in incremental mode
- B. A what-if operation was run before deployment
- C. The template was deployed in complete mode
- D. A CanNotDelete lock was applied to the resource group
Show answer
Answer: C
Complete mode removes any resource in the resource group that is not defined in the template. Incremental mode, the default, would have left the VM alone. A what-if operation only previews changes, and a resource lock would have prevented the deletion rather than caused it.
Want more questions like this? Full AZ-104 practice tests →
Question 2. A new version of a web app on App Service must be tested in production conditions and then released with no downtime, with the option to roll back in seconds. The app runs on the Standard tier. What should you use?
- A. A staging deployment slot and a swap
- B. Scale out the plan to three instances
- C. Back up the app and restore it after deploying
- D. Deploy the new version to a second App Service plan in another region
Show answer
Answer: A
A staging deployment slot lets you deploy and warm up the new version, then swap it into production without downtime, and swap back to roll back. Scaling out adds capacity but does not stage a release. A backup and restore is slow and interrupts the app. A second plan in another region adds cost and needs traffic routing that the requirement does not ask for.
Want more questions like this? Full AZ-104 practice tests →
Question 3. You must enable encryption at host on an existing Azure VM. The feature is already registered on the subscription. What must you do to the VM first?
- A. Resize it to a memory-optimised size
- B. Stop and deallocate it
- C. Move it into an availability zone
- D. Convert its disks to Ultra Disk
Show answer
Answer: B
Encryption at host can only be enabled on an existing VM while it is deallocated. Resizing, moving to a zone or converting disks to Ultra Disk is not required.
Want more questions like this? Full AZ-104 practice tests →
What to practise
Write a small Bicep file that deploys a VM, deploy it, change a parameter and redeploy. Export the resource group as a template and decompile it. Resize the VM, add a data disk and move it to another resource group. Then run a container in Container Instances and in Container Apps, and put a web app on App Service with a staging slot you swap twice. That covers every sub-section of the domain.