AZ-104 Skill 3: Deploy and Manage Azure Compute Resources

Deep-dive guide | Virtual Machines, Containers, App Service, and Infrastructure as Code for the Azure Administrator

Compute is where code actually runs. Whether it’s a legacy enterprise application running on a virtual machine, a cloud‑native microservice in a container, or a web app on a fully managed platform, everything you built with identity, governance, storage, and networking ultimately serves the compute layer. Microsoft allocates 20–25% of the AZ‑104 exam to this area because deploying, scaling, and managing compute is the administrator’s most visible and operationally critical task.

This guide moves far beyond the exam objectives. It connects each measured skill to the underlying Azure domains, the architectural patterns that dictate platform choice, and the real‑world trade‑offs you’ll face when deciding between VMs, containers, or platform services.

1. Overview

#

Compute is the heart of every cloud platform. It provides the processing power that executes your code, serves your users, and processes your data. In Azure, “compute” spans a spectrum of control vs. responsibility:

• Infrastructure as a Service (IaaS): Virtual Machines, VM Scale Sets – you manage the OS, patches, and runtime.
• Platform as a Service (PaaS): App Service, Azure Container Apps – Azure manages the infrastructure, you bring the code or containers.
• Serverless/Consumption: Azure Functions, Container Instances – you pay only when your code runs.

As an Azure administrator, you are responsible for deploying, configuring, scaling, securing, and maintaining these resources. Your choices directly affect performance, cost, availability, and the speed at which your organization can release software.

Compute is also deeply interconnected with every other Azure pillar:

• Identity: Managed identities and RBAC control access to compute resources.
• Networking: VNets, subnets, NSGs, and load balancers define how compute resources communicate.
• Storage: Managed disks, file shares, and blob storage provide persistent data.
• Monitoring: Metrics, logs, and alerts keep you aware of compute health and performance.

2. Skill Area Breakdown

#

Microsoft groups the compute skill area into four measured sub‑skills.

Infrastructure as Code (IaC)

#

Automating resource deployment is no longer optional. AZ‑104 expects you to understand and modify ARM templates and Bicep files.

• ARM Templates: JSON‑based declarative definition of all Azure resources and their properties.
• Bicep: A domain‑specific language that transpiles to ARM JSON, with simpler syntax and modularity.
• Key tasks: Interpret an existing template, modify parameters/variables/resources, deploy using portal/CLI/PowerShell, export a resource group’s deployment as a template, and convert ARM to Bicep.

IaC ensures repeatable, auditable, and consistent environments. In production, it is the foundation of DevOps pipelines and immutable infrastructure.

Virtual Machines

#

The classic IaaS compute unit. Administrators manage the full VM lifecycle.

• Creation: select OS image, size, disks, networking, management options.
• Encryption: enable encryption at host (server‑side encryption at the virtualization host) or Azure Disk Encryption (in‑guest BitLocker/DM‑Crypt).
• Mobility: move VMs to another resource group, subscription, or region (requires Azure Resource Mover or VM backup/restore).
• Sizing: scale up/down by changing VM size, understanding the impact of resizing on memory, CPU, and connected disks.
• Disk management: OS disks, data disks, temporary disks; managed vs. unmanaged; snapshot and restore; expand disks.
• High availability: deploy to availability sets (fault/update domains) or availability zones (physical separation); understand SLAs.
• Scale Sets: deploy and configure VMSS for horizontal scaling; auto‑scale rules based on metrics.

Containers

#

Containers package applications with their dependencies, enabling portability and density.

• Azure Container Registry (ACR): private Docker registry for storing container images; manage replication, admin keys, and access control.
• Azure Container Instances (ACI): fastest way to run a container without managing servers; good for burst workloads, task processing, and simple apps.
• Azure Container Apps (ACA): serverless containers on top of Kubernetes, with built‑in service discovery, scaling, and ingress; ideal for microservices and event‑driven apps.
• Scaling: configure HTTP scaling, event‑driven scaling (KEDA), and revisions.

App Service

#

