Compute Resources

Every service in this domain is a way to host application code, and they line up on one axis Microsoft calls the hosting model: Infrastructure as a Service (IaaS) at the bottom, Platform as a Service (PaaS) at the top, with container services in between. With an Azure Virtual Machine (IaaS) you own and patch the guest operating system while Azure owns only the physical host, so you get the most control and portability but carry the most operational overhead. Azure App Service (PaaS) flips that: Microsoft runs and patches the OS and web server and you deploy only the app, trading control for near-zero infrastructure management. The container services sit between, and the same single trade-off (more control versus less to manage) is the question behind every 'which compute' decision on the exam.

Within the container middle of the spectrum there are three independently provisioned resources, again ordered by management altitude. Azure Container Registry (ACR) is the private store that holds images and runs nothing; Azure Container Instances (ACI) runs a container group as a serverless task with no orchestration, no autoscaling, and per-second billing; Azure Container Apps runs containers as a managed serverless app with built-in HTTP ingress, immutable revisions for traffic-splitting and rollback, and automatic scaling driven by KEDA. They are not competing tiers of one product: the normal flow pushes an image to ACR, then ACI or Container Apps pulls and runs it. The split between the two run services is the same control-versus-management question: ACI for a fixed-size task you start and stop, Container Apps for a service whose instance count must follow load on its own.

Where redundancy and scaling come from tracks the same management altitude. A lone VM is a single point of failure, so on IaaS you arrange resilience yourself by spreading VMs across an availability set (fault and update domains in one datacenter, 99.95% SLA with 2+ VMs) or availability zones (separate datacenters, 99.99% with 2+ zones), and you add elasticity yourself with a Virtual Machine Scale Set that autoscales horizontally. Climb to App Service and the platform owns the instances: you pick a pricing tier and the plan scales out (manually or via autoscale) up to a tier-bound ceiling, and a deployment slot gives zero-downtime releases. Climb to Container Apps and scaling becomes automatic down to zero replicas. The recurring exam cue is horizontal versus vertical: more instances under load is scale-out (a scale set, an App Service plan, or Container Apps replicas), while more power per instance is a resize or scale-up and never autoscale.

Whatever you host (VMs, registries, container apps, or App Service plans) Azure Resource Manager (ARM) is the single engine that receives the request and provisions it, and infrastructure as code is how you drive it repeatably. You declare the desired end state, not a sequence of steps, in one of two functionally equivalent languages: an ARM template in JSON, or a Bicep file that transpiles to that same ARM JSON before deployment. Because the description is declarative, a redeploy is idempotent: ARM compares declared state to actual and changes only what differs. Deployment mode then governs resources already in the group but absent from the template: incremental (the default) leaves them alone, while complete deletes them, so the mode is a safety decision, not a syntax one.