Mastering Azure compute for Microsoft AZ-104 Azure Administrator: What Candidates Need to Understand

 

The AZ-104 compute domain is not a virtual-machine chapter with a few extra services attached. In the current April 17, 2026 outline, compute covers declarative deployment with ARM templates and Bicep, virtual machines, managed disks, availability options, Virtual Machine Scale Sets, Azure Container Registry, Azure Container Instances, Azure Container Apps, and Azure App Service. Those services represent different operational models, and the exam expects an administrator to understand the consequences of choosing one over another.

A strong compute decision starts with the workload boundary. Does the team need operating-system control? Is the application already packaged as a container? Is horizontal scale a core requirement? Is it a web workload that benefits from a managed platform? Does the environment need repeatable deployment from code? Which parts of the stack will the administrator own after deployment? Answering those questions first keeps you from choosing a service simply because its name appears in the prompt.

The current blueprint gives compute 20–25 percent of AZ-104, so it deserves both conceptual depth and hands-on repetition. Use the AZ-104 labs article to turn the concepts here into hands-on work. The goal in this deep dive is to build a decision model that connects deployment, availability, networking, identity, monitoring, and recovery rather than treating each compute feature as an isolated fact.

Use a compute decision model instead of a product checklist

Compute questions are easier when you compare operating models rather than service names.

• Virtual machines fit workloads that need operating-system control, custom agents, or traditional server administration. The administrator still owns the guest OS, disks, networking, monitoring, and recovery decisions.
• Virtual Machine Scale Sets fit groups of similar VM instances that need coordinated scaling. You still need to understand the VM model, health, network design, scaling behavior, and update implications.
• Azure Container Instances can run packaged workloads with relatively little infrastructure management. The important questions are image source, container configuration, network exposure, and resource sizing.
• Azure Container Apps adds an application-oriented container platform with ingress and scaling capabilities. Study how identity, networking, revision or deployment behavior, and observability differ from a single container instance.
• Azure App Service is a managed web-application platform. Administrators still manage the App Service plan, scaling, TLS, custom domains, networking, deployment slots, backup, and application configuration.
• ARM templates and Bicep address repeatable desired-state deployment. They are not another runtime model; they are a way to define and deploy Azure resources consistently.

The exam may combine any of those choices with requirements about private networking, managed identity, availability, cost, or recovery. A correct compute service with the wrong surrounding controls is still an incomplete design. Practice explaining both what Azure manages and what remains your responsibility.

Declarative deployment with ARM and Bicep

ARM templates and Bicep are about desired state

The current AZ-104 objectives include interpreting, modifying, and deploying ARM templates or Bicep files, and exporting or converting deployments. The key idea is declarative infrastructure: you describe the resources and properties you want, and Azure Resource Manager orchestrates deployment.

Candidates sometimes avoid this objective because they assume it requires software-development depth. For AZ-104, focus on reading resource definitions. Identify parameters, resource types, names, locations, properties, dependencies, and outputs. Ask what Azure state the file is trying to create.

Take a simple Bicep file that defines a virtual network or VM. Change one parameter or property and predict the effect. Add a tag. Change a SKU. Move a value into a parameter. The purpose is to become comfortable with structure and resource relationships.

Parameters versus hard-coded values

Parameters make deployments reusable. If a template contains a hard-coded region or VM size, changing environments can require editing the file. A parameter can allow the same deployment logic to be used with different values.

When interpreting a template question, distinguish a parameter definition from the value supplied during deployment. Understand that a parameter can have allowed values, defaults, or other metadata depending on the format. You do not need to memorize every syntax option, but you should recognize why parameterization matters.

Dependencies matter in declarative deployment

Resources often depend on other resources. A network interface may depend on a subnet. A VM may depend on a network interface and disks. A private endpoint may depend on a target service. Declarative tools can infer or explicitly define some dependencies.

When a deployment fails, ask whether the referenced resource exists and whether the dependency is expressed correctly. This is another place where infrastructure-as-code study reinforces the mental model of Azure relationships.

Virtual machines as an operational system

Virtual machines remain a core administrator skill

Virtual machines are familiar, but AZ-104 questions rarely stop at creation. You need to understand sizing, disks, availability, encryption at host, moves, scale options, and the resources surrounding a VM.

A VM is not one object. It relies on a network interface, virtual network and subnet, disks, identity or access controls, monitoring, and often backup. If you can draw those dependencies, troubleshooting becomes easier.

VM size is a resource decision