Azure’s fully managed web hosting platform supporting .NET, Java, Node.js, Python, PHP, and containers.

• App Service Plan: defines the region, scaling model, and instance size; shared across multiple App Services.
• Scaling: scale up (change plan tier) or scale out (add instances, manual or auto‑scale rules).
• App creation: deploy code from Git, Docker Hub, or zip; configure application settings and connection strings.
• Certificates & TLS: upload private certificates or use Azure‑managed; enforce HTTPS‑only, set minimum TLS version.
• Custom domains: validate ownership with CNAME/A records; bind domain to app.
• Backups: configure automated backups to a storage account (requires Standard plan or above).
• Networking: VNet integration (outbound), private endpoints (inbound), access restrictions.
• Deployment slots: staging slots for zero‑downtime deployments and rollbacks; swap slots to promote code.

3. Azure Domains Mapping

#

Each exam skill taps into one or more foundational Azure domains that define the service categories and capabilities.

Recognizing the domain helps you retrieve the correct knowledge when answering a scenario question. For instance, a question about scaling a web app under load is a Compute domain question, but also touches Application Platform. An IaC question is primarily an Automation domain question.

4. Azure Architecture Mapping

#

Architecture decisions determine which compute service to use, how to make it resilient, and how to manage its lifecycle at scale.

Compute Architecture

#

The core design question: where should this workload run on the IaaS‑PaaS‑Serverless spectrum?

• Control vs. overhead: VMs give full control (OS, registry, custom agents) but require patching and maintenance. App Service and Container Apps abstract away the OS, shifting effort to application code.
• Scalability: VMs scale vertically (resize) or horizontally (Scale Sets). Platform services scale horizontally natively with auto‑scale rules.
• Cost model: VMs are provisioned, you pay for allocated time; serverless is consumption‑based. Choosing the wrong model leads to either overspend or performance issues.

VM‑Based Architecture

#

Used when the workload demands OS‑level access, custom network drivers, or legacy runtime environments.

• Lift‑and‑shift: Moving existing servers to Azure with minimal changes. VMs are the natural choice.
• High availability design: A single VM has an SLA of 99.9%. Add an availability set (SLA 99.95% for multi‑VM) or availability zones (SLA 99.99% for zone‑redundant VMs). The exam tests your ability to choose.
• VMSS for scaling: Use when you need to distribute load and add/remove instances based on demand. VMSS integrates with load balancers and auto‑scale.

Container Architecture

#

Containers decouple the application from the underlying OS, enabling consistency across environments.

• ACI for simple tasks: No orchestration overhead; ideal for batch jobs, CI/CD agents, or short‑lived services.
• Container Apps for microservices: Provides Kubernetes‑powered serverless containers with scale‑to‑zero, revision management, and ingress. Good for cloud‑native apps without managing Kubernetes.
• AKS (Azure Kubernetes Service): Not heavily tested in AZ‑104 but you must know when to choose ACR to store images for AKS.

Serverless Architecture

#

Azure Functions and Logic Apps are beyond the scope of AZ‑104 compute, but Container Apps and App Service both have serverless‑like consumption tiers.

• Scale to zero: Containers stop when not in use, reducing cost.
• Event‑driven scaling: KEDA triggers (messages in a queue, HTTP requests) automatically scale instances.

High Availability Architecture

#

The exam frequently asks about availability options.

• Availability Set: Group of VMs spread across different racks within a datacenter. Only protects against hardware failures within a region.
• Availability Zones: Physically separate locations within a region. Protects against entire datacenter failure. Use for critical workloads.

Infrastructure as Code Architecture

#

Automation ensures that compute environments are created identically every time, reducing configuration drift and enabling disaster recovery.

• Declarative model: ARM and Bicep define the desired state. Azure Resource Manager ensures the resources match that state.
• Modularity: Bicep modules allow reuse of code. ARM linked templates serve a similar purpose but are more cumbersome.

5. Azure Services Deep Dive

#

Azure Virtual Machines

#

