Deploy and Manage Compute Resources
Microsoft weights this domain at 20–25% of the AZ-104 exam, tied with identities and governance as the largest. It tests your ability to deploy, configure, scale, and secure Azure compute services including virtual machines, VM scale sets, containers, and App Service. Expect scenario-based questions requiring you to choose the right resource type, configuration option, or troubleshooting action. Mastery of limits, defaults, and the distinctions between similar services is essential.
ARM Templates and Bicep Deployments
Azure Resource Manager (ARM) templates are JSON files that declaratively define Azure infrastructure. Bicep is a domain-specific language that compiles to ARM JSON — it is not a separate deployment engine, it produces ARM templates.
Core Concepts
| Concept | ARM Template | Bicep |
|---|---|---|
| File format | JSON | .bicep |
| Verbosity | High (lots of boilerplate) | Low (concise syntax) |
| Compiles to | Itself | ARM JSON |
| Modules | Linked/nested templates | module keyword |
| State management | None (Azure tracks state) | None (same engine) |
| IDE support | JSON schema + snippets | Bicep VS Code extension |
Deployment modes:
- Incremental (default): Adds/updates resources in the template; resources NOT in the template are left untouched.
- Complete: Deletes resources in the resource group that are NOT in the template. Use with caution.
Deployment scopes: Resource group (most common), subscription, management group, tenant.
Key template sections: parameters, variables, resources, outputs, functions. The dependsOn property enforces explicit ordering; ARM resolves implicit dependencies automatically via resource references.
What-if operation: Run az deployment group what-if or New-AzResourceGroupDeployment -WhatIf to preview changes before applying.
Common Traps
- The default deployment mode is Incremental, not Complete. The exam may imply you need to remove resources and ask which mode — answer is Complete.
- Bicep does not replace ARM; it transpiles to ARM. You can decompile existing ARM JSON to Bicep with
bicep decompile. dependsOnis needed only when ARM cannot infer the dependency (e.g., a script extension that must run after a VM but isn't referencing it directly).- Linked templates must be accessible via a URI (e.g., Azure Blob Storage). Bicep modules can reference local files or Azure Container Registry.
Worked Scenario
Requirement: You have an ARM template deployment that should automatically delete resources removed from the template on each run.
Answer: Set mode: 'Complete'. Incremental (the default) would leave old resources in place.
VM Sizes, Disks, and Encryption
VM Size Families
| Series | Optimized For | Example Sizes |
|---|---|---|
| B | Burstable, dev/test | B1s, B2ms |
| D/Ds | General purpose | D4s_v5 |
| E/Es | Memory optimized | E8s_v5 |
| F/Fs | Compute optimized | F8s_v2 |
| N (NC/NV/ND) | GPU workloads | NC6, NV6 |
| M | Memory-intensive (SAP HANA) | M128ms |
| L | Storage optimized | L8s_v3 |
Changing a VM size requires deallocating the VM first (unless the new size is in the same cluster/size family and the platform supports in-place resize — but for the exam, assume deallocation is required).
Managed Disk Types
| Disk Type | Use Case | Max IOPS (per disk) | Max Throughput |
|---|---|---|---|
| Ultra Disk | Highest perf, latency-sensitive | 160,000 | 2,000 MB/s |
| Premium SSD v2 | Flexible perf, production DB | 80,000 | 1,200 MB/s |
| Premium SSD (P-series) | Production workloads | 20,000 | 900 MB/s |
| Standard SSD (E-series) | Web servers, light prod | 6,000 | 750 MB/s |
| Standard HDD (S-series) | Backup, archive, dev/test | 2,000 | 500 MB/s |
Key disk facts:
- Ultra Disk and Premium SSD v2 require the VM to be in an Availability Zone — they cannot be used with Availability Sets.
- OS disk maximum size is 4 TiB (managed disk); data disks up to 32 TiB.
- Ephemeral OS disks are stored on the VM host (local SSD); they offer lower latency, no storage cost, and are ideal for stateless workloads. They are lost on deallocation.
- Disk caching: OS disk default = Read/Write; Data disk default = None. Premium SSD supports Read-only and Read/Write caching.
Encryption Options
| Option | Who Manages Keys | Encrypts At Rest | Encrypts In-Transit (host) |
|---|---|---|---|
| SSE with PMK | Microsoft (Platform Managed) | Yes | No |
| SSE with CMK | Customer (via Key Vault) | Yes | No |
| Azure Disk Encryption (ADE) | Customer (BitLocker/DM-Crypt) | Yes (OS+data) | No |
| Encryption at host | Platform + optional CMK | Yes (temp disk too) | Yes |
| Confidential disk encryption | Customer, hardware-isolated | Yes | Yes |
SSE = Server-Side Encryption (default for all managed disks, uses PMK unless CMK is configured). ADE uses BitLocker (Windows) or DM-Crypt (Linux) inside the VM — it does NOT encrypt temp/ephemeral disks.
Common Traps
- The exam may ask which disk type supports the highest IOPS — answer is Ultra Disk.
- Ultra Disk and Premium SSD v2 are not available with Availability Sets — only with Availability Zones.
- Ephemeral OS disks are lost on deallocation/resize — not suitable for stateful workloads.
- ADE requires a Key Vault in the same region. Enabling ADE after deployment is supported.
- Standard HDD has no SLA for single-instance VMs; Premium SSD gives 99.9% SLA for single-instance VMs.
Unlock with a paid plan
9 more sections (about 2,747 words) continue below. Every paid plan unlocks all AZ-104 study guides, the full question bank and mock exams, from $4.97/month.