VM sizes differ in CPU, memory, disk performance, networking capability, and cost. The exam is more likely to test whether you can change or select an appropriate size under constraints than whether you can memorize a catalog.

Practice resizing a VM in a lab. Observe that availability and supported sizes can depend on region, hardware, or other constraints. If a question says the workload needs more memory but should remain a VM, resizing may be a logical administrative action.

Managed disks and disk roles

Understand the difference among the OS disk, data disks, and temporary storage characteristics where relevant. Practice attaching a data disk and observing how the Azure resource relates to what the operating system sees.

When moving or resizing VMs, remember that disks are part of the dependency picture. A question about a VM move may include resource types that have their own movement constraints.

Encryption at host is a compute security setting

The current objectives include configuring encryption at host for Azure VMs. Study it as part of layered security. Disk and storage encryption controls are distinct from network security, access control, and application encryption.

Do not respond to every “secure the VM” requirement with NSGs. Identify whether the requirement concerns data at rest, host-level handling, management access, identity, or network exposure.

Availability sets and availability zones address infrastructure failure

Availability design is about reducing the impact of infrastructure failure and maintenance. Availability zones are physically separate locations within a supported Azure region. Availability sets distribute VMs across fault and update domains within the relevant infrastructure model.

For scenario questions, focus on the failure boundary. If the requirement explicitly says the workload should tolerate a datacenter-level or zone failure within a region, availability zones are relevant. If the scenario uses multiple VMs without zones and emphasizes separation across infrastructure fault or update domains, an availability set may be relevant.

Avoid treating availability as the same thing as backup. Availability aims to keep service running through certain failures. Backup aims to recover data or workloads after loss. A highly available VM design can still need backup.

Moving a VM tests your understanding of resource boundaries

The current objectives include moving a VM to another resource group, subscription, or region. These are not identical operations. Resource-group and subscription moves involve management boundaries and resource dependencies. Regional moves involve relocation and may use different processes or tooling.

For preparation, learn to check dependencies before moving. A VM can be connected to resources that may not move in the same way. RBAC, policies, resource IDs, and automation references may also be affected by scope changes.

A good lab is to move a supported VM-related resource between resource groups in a disposable environment and then verify that networking, permissions, and monitoring still behave as expected.

Scale sets and repeatable VM fleets

Virtual Machine Scale Sets manage groups of VM instances

Scale sets allow administrators to deploy and manage multiple VM instances with a common model and scaling behavior. They are useful when a workload needs multiple similar compute instances and potentially automatic scaling.

The exam-relevant idea is not every scale-set property. Understand how a scale set differs from manually creating several independent VMs. The instances are managed as a group, often behind load-balancing or application traffic distribution, and can scale based on rules or demand.

Build a simple scenario: a stateless service runs on several identical VM instances and must add instances when load increases. A scale set is more operationally appropriate than manually cloning VMs whenever traffic rises.

Container compute choices

Azure Container Registry stores container images

Container Registry is the image repository component in the current compute domain. It is not itself the runtime where your application executes. This distinction matters.

A common architecture is: build or obtain a container image, store it in a registry, then deploy that image to a runtime such as Azure Container Instances or Azure Container Apps. Authorization determines which identities can push or pull images.

When a scenario says “store private container images,” think registry. When it says “run this container,” think runtime. The registry and runtime can be related but are different resources.

Azure Container Instances provides simple container execution

Azure Container Instances can run containers without requiring you to manage VMs directly. It is useful for relatively straightforward container workloads where you want rapid deployment and less infrastructure management.

For AZ-104, understand provisioning, basic networking and resource configuration, and sizing or scaling considerations at the administrator level. Do not confuse it with a complete container-orchestration platform.

A practice scenario might require a short-lived processing container that does not justify a persistent VM. Another might require a quick test of an image stored in Container Registry. The operational simplicity of Container Instances can make it a good fit.

Azure Container Apps adds application-oriented container capabilities

Azure Container Apps is another managed container runtime included in the current AZ-104 blueprint. It provides a more application-oriented environment with scaling and other platform features while abstracting the underlying infrastructure.

The important exam distinction is that Azure administrators can provision and manage containerized workloads without necessarily operating a VM fleet. Compare the workload requirement with Container Instances and App Service rather than trying to memorize a marketing feature list.

If a scenario emphasizes a containerized application with scaling and managed platform behavior, Container Apps may be more appropriate than a single manually managed container instance.

App Service operations

App Service is a managed platform for web applications

Azure App Service is a major compute option for hosting web applications and APIs while Azure manages much of the underlying infrastructure. The current objectives include App Service plans, scaling, TLS and certificates, custom DNS names, backups, networking settings, and deployment slots.