• Architecture: A VM consists of compute (vCPUs, RAM) and storage (OS disk, data disks). The OS disk is where the operating system resides; data disks hold application data. A temporary disk (D: on Windows, /dev/sdb on Linux) is ephemeral.
• Sizing: Choose a series based on workload: General purpose (D, B‑series), Compute optimized (F), Memory optimized (E, M), Storage optimized (L). Changing size may require deallocation.
• Disks: Managed disks abstract away storage accounts, are highly durable, and support snapshots. Encryption at host encrypts data on the VM host itself before it reaches Azure Storage; Azure Disk Encryption encrypts inside the guest OS.
• Availability: At creation, specify availability set or zone. Moving a VM between availability sets is not direct; you recreate it.

Azure Virtual Machine Scale Sets (VMSS)

#

• Purpose: Manage a group of identical, auto‑scaling VMs. You define a configuration (image, size, networking) and scaling rules.
• Scaling: Schedule‑based (scale to N instances at a specific time) or metric‑based (CPU > 70% for 10 minutes → add 2 instances). Scale‑in policy determines which VMs are removed (oldest, newest, random).
• Updates: Rolling upgrade policies update VMs in batches; maximum surge creates new VMs before deleting old ones for zero downtime.

Azure App Service

#

• App Service Plan: Compute resources for your apps. A single plan can host multiple web apps, API apps, and function apps (when using dedicated App Service plan). Changing a plan’s tier affects all apps in it.
• TLS/SSL: App Service can generate free managed certificates or you can import PFX certificates. To bind a custom domain, you must verify domain ownership and add a TLS binding.
• Backup: Backs up configuration and content to a storage account. Can be scheduled; retention in days. Requires Standard tier or above.
• Networking: VNet Integration (outbound) allows apps to reach resources in a VNet without a private endpoint. Access Restrictions allow/deny IP ranges and service tags.
• Deployment Slots: Each slot is a live app with its own hostname. You can warm up a staging slot, then swap (the operation changes the routing, zero cold starts). Slot‑specific settings (connection strings) can be marked as “sticky”.

Azure Container Registry (ACR)

#

• Image storage: ACR stores Docker images and OCI artifacts. SKU tiers (Basic, Standard, Premium) differ in storage, throughput, and replication.
• Authentication: Use admin user (not recommended for production) or Azure AD with RBAC. az acr login uses your Azure AD token.
• Tasks: ACR Tasks can build container images in the cloud without a local Docker engine. (Less likely in AZ‑104 but good to know.)

Azure Container Instances (ACI)

#

• Lightweight: Single containers with no orchestration. You define CPU, memory, port, and restart policy. Can be exposed with a public IP or integrated into a VNet.
• Use cases: CI/CD agents, data processing jobs, simple stateless web services.
• Limitations: No auto‑scaling; you can’t update an ACI; you redeploy a new one.

Azure Container Apps (ACA)

#

• Serverless containers: Built on Kubernetes but abstracted. You define container apps with multiple revisions. Auto‑scale from 0 to N based on HTTP traffic or KEDA scalers.
• Features: Dapr integration, ingress with TLS, secrets management, and environment‑level networking.

ARM Templates and Bicep

#

• ARM Template: JSON file with schema, parameters, variables, resources, outputs. Every resource must be defined with its type, apiVersion, name, location, and properties.
• Bicep: Cleaner syntax, supports comments, modules, and auto‑completion. A Bicep file compiles to an ARM JSON template. You can deploy both using az deployment group create.
• Common exam task: You’ll be shown a snippet with a missing property or an incorrect parameter; you must identify what to add or change. Focus on understanding dependsOn, copy loops, and parameter types.

6. Compute Decision Framework

#

Choosing the right compute platform is a core administration skill. The table below summarizes the decision points.

Operational complexity and cost:

• VMs: highest control, highest management overhead (patching, monitoring, scaling scripts).
• App Service: low management, moderate cost, many enterprise features out of the box.
• Container Apps: low management, consumption pricing can be very cost‑effective for variable workloads.
• ACI: minimal management, pay per second, but limited networking and no auto‑scale.

