AZ-104 Compute Choices: VMs, App Service and Containers
AZ-104 Compute Choices: VMs, App Service and Containers
A development team wants to move a customer-facing API and a scheduled processing job into Azure. One engineer proposes a virtual machine, another suggests App Service, and a third wants to run containers. All three can execute application code, but they leave administrators responsible for very different scaling, security, deployment and recovery work.
The AZ-104 exam measures practical administration of virtual machines, Virtual Machine Scale Sets, Azure Container Registry, Container Instances, Container Apps and App Service. It also examines ARM/Bicep deployment and the controls around compute. The right answer is rarely the newest service. It is the one that satisfies the workload’s requirements without imposing unnecessary operational responsibilities.
Choose a service by workload behavior and ownership
Start with five questions: Does the team need control of the operating system? Is the workload an always-on web service, a batch task or an event-driven process? Does it need persistent local state? How does it scale? Which parts of patching, availability and deployment must the team manage? The answers often eliminate several compute options before any feature comparison becomes necessary.
A virtual machine gives substantial control over the guest operating system, software stack and network configuration. That flexibility also makes the team responsible for more guest-level administration, patching, health monitoring and backup design. App Service is a managed hosting platform optimized for web apps and APIs; the team primarily manages application configuration, deployment, scaling and connectivity rather than routine guest OS maintenance.
Container Instances offers direct on-demand container execution with fewer orchestration features than a full container-app platform. Container Apps adds managed revisions, ingress, scaling and service-to-service patterns for containerized apps and jobs. A Kubernetes cluster may be justified for specific orchestration requirements, but it is not a mandatory step for running every container.
Virtual machines are still appropriate when the OS matters
Choose a VM when an application requires special guest-level components, a supported legacy service, operating-system configuration or administration not offered by the managed platforms. Pick a size that meets CPU, memory, temporary storage and disk throughput needs. Distinguish the OS disk, data disks and temporary storage before diagnosing persistent data loss. A successful VM deployment is not the same as a recoverable application.
For an internal accounting service running on two VMs, the administrator might place instances across supported availability zones, attach managed data disks, set network controls and configure monitoring before making the service live. A scale set can simplify management of many similar VM instances, particularly when the workload can tolerate scaling and instance replacement. An availability set instead helps distribute VMs across fault and update domains within its supported placement model; it does not automatically add or remove capacity.
The existing VM scale sets and availability sets comparison is useful when the design hinges on fault isolation or instance scaling. In an AZ-104 scenario, always ask whether the goal is placement resilience, horizontal scaling, both or neither.
App Service plans determine capacity; apps determine deployed behavior
An App Service app runs on the capacity provided by its App Service plan. The plan’s pricing tier, instance size and scale determine available capabilities and cost characteristics. Scaling up selects a larger capacity tier or size; scaling out increases instances where supported. An administrator investigating slow requests should examine resource utilization and app performance before changing the plan indiscriminately.
An API that serves predictable business-hour traffic may fit App Service well. The team can deploy application code or a supported container image, configure environment settings, establish a custom domain, manage certificates and TLS, and add health monitoring. App Service avoids much guest OS management, but configuration errors remain the team’s responsibility. A wrong connection string, missing managed identity role or restricted outbound network path can still make the app fail.
Do not confuse an App Service plan with an individual app: multiple apps sharing a plan also share its compute capacity, which can create noisy-neighbor effects. Capacity changes should be evaluated against all applications on that plan, not only the one that raised the performance ticket.
Deployment slots separate release risk from infrastructure changes
Deployment slots let eligible App Service plans maintain a staging version of an app alongside production. A team can deploy new code to a staging slot, warm it up, test health checks and then swap it toward production. Slots can reduce release disruption, but they are not an automatic substitute for application testing or rollback planning. Slots are available only on supported App Service plan tiers.
Settings that follow the slot and settings that swap with the application must be understood before release. Suppose staging points to a test database and production to live customer records. If connection settings are not marked or handled appropriately, swapping can expose the wrong environment. Document which configuration settings are slot-specific, verify identity and network paths, and run a smoke test after the swap.
A deployment that succeeds while the app cannot authenticate to storage is still a failed release. Confirm the service’s actual downstream transactions before closing the change. This is why a good App Service plan includes both deployment workflow and observability.
Container Registry stores images; a runtime executes them
Azure Container Registry (ACR) is a private image registry. It is not the service that runs application processes. The workload needs a runtime such as Container Instances, Container Apps or a suitable App Service configuration to pull an image and execute it. A common operational failure is giving a deployment identity permission to create the runtime but not permission to read the image from ACR.
For an internal task that converts uploaded files in a short, controlled batch, a container instance or managed container job may be suitable. Record its CPU and memory requirements, image source, environment configuration, expected runtime and logging destination. Prefer a managed identity with the necessary registry pull capability over embedding a registry administrator password in an image or deployment script.
The Azure Container Apps deployment guide addresses wider image and runtime workflows. The AZ-104 distinction is to keep image storage, image authorization, application ingress, container execution and scaling as separate decisions.
Container Apps adds managed revisions and workload-driven scaling
Container Apps is a useful option when a team wants managed microservices, APIs or jobs without owning a full Kubernetes control plane. Its managed environment supplies shared infrastructure for those apps, while each app has its own configuration, revision and scaling behavior. Event-driven scaling can be valuable, but the triggers and minimum/maximum replica settings should reflect actual workload behavior and acceptable cold-start or processing delays.
Imagine a background invoice processor that receives intermittent messages. Running a VM around the clock may be reasonable under some constraints, but a containerized job or scaled application might make better use of capacity. Compare startup time, concurrency, network requirements, observability and fault recovery. If the task needs local state that disappears with an instance, move durable records to an appropriate external service.
Container Apps and Container Instances should not be treated as interchangeable just because both run containers. The former includes higher-level application primitives and managed scaling; the latter is a more direct container execution building block. Choose the operational model the team can support rather than the service with the most fashionable name.
Networking and identity failures often masquerade as compute failures
A healthy VM can serve no traffic because an NSG blocks the required port, a user-defined route sends packets to an unavailable appliance or the load balancer’s health probe does not match the service. An App Service application can start but be unable to reach a private storage endpoint because of configuration or DNS. A container runtime can fail repeatedly to pull its image because it lacks registry access. Each incident may be labeled “the application is down,” but the owning control is different.
Map a request through ingress, the running instance, identity and dependencies. If the container is not starting, inspect its image-pull and runtime logs. If the web app starts but downstream calls time out, inspect name resolution and networking. If a VM responds locally but not through a load balancer, investigate probe behavior and filtering. Avoid simply increasing compute resources when there is no evidence of saturation.
Workload identity follows a similar boundary. An app’s managed identity needs only the permissions required on storage, Key Vault or other dependencies. A virtual machine’s local administrator account does not grant Azure resource permissions merely because it can sign in to the guest.
Use the same scenario to compare three options
Take a small claims-processing service with a public API, a background document job and a private data store. In a VM design, the administrator must configure the guest, application stack, load balancing, patching and backups. In App Service, the public API benefits from managed hosting, deployment slots and scale settings, while the background job may run separately. In a container design, the API and processing job can use images and a managed container runtime with independent scaling behavior.
Write down which model needs the fewest operational exceptions. If the application must install an unusual operating-system driver, that requirement may justify a VM despite the maintenance burden. If it is a conventional web API with stable dependencies, App Service may offer a cleaner boundary. If it is already containerized and needs managed event-driven processing, Container Apps deserves consideration. None is inherently correct without the application’s actual constraints.
Then deliberately fail one dependency: remove a data role, block an outbound endpoint or publish an inaccessible image version. Examine how each hosting model exposes the failure and how the team would restore service. This exercise produces more useful AZ-104 preparation than memorizing three comparison tables.
Make capacity, monitoring and recovery decisions before go-live
Every hosting choice needs an availability and monitoring plan. For VMs, define patch windows, disk performance checks, backup policies and placement requirements. For App Service, inspect instance utilization, app health, deployment behavior and dependent services. For containers, capture runtime errors, failed image pulls, scale events and the distinction between persistent data and disposable instances.
Cost is part of the selection, but a low advertised base price does not describe the whole workload. A service that scales to zero may save idle compute, but storage, networking, logging and image registry costs remain. A shared App Service plan may be efficient for several related apps, while a dedicated VM can be sensible for a predictable specialized workload. Compare total operational effort, failure modes and resource consumption, not only monthly instance prices.
An Azure administrator should be able to justify the chosen service, explain which layers the platform manages, name the first diagnostics to inspect when it fails, and demonstrate a recovery test. That combination is the practical meaning of AZ-104 compute competence.
- Category: Certifications Microsoft
- Tags: AZ-104