Think of the App Service plan as the compute capacity and hosting context, while the App Service represents the application. Several apps can share a plan depending on design and requirements.

App Service scaling

Scaling can mean changing the capability of the plan or changing the number of instances, depending on the scenario. Read the requirement carefully. If the workload needs more powerful instances, that is different from needing more instances to handle additional traffic.

Custom domains and TLS

Mapping a custom DNS name and configuring TLS are related but separate steps. DNS must direct the name appropriately, and the application must have a suitable certificate and TLS configuration. A scenario that says the custom hostname resolves but HTTPS fails points toward a different layer than a scenario where the name does not resolve at all.

App Service backup

App Service backup protects application-related state according to supported configurations. Do not confuse an application backup with availability or deployment slots. A deployment slot can reduce deployment risk or support staging, but it is not a backup replacement.

Deployment slots

Deployment slots allow you to deploy and validate a version in a separate slot before swapping traffic. They are useful for reducing risk during application releases.

For AZ-104, understand the operational purpose: separate environments within the App Service deployment model, controlled swaps, and configuration considerations. Avoid assuming every setting automatically moves or behaves identically during a swap.

Compute depends on networking, identity, monitoring, and recovery

Compute networking is never optional

Every compute model has networking implications. A VM has a network interface and subnet. App Service has networking settings and can integrate with virtual networks in supported ways. Containers also have network configuration. Load balancing, DNS, NSGs, private endpoints, public IPs, and routing can all affect compute workloads.

When a compute question includes a connectivity symptom, switch mental models from “compute service” to “end-to-end path.” Check the source, destination, DNS resolution, route, security controls, service networking, and application listener.

The networking guide is worth reviewing alongside compute because many failures cross both domains.

Identity should be part of compute design

Compute workloads need identities to access other Azure resources. Users and administrators need roles to manage compute. Managed identities can give supported Azure resources an identity without embedding long-lived credentials in application code.

When a VM or App Service must access storage or another service, ask whether identity-based access can replace a secret. Then assign the appropriate role at the narrowest practical scope.

This is another reason to connect the Entra governance with compute study rather than treating identity as a completed chapter.

Monitor compute as part of every lab

A compute resource that exists but cannot be observed is difficult to operate. Use Azure Monitor metrics, logs, alerts, and Insights where appropriate. For VMs, monitor availability and performance. For App Service or containers, identify signals that show application or platform health.

Create an alert for a meaningful condition and attach an action group. Trigger or simulate the condition if possible. The objective is to connect deployment with operations.

When troubleshooting performance, distinguish resource saturation from connectivity failure, application errors, and platform configuration. Monitoring data helps identify which layer deserves investigation.

Back up and recover compute workloads appropriately

Virtual machines and application workloads can have backup or recovery requirements. Avoid assuming availability zones or scale sets eliminate the need for backup. Availability protects service continuity against certain failures; backup protects recovery from data loss or unwanted change.

For VMs, understand how Azure Backup and recovery vault concepts fit the current monitoring and maintenance domain. For App Service, understand the service-specific backup objective. For disaster recovery, Azure Site Recovery can address replicated workload failover scenarios where supported.

Ask the requirement: keep the service online through host or zone failure, recover a deleted or corrupted state, or fail over to another region? Those are different problems.

Analyze AZ-104 storage scenarios

Scenario 1: web application without OS administration

Requirement: a team needs to host a standard web application, use a custom domain and HTTPS, scale as traffic changes, and deploy new releases with reduced risk. The team does not want to manage operating systems.

App Service is a natural candidate. The operational requirements line up with a managed web platform, App Service plan capacity, custom domain and TLS configuration, scaling, and deployment slots. If the application also needs private access to a backend service, networking settings become part of the design.

The key is that a VM could technically host the application, but the requirement explicitly values reduced operating-system management. The best answer should reflect that constraint.

Scenario 2: identical VM workers that need to scale

Requirement: a processing service runs on identical VM instances and needs to increase or decrease instance count according to demand.

A Virtual Machine Scale Set fits the pattern because the instances share a model and are managed as a group. You would also consider load distribution or work-queue design, health, monitoring, and network configuration.

Manually creating independent VMs may work at small scale but does not satisfy the operational scaling requirement as cleanly.

Scenario 3: short-lived container job

Requirement: an image already exists in a private registry and must run as a short-lived containerized task without maintaining VMs.

The design should separate the registry from the runtime. Container Registry stores the image. Azure Container Instances may be suitable for a simple, short-running container workload. Authentication between the runtime and registry is part of the design.