7. Real‑World Enterprise Scenario

#

Company: Fabrikam, a manufacturing firm, is modernizing its application landscape.

Workloads:

• ERP system: Monolithic legacy application running on Windows Server 2016 with SQL Server. Must be highly available and able to scale vertically.
• Customer Portal: A .NET 6 web application with a React frontend, deployed from GitHub. Experiences traffic surges during product launches.
• Internal APIs: Containerized microservices providing data to the portal and mobile apps. Need to scale quickly based on queue messages.
• Deployment automation: All infrastructure must be defined as code and deployed from CI/CD pipelines.

Solution design:

• ERP system: Deploy two VMs across availability zones for 99.99% SLA. Use Premium SSD managed disks for SQL Server, with Azure Backup for recovery. VM sizes can be resized vertically with minimal downtime via redeploy (or change size with deallocation during maintenance window).
• Customer Portal: Azure App Service on an S2 plan with auto‑scale rules (add instances when CPU > 60%). Configure deployment slots: deploy to staging slot first, validate, then swap to production. Custom domain and TLS managed certificate. VNet integration to access internal APIs securely.
• Internal APIs: Containerized microservices stored in ACR Premium with geo‑replication. Azure Container Apps with KEDA scaling based on Azure Storage Queue length. Scale to zero overnight when no messages.
• Automation: All resources defined in Bicep templates, stored in the same Git repository. GitHub Actions pipeline validates and deploys on commit. Infrastructure is idempotent and can be recreated in a disaster recovery region.

This architecture balances control, cost, and operational simplicity, exactly as AZ‑104 expects you to evaluate.

8. AZ‑104 Exam Thinking

#

Microsoft tests compute skills through scenario‑based questions that require you to select the correct service, configuration, or tool.

ARM / Bicep Questions

#

• Typical pattern: You’re shown a JSON or Bicep snippet with a missing value or a syntax error, and asked what to fill in or what will happen when you deploy.
• Key knowledge: Understand the structure: parameters, variables, resources, outputs. Know that dependsOn ensures ordering. Parameters can have allowedValues, defaultValue, and type.
• Exam trap: Confusing Bicep’s @allowed decorator with ARM’s allowedValues. They are syntactically different but the logic is the same.

VM Questions

#

• High availability: “Which option provides protection against a datacenter outage?” → Availability Zones, not Availability Sets.
• Moving a VM: “You need to move a VM to another subscription.” Answer: use Azure Resource Mover, or recreate from snapshot if moving to a different region.
• Encryption: “You need to ensure data is encrypted on the VM host before it reaches Azure Storage.” → Encryption at host.

Container Questions

#

• Image storage: “Where do you store container images so they can be deployed to AKS and ACI?” → Azure Container Registry.
• Service choice: “You need to run a containerized task once per hour, and you want to pay only for execution time.” → ACI with restart policy Never, or an Azure Function if code is suitable. ACI fits if it’s a container image.

App Service Questions

#

• Scaling: “You need to automatically increase instances when the number of HTTP requests exceeds 1000/sec.” → Enable auto‑scale with a metric rule.
• Deployment: “You want zero downtime deployment.” → Use deployment slots and swap.
• TLS: “You must enforce TLS 1.2 minimum.” → Configure min TLS version in the App Service settings.

General reasoning method:

1. Identify the workload’s key requirement (OS control, scaling, cost, isolation, managed platform).
2. Eliminate services that don’t provide that feature (e.g., ACI can’t auto‑scale; VMSS isn’t suitable for a simple web app).
3. Select the simplest solution that meets all constraints.

9. Practice Scenarios

#

Scenario 1 – ARM Template

#

You have an ARM template that deploys a storage account and a VM. The VM must be created only after the storage account exists.

What should you add to the template’s VM resource definition?

A. dependsOn: [ ] containing the storage account’s resource ID. B. A condition that checks the storage account’s provisioning state. C. A copy loop with the storage account’s name. D. An output that references the storage account.

Correct answer: A
Explanation: dependsOn ensures the storage account is deployed first. The VM resource references the storage account’s symbolic name (in Bicep) or resource ID (in ARM).
Architecture reasoning: Explicit dependencies prevent race conditions and are essential in IaC for correct ordering.
Related services: ARM Templates, Azure Resource Manager.

Scenario 2 – VM Availability

#

You deploy two VMs running the same application. You need to achieve an SLA of 99.95% for connectivity to these VMs.

What should you do?

A. Place both VMs in the same availability set. B. Place the VMs in separate availability zones. C. Deploy both VMs in the same resource group. D. Configure a load balancer in front of a single VM.

Correct answer: A (Availability Set) is sufficient for 99.95%. Availability zones would give 99.99% but are not required to meet the 99.95% SLA. The question asks what you should do to achieve that SLA; placing them in an availability set is the minimum requirement.
Explanation: A single VM has 99.9% SLA. An availability set with two or more VMs raises it to 99.95%. Zones provide 99.99% but are a higher bar; either would work, but the exam often expects the most cost‑effective solution that meets the requirement. Availability set is simpler and cheaper.
Architecture reasoning: Match availability design to business SLA, not over‑engineering.
Related services: Virtual Machines, Availability Sets, SLA.

Scenario 3 – Container Choice

#

You need to run a containerized background job that processes files from a storage queue. It runs unpredictably, sometimes many instances needed, sometimes none for hours. You want to minimize cost and management.

Which compute solution should you choose?

A. Azure Virtual Machine Scale Set with custom scaling scripts. B. Azure Kubernetes Service. C. Azure Container Apps with KEDA scaling. D. Azure Container Instances deployed manually when needed.

Correct answer: C
Explanation: Container Apps provides serverless containers that scale based on KEDA triggers (like queue length), including scale to zero, which minimizes cost and management. VMSS would require always‑on VMs and custom scaling logic. ACI would require manual deployment. AKS adds unnecessary orchestration overhead.
Architecture reasoning: For event‑driven container workloads, serverless containers are the optimal balance of responsiveness and cost.
Related services: Azure Container Apps, Azure Container Instances, KEDA.

Scenario 4 – App Service Deployment

#

Your web app is running in production. You need to deploy a new version with zero downtime and the ability to instantly roll back if issues are detected.

What should you configure?

A. Deployment slots with swap. B. A second App Service Plan. C. A staging environment in another region. D. Auto‑scale rules.

Correct answer: A
Explanation: Deployment slots allow you to deploy to a staging slot, warm it up, then swap with production. Rollback is another swap.
Architecture reasoning: Slots are the standard pattern for blue‑green deployments on App Service, enabling safe, instantaneous promotion and rollback.
Related services: App Service, Deployment Slots.

Scenario 5 – VMSS Auto‑scale

#

Your VM Scale Set currently has 3 instances. You configure an auto‑scale rule to increase instances by 1 when CPU exceeds 75% for 10 minutes, and decrease by 1 when CPU drops below 25% for 10 minutes. CPU spikes to 80% for 12 minutes, then drops to 20% for 15 minutes.

How many instances will the Scale Set have after the scale‑in operation completes?

A. 2 B. 3 C. 4 D. 5

Correct answer: B (3)
Explanation: The spike triggers a scale‑out to 4. Then the drop triggers a scale‑in, reducing the count by 1, back to 3. (Assuming no other activity.)
Architecture reasoning: Auto‑scale rules are cumulative and can cause flapping if thresholds are too close. Proper design includes a cooldown period to prevent oscillations.
Related services: VM Scale Sets, auto‑scale.

10. Common Exam Mistakes

#