If the requirement changes to a long-running application with more advanced scaling or managed application features, Container Apps may become more appropriate.

Scenario 4: repeatable environment deployment

Requirement: a team must deploy the same resource pattern into development and test environments with different names and sizes.

ARM templates or Bicep provide declarative, parameterized deployment. The file should express common structure, while parameters vary environment-specific values.

The administrator should be able to read the file, identify parameters and resources, modify a value, deploy it, and validate the resulting Azure state. This is exactly the kind of practical infrastructure-as-code literacy the AZ-104 objective expects.

Scenario 5: VM availability requirement

Requirement: two VMs supporting an application should be designed to reduce the impact of a datacenter-level failure inside the Azure region.

Availability zones are the relevant failure-domain concept in a supported region because the requirement explicitly references physically separate datacenter locations. You would deploy instances across zones and then consider how traffic is distributed between them.

Avoid answering with backup alone. Backup does not keep the application serving traffic during the failure.

Scenario 6: application deployment goes wrong

Requirement: a new version was deployed to an App Service and immediately causes errors. The team needs a release process that allows validation before production traffic moves.

Deployment slots provide a strong operational pattern. Deploy to a staging slot, validate configuration and behavior, then perform a controlled swap when ready. If a problem appears after the swap, the slot model can support a safer rollback pattern than overwriting production directly.

The exam may not ask for a full DevOps strategy, but it expects you to understand the administrative role of slots.

A practical compute study sequence

Common compute preparation mistakes

Watch for these patterns:

• memorizing VM creation steps but ignoring the surrounding resources;
• assuming availability and backup solve the same problem;
• confusing Container Registry with a container runtime;
• treating Container Instances and Container Apps as identical;
• ignoring App Service plan capacity when thinking about app scaling;
• memorizing Bicep syntax without understanding resource state;
• failing to include networking and identity in compute design;
• granting workload access with secrets when managed identity could fit;
• ignoring monitoring until the end of preparation;
• choosing a VM simply because it is the most familiar compute model.

The AZ-104 mistakes provides a broader review of these study patterns.

Phase 1: virtual machine foundation

Create a VM, inspect its network interface and disks, resize it, add a data disk, review availability choices, and configure monitoring. If possible, move a supported resource between resource groups and observe scope effects.

Phase 2: availability and scale

Deploy two VMs using an availability design or study the configuration carefully. Build a basic scale-set scenario and explain how group management differs from independent VMs.

Phase 3: infrastructure as code

Read a small Bicep file, deploy it, change a parameter, modify a resource property, and redeploy. Export or review a deployment representation so you become comfortable connecting portal-created resources with declarative definitions.

Phase 4: containers

Create or study an Azure Container Registry, push or identify an image, deploy to Container Instances, and compare the operational model with Container Apps.

Phase 5: App Service

Create a plan and app, configure scale settings, review networking, add a custom-domain or TLS exercise if practical, configure backup, and use a deployment slot.

Phase 6: integration

Connect compute to storage, networking, RBAC, monitoring, and backup. Intentionally break one dependency and troubleshoot it from symptoms.

Capstone deployment and troubleshooting

Capstone lab: deploy, secure, monitor, and recover a small application

A strong compute capstone can combine most of the domain without becoming an enterprise architecture project. Start with a simple application requirement. For example: a small internal web application needs a managed hosting platform, a custom name, encrypted HTTPS access, private access to a storage dependency, monitoring, and a release process that allows validation before production traffic is switched.

Choose App Service and create an App Service plan. Deploy a small application or placeholder. Configure the custom-domain concept and TLS. Add a deployment slot and use it to stage a new version. Integrate networking with the storage design where practical. Give the application an identity and authorize that identity to the storage resource at the narrowest suitable scope. Add a metric alert and inspect logs. Configure a backup where supported by the scenario.

Then repeat the architecture exercise using a VM-based deployment. You do not need to rebuild everything, but describe what new responsibilities appear: operating-system patching, VM sizing, disk management, host-level configuration, availability design, secure administration, and potentially load balancing. The comparison teaches why a managed platform can reduce administration even though both models can host an application.

Finally, create a small Bicep definition for one portion of the environment. The capstone now connects compute model, identity, networking, storage, monitoring, release management, and infrastructure as code.

Capstone troubleshooting: isolate the failing layer

Imagine users report that an application hosted on Azure compute cannot reach a storage dependency. A weak troubleshooting response is to change an NSG, restart the application, add a role, and open the storage firewall all at once. A stronger response identifies the layers and tests them in order.