• Confusing Availability Sets and Availability Zones: Sets protect against rack/switch failures; zones protect against entire datacenter failures. If the scenario mentions “datacenter outage,” the answer is zones.
• Choosing VMs when App Service or Container Apps would suffice: The exam rewards managed services where they reduce administrative overhead. If the app can run on a platform service, that’s often the right answer.
• Confusing Container Apps and Container Instances: ACI is for simple, single‑instance containers without auto‑scale. Container Apps is for microservices with auto‑scale and revisions.
• Ignoring scaling requirements: If a scenario describes variable traffic, look for auto‑scale in the answer. Manual scaling is rarely the correct choice for such scenarios.
• Misunderstanding VMSS behavior: Scale sets can automatically reimage VMs to apply updates. Over‑allocation during scaling may cause brief cost spikes.
• Treating ARM and Bicep as different deployment engines: They both deploy through Azure Resource Manager. Bicep is just a transpiled language. The same limitations apply.
• Forgetting that App Service backups require a Standard plan or higher. A common trap question: you’re on a Free or Shared tier and need to configure backup; you must scale up first.
• Assuming VMs can be moved between regions without effort: Moving a VM to another region involves Azure Resource Mover, or backup/restore, which can be time‑consuming. The exam may test this as a constraint.

11. Skill 3 Learning Checklist

#

Must Know (exam‑critical)

#

• Interpret and modify an ARM template or Bicep file (parameters, dependencies, resources)
• Deploy resources using ARM template or Bicep (portal, CLI, PowerShell)
• Export a resource group deployment as an ARM template
• Convert an ARM template to Bicep using az bicep decompile
• Create a VM from the portal/CLI, including selecting OS, size, disks, networking
• Configure encryption at host vs. Azure Disk Encryption
• Move a VM to another resource group, subscription, or region (Azure Resource Mover)
• Change VM size (resize) and understand downtime implications
• Manage managed disks: create, attach, detach, snapshot, expand
• Deploy VMs to an availability set and availability zones
• Create and configure a VM Scale Set with auto‑scale rules
• Create an Azure Container Registry and push/pull images
• Provision an Azure Container Instance (CPU, memory, port)
• Provision an Azure Container App with scaling and revisions
• Create an App Service Plan and understand scaling tiers
• Configure App Service auto‑scale rules
• Configure custom domains and TLS/SSL bindings
• Configure App Service backup (requirements, storage account)
• Configure deployment slots and perform a swap

Should Know (strong working knowledge)

#

• Understand VMSS rolling upgrade policies and maximum surge
• Know when to use Azure Dedicated Host (compliance, licensing)
• Use proximity placement groups for low‑latency workloads
• Configure container app ingress and Dapr integration
• Understand App Service networking: VNet integration vs. private endpoint
• Use ACR Tasks to build images
• Know how to run a container as a background task in ACI (restart policy)

Nice to Know (architecture context)

#

• Understand VM burstable SKUs (B‑series) for cost optimization
• Know the difference between App Service Environment (ASE) and multi‑tenant App Service
• Familiarity with Azure Functions deployment in an App Service Plan (dedicated)
• Understand how to use Azure Compute Gallery (shared VM images) to standardize VM deployments across the enterprise

12. What’s Next

#

Compute resources don’t exist in isolation. They need networks to communicate, be secured, and be reachable. In AZ‑104 Skill 4: Implement and Manage Virtual Networking, you’ll configure VNets, subnets, load balancers, and hybrid connectivity that bring compute workloads to life.

AZ‑104 Skill 4: Implement and Manage Virtual Networking →

Related Architecture and Domain Content

#

• Compute domain deep‑dive: /azure/domains/compute
• Networking domain overview: /azure/domains/networking
• Automation domain (IaC): /azure/domains/devops
• Compute architecture design: /azure/architecture/compute-architecture
• VM‑based architecture patterns: /azure/architecture/vm-based-architecture
• Container architecture: /azure/architecture/container-architecture
• Serverless architecture: /azure/architecture/serverless-architecture
• High availability architecture: /azure/architecture/high-availability-architecture
• Virtual Machines service guide: /services/virtual-machines
• VM Scale Sets reference: /services/virtual-machine-scale-sets
• App Service deep‑dive: /services/app-service
• Container Apps guide: /services/container-apps
• Container Instances reference: /services/container-instances
• Container Registry service: /services/container-registry