Confirm the application process is running. Confirm the target hostname resolves to the intended address. Confirm the route and network controls permit the connection. Confirm the storage account accepts the network path. Confirm the workload identity has the required data permission. Review application or platform logs for authorization or connection errors.

Now change the scenario: users can reach the application, but a deployment slot swap results in unexpected configuration. The networking path may be irrelevant. Investigate slot settings and application configuration instead. Another scenario: a VM has high CPU and slow response. Monitoring and VM size may matter more than network access.

This troubleshooting discipline is valuable because “compute problem” is often only the visible symptom. AZ-104 preparation should train you to identify whether the root cause actually belongs to compute, networking, storage, identity, or monitoring.

Readiness through trade-off questions

Use a compute decision tree during practice

When a scenario offers several compute services, use a short decision tree before looking at the answer choices. First ask whether the workload needs operating-system control. If yes, virtual machines or a VM-based model may be appropriate. If not, ask whether the workload is fundamentally a web app or API that fits a managed application platform. If yes, App Service may be A well-prepared candidate. If the application is packaged as a container, ask whether it is a simple container task or a more application-oriented container workload with scaling needs. Then consider Container Instances or Container Apps accordingly.

Next, ask whether the workload needs multiple identical VM instances and coordinated scaling. That points toward a scale set rather than independent VMs. Finally, ask whether the environment must be deployed repeatedly and consistently. That requirement cuts across the service choice and points toward ARM templates or Bicep.

The value of a decision tree is not that every real Azure architecture can be reduced to five questions. It is that exam scenarios often include one or two constraints that eliminate several choices. Training yourself to find those constraints prevents familiar services from biasing the answer.

Avoid memorizing service boundaries too rigidly

Azure services evolve, and managed platforms can overlap in capability. Your goal is not to build a permanent ranking of which service is “best.” Learn the core operational distinctions and then let scenario constraints drive the choice.

For example, App Service and Container Apps can both host application workloads, but the packaging model, scaling experience, platform features, and operational expectations differ. A VM can host almost anything, but that flexibility comes with greater infrastructure responsibility. Container Instances can be ideal for a simple task but may be less suitable for a complex long-running application environment. Scale sets improve VM-fleet management but do not remove the need to operate the guest workload.

When two services appear plausible, restate the business requirement and identify the feature that actually matters: OS control, container packaging, web-platform features, horizontal VM scaling, deployment repeatability, or reduced infrastructure management. This keeps your knowledge adaptable as Azure changes.

Review compute through “what changes if…” questions

A powerful final-review technique is to take one scenario and change a single requirement.

Start with: “A web application should run without OS administration.” Then change it to: “The application requires a custom kernel module.” The compute choice may shift toward a VM. Change it again: “The workload is delivered as a container image and runs for ten minutes every hour.” A container runtime may become more attractive. Change it again: “The workload must run on several identical VMs and scale with demand.” A scale set enters the picture.

Do the same with availability. If the requirement is “recover from accidental data deletion,” compute availability is not the main solution. If the requirement becomes “continue operating through a zone failure,” availability zones and multi-instance design become relevant. If the requirement becomes “recreate the environment consistently in another subscription,” infrastructure as code becomes central.

These variations train you to notice the requirement that changes the answer. That skill is more durable than memorizing one service-to-scenario mapping.

Final compute checklist

Before considering the domain ready, Be ready to:

• interpret and modify a basic ARM template or Bicep file;
• explain why parameters and dependencies matter;
• create and manage VMs, sizes, disks, and host-encryption settings at an administrator level;
• reason about moving VMs and their dependencies;
• distinguish availability sets from availability zones based on failure requirements;
• explain the operational role of Virtual Machine Scale Sets;
• separate Container Registry from container execution;
• compare Container Instances and Container Apps at a practical level;
• explain App Service plans, scaling, TLS, custom names, backup, networking, and deployment slots;
• include networking, identity, monitoring, and recovery in compute scenarios;
• choose a compute model because it satisfies the requirement, not because it is the service you know best.

The AZ-104 exam can help you test these decisions once the concepts are stable. The Microsoft certifications provides broader context if you are planning what to learn after Azure administration.

Azure compute becomes much easier when you stop asking, “Which service do I need to memorize?” and start asking, “What operational model does this workload require?” That question naturally leads to the right comparisons among VMs, scale sets, containers, App Service, and declarative deployment. It also reflects the real work of an Azure administrator: balancing control, availability, repeatability, security, networking, and operations.