AZ-104 Compute
Deploy & manage Azure compute resources
VM
Azure Virtual Machine (VM)
What it is
An Azure Virtual Machine is an emulated computer running in Microsoft’s datacenter — Infrastructure as a Service (IaaS). You pick an OS image (Windows or Linux), a size (CPU/RAM), one or more disks, networking, and authentication. You get full control of the guest OS, which is the defining trait of IaaS versus PaaS.
Why it exists
Some workloads need a real OS you can install anything on, tune, patch, and manage — existing on-premises apps, custom agents, licensed software. VMs give you that control without buying or racking hardware. You pay per second/hour for what you run.
Key ideas
- Compute model: vCPU + RAM are the unit of compute; pick a size/family from VM sizes.
- Storage: OS disk + optional data disks, typically managed disks. Boot from image or custom/generalized image.
- Networking: every VM has a virtual NIC attached to a virtual network (VNet) subnet; a network interface + public IP + network security group govern traffic.
- Auth: by SSH keys / username+password (Linux), or password / Microsoft Entra auth (Windows). Secrets protected with Azure Key Vault.
- Availability: plan for resilience with availability sets and availability zones.
- Scale: Virtual Machine Scale Sets run many identical VMs behind a load balancer.
- Management extensions: VM extensions (e.g. Custom Script Extension) run setup inside the guest.
How it fits (diagram)
Exam notes
- Before creating a VM, decide: resource group, size, storage (disk type/SKU, ephemeral OS disk option), networking/subnet, and availability options (region/Zones vs availability set vs none).
- VMs incur cost even when stopped (allocated) — deallocate (
az vm deallocate) stops billing while retaining disks; delete removes them. - Creation paths: Portal, Azure CLI, PowerShell, Bicep/ARM templates, Azure Quickstart templates.
- Redeploy a VM (
az vm redeploy) to a new Azure host to recover from host-level issues.
Related
Path MOC · vm-sizes · managed-disks · vm-snapshot · availability-set · availability-zones · virtual-machine-scale-set · azure-vm-extension · azure-cli · bicep
📘 Source: Microsoft Learn — Azure Vm
VM sizes and families
What it is
A VM size is a standard combination of vCPUs, memory, temporary storage, and network bandwidth offered by Azure (e.g. Standard_D2s_v3). Sizes are grouped into families (series) optimized for different workloads — General purpose (D), Compute optimized (F), Memory optimized (E), Storage optimized (L), GPU (N), High performance compute (H), Burstable (B).
Why it exists
Compute demand varies wildly. Size families let you right-size — pay only for the CPU/memory profile your workload actually needs, and scale up (change size) or out (scale sets) as demand changes.
Key ideas
- Name anatomy:
<Family>-<vCPU>-<series>-<generation>e.g.D2s v3= D-family, 2 vCPUs, Standard, v3 generation. - B-series (burstable): baseline credit accrual, bursts on demand — cheap for dev/test and low-steady-load workloads.
- Ephemeral vs managed storage couples with disk choices and the temporary disk (D:/tmp on Windows).
The three pieces (memorize!)
- vCPU count → compute capacity.
- Memory (GiB) → concurrent workloads / in-memory data.
- Temporary disk size + max network bandwidth → local scratch space and possible throughput.
How it fits (diagram)
Exam notes
- Resizing a VM requires deallocating it first (the new size may not fit the current host).
- vCPU quotas are per-family and per-region — you may need a quota-increase request before provisioning many VMs.
- The temporary disk is NOT persisted; a resize/restart can wipe it. Put persistent data on data disks.
- Introducing a size too small for the workload → poor performance, not an error; resize up with deallocate → resize → start.
- AZ-104 care about choosing an appropriate size and knowing family purpose, not memorizing every SKU.
Related
Path MOC · azure-vm · virtual-machine-scale-set · managed-disks
📘 Source: Microsoft Learn — Vm Sizes
Azure managed disks
What it is
A managed disk is a block-level storage volume Azure creates and manages for you behind a VM — the OS disk and data disks. Microsoft handles the underlying storage accounts; you specify disk type, size, and redundancy. Unmanaged disks (storage-account backed, VM-scoped 20k IOPS cap) are legacy.
Why it exists
Disk management was a pain: unmanaged disks tied performance to a storage account and had an IOPS ceiling. Managed disks hide that — you pick a UI/SSD/HHD tier and Azure places it for scale and high availability automatically.
Key ideas
- Disk types: Premium SSD (low latency, production), Standard SSD (consistent, entry production), Standard HDD (backup, sparse access), Ultra disk (extreme IOPS for data-heavy), plus Premium SSD v2.
- Ephemeral OS disk: OS disk stored on the VM’s local temporary storage — resets on deallocate/restart but gives lower latency and lower cost; ideal for stateless or scale-out workloads (e.g. scale sets) and the cache/batch tier.
- OS disk vs data disks: one OS disk, up to many data disks; each has a size and type.
- Snapshots & images: snapshots capture a point-in-time copy; images are generalized system images reused for provisioning.
- Redundancy: zone-redundant and locally-redundant disk options.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: virtual-machines/managed-disks-overview
Exam notes
- Max 4 TiB typical per-managed-disk scalability is governed by size tier; data disk IOPS/throughput scale with disk size (choose size = choose guaranteed IOPS).
- Ephemeral OS disk: benefits = free, low latency; trade-off = data lost on deallocate/restart and VM size must support it. Only for cache/temp workloads.
- Detach a data disk to move it to another VM (persistent disks survive VM deletion unless otherwise deleted).
- OS/data disk encryption uses Azure Disk Encryption or server-side encryption; SSO/managed-identity prep not required for the exam details.
- Snapshots → new disks or images is the standard backup/migration path.
az vm disk snapshot/ portal Snapshot button.
Related
Path MOC · azure-vm · vm-snapshot · availability-set · virtual-machine-scale-set
📘 Source: Microsoft Learn — Managed Disks
VM snapshots and images
What it is
- A snapshot is a read-only, full point-in-time copy of a managed disk, regionally stored, used for backup, or to build new disks.
- An image (shared image / managed image) is a generalized OS + apps blueprint you deploy many VMs from, backed by the Azure Compute Gallery for versioning and regional replication.
Why it exists
You need to recover a broken VM, or stamp out many identical VMs without reconfiguring each. Snapshots give cheap rollback; images give repeatable, versioned, regionally-replicated provisioning.
Key ideas
- Snapshot → new disk → attach to a VM; or snapshot both OS+data disk to reconstruct a VM. Snapshots of a running VM can be inconsistent unless the app is quieted.
- Generalization: Windows
sysprep, Linuxwaagent -deprovision— removes machine-specific data so the image can be deployed to many VMs as if new. - Managed image vs Compute Gallery: shared images in the Azure Compute Gallery support versioning (
publisher:offer:sku:version) and replication to multiple regions → the modern path. - Images + scale sets / Bicep → consistent fleet provisioning.
How it fits (diagram)
Exam notes
- Snapshot = disk-level backup; does not generalize — do not boot the same SID/hostname on many snapshots.
- To create a reusable fleet image: generalize first (sysprep/waagent), then capture image. Deploying the same image (not generalized) to many VMs causes identity conflicts.
- Azure Compute Gallery (formerly Shared Image Gallery) = versioned + globally replicated images, integrated with scale sets for patching.
- AZ-104: understand when to snapshot vs image vs Back up VM (Azure Backup) for disaster recovery.
Related
Path MOC · managed-disks · azure-vm · virtual-machine-scale-set
📘 Source: Microsoft Learn — Vm Snapshot
Availability
Availability set
What it is
An availability set is a logical grouping of VMs that spreads them across fault domains (distinct racks/datacenter fault hardware) and update domains (reboot groups during planned maintenance) so that a single hardware failure or maintenance window doesn’t take down the whole workload. Also called availability set across FDs/UDs in a region.
Why it exists
A single VM sits on one physical host — any host/rack failure or Azure patch cycle could kill it. Availability sets arrange VMs across independent failure boundaries for 99.95% service-level availability, without needing multiple regions.
Key ideas
- Fault domain (FD): a set of hardware that shares a common power/network/rack — whole FDs fail together. Put replicas in different FDs.
- Update domain (UD): reboot groups applied sequentially during planned maintenance. VMs in different UDs are rebooted one group at a time (up to 20 UDs).
- Put 2+ VMs into an availability set to qualify for the SLA; place each VM in its own FD/UD.
- Zonal vs regional: availability sets are regional; availability zones are per-datacenter-isolated — newer, higher granularity.
- Combine with an internal load balancer to distribute traffic across the set’s VMs.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: virtual-machines/availability-set-overview
Exam notes
- Availability sets and availability zones are mutually exclusive for a VM — choose one for a given VM/scale set. (Zones give higher isolation; sets give rack-level within a region.)
- You must have ≥2 VMs in a set to get the availability SLA.
- Classic exam question: “spread VMs across racks + maintenance reboots” → availability set (fault + update domains).
- AZ-104 emphasizes knowing fault domain vs update domain vs zone semantics.
Related
Path MOC · azure-vm · availability-zones · virtual-machine-scale-set
📘 Source: Microsoft Learn — Availability Set
Availability zones
What it is
Availability zones are physically separate datacenters within an Azure region — each zone has independent power, cooling, and networking. By placing VMs (or a scale set) in multiple zones, you survive a whole-zone failure. Zonal isolation is the strongest availability option within a region.
Why it exists
Fault/update domains protect against rack-level loss; a zone failure (entire datacenter in a region) is a bigger blast radius. Zones give you 99.99% availability and true regional-disaster tolerance inside one region for the workloads that can afford the cost.
Key ideas
- Usually a region has 3 zones. Resources are tagged zone 1/2/3 or use zone-redundant placement.
- Zone-redundant services (LB, storage, App Service plans) replicate automatically across zones.
- For VMs: distribute replicas across the zones via zonal deployment or a zone-redundant scale set.
- Zone-redundant storage (ZRS) and zone-redundant managed disks keep data available when a zone fails.
- Zones are available in select regions only — not every Azure region exposes zones (exam checks this).
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: availability-zones/az-overview
Exam notes
- Zones ⊄ availability sets: you choose either the wider failover (zones) or the rack-level spread (set), per VM/scale set — not both for the same deployment.
- Zone-redundant options exist for Azure Load Balancer (Standard), App Service plans, and storage — AZ-104 asks which services are zone-redundant.
- Only launch into zones if the region supports them; check
Get-AzLocation/ docs. - Zonal vs regional: AZ-104 wants you to pick zones when you need datacenter-level redundancy.
Related
Path MOC · azure-vm · availability-set · virtual-machine-scale-set · managed-disks
📘 Source: Microsoft Learn — Availability Zones
Virtual Machine Scale Sets (VMSS)
What it is
A Virtual Machine Scale Set runs a fleet of identical VMs created from the same image/configuration, managed as one unit, with automatic scaling and load balancing built in. VMs are added/removed on demand and spread across fault domains, update domains, or availability zones.
Why it exists
Individually managing dozens of identical VMs is impossible to scale — patching, load distribution, and right-sizing would be manual. Scale sets give automatic scale-out/in (by metric/CPU/time), homogeneity, and fleet-level manageability.
Key ideas
- Scaling modes: manual, automatic (by metric), or autoscale rules (CPU %, queue length, schedule) — with min/max/default instance counts.
- Horizontal scaling (scale out/in) = add/remove VM instances; vertical scaling (scale up/down) = resize instance size. AZ-104 availability module covers both.
- Availability: instances are spread across fault domains, update domains, or availability zones automatically.
- Instance types: uniform (old) vs Flexible orchestration (newer) — flexible runs standard marketplace images and integrates with Virtual Networks directly.
- Integrated with Azure Load Balancer / Application Gateway and disk storage; uses a scale-set autoscale profile.
- Critical requirement: scale sets must be able to add instances quickly — often used with images (golden images) and ephemeral OS disks.
- Disks: instances are disposable; critical data lives in attached/data disks or storage, not the OS ephemeral disk.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: virtual-machine-scale-sets/overview
Exam notes
- Autoscale = logical combination: scale sets scale out/(add VMs) or in (remove); configure min/max and rules.
- Metrics triggering scale often use Application Insights / diagnostic data (CPU %, message queue depth), applied via autoscale profiles.
- Fault domains in a scale set: update each VM instance; VM instances are automatically spread — no manual FD assignment needed.
- Promoting a new OS config → update the scale set model + rolling upgrade.
- AZ-104: know that horizontal scaling is scale sets, vertical is resize; zone/fault-domain distinction.
Related
Path MOC · azure-vm · vm-sizes · availability-set · availability-zones · managed-disks · azure-vm-extension
Azure VM extensions
What it is
Azure VM extensions are small packages that run post-deployment automation inside a VM’s guest OS — installing software, running scripts, configuring settings, applying security/antimalware, collecting diagnostics. They are applied after the VM is created (Config drift fix) via the VM agent that runs in the guest.
Why it exists
You can’t easily log into every VM to bootstrap software at scale. Extensions let you execute the same bootstrap/maintenance on one VM or a whole scale set declaratively, reproducibly, and from the control plane (Portal/CLI/templates).
Key ideas
- Custom Script Extension (Windows
CustomScriptExtension, LinuxcustomScriptorCustomScriptForLinux): pass a script (inline or from blob storage) that runs on the guest — the most common way to bootstrap/configure a VM. - VM agent (waagent / WindowsGuestAgent) must be installed for most extensions; most marketplace images include it.
- Other common extensions: Azure Monitor agent (diagnostics), Desired State Configuration (
DSC), Network Watcher agent; DSC for Windows configuration state. - Extensions are defined in the VM/scale set model; Managed identity + Key Vault lets a custom script fetch secrets safely.
How it fits (diagram)
Exam notes
- Run Custom Script Extension at provisioning to avoid manually SSH/RDP-ing into every VM; it’s idempotent-ish — re-running is usually safe but scripts should be written to be idempotent.
- External dependencies (script URL in blob storage) must be accessible; use Key Vault / SAS for secure script retrieval.
- Diagnostics extension (boot diagnostics) helps troubleshoot VM boot issues via serial console.
- AZ-104: Custom Script Extension is the go-to tool to “configure a new VM after creation”.
Related
Path MOC · azure-vm · azure-cli · arm-template · virtual-machine-scale-set
📘 Source: Microsoft Learn — Azure Vm Extension
IaC
Bicep
What it is
Bicep is a domain-specific language (DSL) that lets you define Azure infrastructure declaratively as code, with an easy-to-read, concise syntax. It transpiles to ARM template JSON before deployment, so it is a friendlier authoring layer over the same Azure Resource Manager deployment engine.
Why it exists
ARM templates (JSON) are verbose, hard to read, and error-prone. Bicep gives you the same declarative infrastructure-as-code power — variables, parameters, modules, loops, conditions, dependencies — with syntax like a modern language, plus native tooling (formatter, linter, VS Code extension, preview of changes).
Key ideas
- Transpilation:
bicep buildcompiles a.bicepfile → ARM JSON; you deploy that, or deploy.bicepdirectly (az deployment group create -f main.bicep). - Declarative: you state the target state; ARM computes the diff from current state and applies it (idempotent, no re-provisioning of unchanged resources).
- Modules (
module child './x.bicep') reuse template pieces; parameters and variables make templates configurable. - Resource dependencies are inferred automatically (Bicep figures out the order).
- Compiles to full ARM JSON → all ARM features (expression evaluation, functions) still apply.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-resource-manager/bicep/overview
Exam notes
- Bicep compiles to (maps 1:1 to) an ARM template — they are two views of the same deployment.
- Files end in
.bicep;az deploymenttargets resource-group or subscription scope. - In AZ-104 pop quiz: “declarative, readable language for Azure IaC” → Bicep (vs imperative CLI/portal); preferred over hand-writing JSON.
- Same deployment engine as ARM templates → idempotent diff-based apply.
Related
Path MOC · arm-template · azure-cli · azure-vm
📘 Source: Microsoft Learn — Bicep
ARM templates
What it is
An ARM template is a JSON file that declaratively describes the resources you want to deploy to Azure and their relationships, in a logical object model. Azure Resource Manager reads it and provisions the resources idempotently — it diffs against the current state and applies only the changes needed to reach the declared goal.
Why it exists
Clicking through the Portal or imperative CLI is fine for one resource but not reproducible or auditable for a fleet. Templates make infrastructure code: versioned in git, reviewed, reused with parameters, and safely re-run (no surprise re-provisions).
Key ideas
- Idempotent / declarative: re-deploying the same template brings resources to the declared state — unchanged ones are left alone.
- Structure (top-level elements):
$schema,contentVersion,parameters,variables,functions,resources, andoutputs. - Scope: resource-group, subscription, management group, or tenant deployment.
- You can deploy incrementally (default) or complete; type parameters make templates reusable.
- Bicep is a modern DSL that compiles down to these JSON templates (same engine). Could use
ConvertTo-Json/portal “Export template” to get a starting point. - Deploy via Portal, Azure CLI (
az deployment), PowerShell, or Azure DevOps/GitHub Actions.
How it fits (diagram)
Exam notes
- ARM template vs MPI (managed identity): not related — templates are IaC.
- Incremental vs complete deployment modes: incremental only adds/changes listed resources; complete deletes resources in the RG not in the template (dangerous — default is incremental).
- Linked/nested templates with
deploymentsresource for modularity. - Exam: recognize template JSON anatomy and that it’s declarative + idempotent.
Related
Path MOC · bicep · azure-cli · azure-vm
📘 Source: Microsoft Learn — Arm Template
Azure CLI
What it is
Azure CLI (command az) is Microsoft’s cross-platform command-line tool for creating and managing Azure resources. It wraps the Azure REST API / ARM control plane, letting you script and automate everything you’d otherwise click in the Portal — useful for provisioning, configuration, and repeatable operations.
Why it exists
Administering Azure interactively-at-scale requires automation. The CLI gives you a single, scriptable interface (works on Windows/macOS/Linux, via bash or PowerShell, and in Cloud Shell) so compute tasks like creating a VM or deploying a Bicep template are repeatable and auditable.
Key ideas
- Command groups mirror services:
az vm,az appservice,az acr,az aks,az container,az functionapp,az group,az deployment. - Authentication:
az login(interactive or service-principal) /az account setto pick a subscription. Output is JSON by default. - Two styles for many VM tasks:
az vm create(resource group, name, image, size, auth) andaz disk/az snapshot. - Deployment:
az deployment group create --resource-group <rg> --template-file main.bicepfor IaC. - Works with PowerShell — many places PowerShell is equivalent tooling for AZ-104.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure/cli/
Exam notes
- AZ-104 wants you to know the key compute verbs:
az vm,az vmss,az appservice plan,az appservice webapp,az container,az aks,az acr,az functionapp. az vm deallocatestops billing;az vm redeploymoves to a new host;az vm generalize+ capture for images.- Scriptable automation is the differentiator vs Portal; pair with Bicep/ARM and Azure DevOps CI/CD.
- Same outputs achievable in PowerShell — the exam mentions CLI/PowerShell together.
Related
Path MOC · azure-vm · bicep · arm-template
📘 Source: Microsoft Learn — Azure Cli
PaaS
Azure App Service
What it is
Azure App Service is Azure’s Platform as a Service (PaaS) for hosting web apps, APIs, and mobile backends. You deploy your code and App Service manages the OS, patching, scaling, TLS, and load balancing for you. No VMs to manage — you focus on the app.
Why it exists
Hosting a website by hand means provisioning VMs, installing a web server, patching the OS, and scaling manually. App Service abstracts all of that: deploy (via Git, ZIP, DevOps, or CI/CD) and the platform keeps it running and scales it on a plan.
Key ideas
- Choice of runtime: .NET/.NET Core, Java, Node.js, Python, PHP, and containers (Linux/Windows).
- Runs on an App Service plan, which defines the pricing tier / SKU and capacity; the app itself is the “web app” (site) on the plan.
- Built-in security: managed TLS/SSL, App Service authentication (Entra/social), IP/access restrictions, Managed identities, VNet integration.
- Deployment features: deployment-slots (staging), continuous deployment from GitHub/Azure DevOps, App Service Deployment Center.
- Scaling: scale up (bigger SKU) and scale out (more instances on the plan) — same tier and instance limits as the plan.
- Monitoring: Azure Application Insights for app telemetry and logs.
- Backup/restore and custom domains with managed certificates.
How it fits (diagram)
Exam notes
- App Service = PaaS; you do not patch OS (+ automatic platform patching). Contrast with VMs.
- Deployment slots let you validate a warm deployment then swap (zero downtime).
- Custom domain + TLS binding; App Service Authentication (identity module) for Entra/social auth without code.
- The plan determines scale limits/size; multiple apps can share one plan.
- AZ-104: App Service authentication, deployment slots, scaling via plan, and Application Insights telemetry are the focus areas.
Related
Path MOC · app-service-plan · deployment-slots · azure-functions
📘 Source: Microsoft Learn — App Service
App Service plans
What it is
An App Service plan is the container and billing unit for one or more App Service apps. It defines the pricing tier (SKU), the compute capacity / worker size, the number of instances (scaling), and available features. Every web app, API, or Functions app on that plan shares its resources.
Why it exists
You need a consistent, predictable compute container that hosts apps and can scale. The plan centralizes size + tier + scale decisions: pick a tier (Free → Premium) for features, and scale up (resize) or out (add instances) at the plan level, which affects every app in it.
Key ideas
- Pricing tiers (examples): Free/Shared, Basic (production, no autoscale — manual scale only, up to 3 instances), Standard (autoscale, staging slots, backups), Premium (more capacity, more instances, private endpoints), Isolated (dedicated VNet, network isolation) — and newer Premium v3 / P0v3 with memory-optimized and Pay-as-you-go.
- Scaling: scale up (bigger SKU/worker → more RAM/CPU per instance) vs scale out (more instances — autoscale rules allowed from Standard tier).
- Plan determines feature limits: deployment slots, autoscale (min/max rules), VNet integration, custom domains, and zone redundancy mostly appear in paid tiers.
- Multiple apps can share one plan (saves cost) — but they compete for resources; a heavy app can starve others.
- App Service Environment (ASE) runs plans in a dedicated regional/zone VNet for hard network isolation.
How it fits (diagram)
Exam notes
- Autoscale on App Service requires Standard (or higher) tier; Free/Shared/Basic lack autoscale.
- Choose tier by feature needs — not every feature is in every tier (AZ-104 asks which features each tier supports).
- Zone redundancy on plans is available for select tiers and regions.
- Scaling the plan scales all apps it hosts; isolate critical apps on their own plan.
- AZ-104: “pick a plan tier, scale up/out, understand shared-plan contention.”
Related
Path MOC · app-service · virtual-machine-scale-set
📘 Source: Microsoft Learn — App Service Plan
Deployment slots
What it is
Deployment slots are separate, fully configured staging environments for an App Service web app, each with its own hostname and settings. You deploy to a slot, validate it (warm), then swap (preview) it into production with zero downtime.
Why it exists
Shipping directly to the live site is risky — you want to test the new version against real production settings before cutting it over. Slots let you release safely: deploy to staging, smoke-test with production app settings, then atomic-swap traffic instantly and roll back by swapping again. Common pattern for blue/green deployment.
Key ideas
- Environment per slot: each slot is a full deployment + its own app settings/connection strings (when not marked as deployment slot settings).
- Swap process: preview shows the changes, swap swaps deployment AND slot-specific settings you mark; slot settings (connection strings, app settings flagged
slotSticky) stay with their slot through swap. - Auto-swap: enable to swap automatically after a successful deployment in CI/CD.
- Enables rollback: swap back to the previous version if a regression is found.
- Slots are available on Standard tier and above (not Free/Basic).
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: app-service/deploy-staging-slots
Exam notes
- Slot swap = zero-downtime deployment; the production URL points at the new slot after swap.
- Deployment (slot) settings differ from regular app settings: slot settings persist with the slot across swaps (
WEBSITE_values, connection strings marked as such). - Staging slots require Standard (or higher) plan.
- AZ-104: know how to protect production keys by marking them as slot settings so they don’t get swapped to staging.
Related
Path MOC · app-service · app-service-plan
📘 Source: Microsoft Learn — Deployment Slots
Azure Functions
What it is
Azure Functions is a serverless computing service: you run short-lived, event-driven functions in response to triggers without provisioning or managing infrastructure. Pay only for execution time — the platform scales automatically per event and you only run when something triggers you.
Why it exists
Many tasks are event-driven and bursty (an HTTP request, a queue message, a blob upload, a timer). Reserved VMs or even containers sit idle costing money. Functions give scale-to-zero — you run only when events fire, autoscale up automatically under load, and pay per execution.
Key ideas
- Triggers kick off functions: HTTP trigger, Timer, Azure Storage Queue/Blob/Event Hub triggers, Azure Service Bus, Event Grid, Cosmos DB, and more.
- Bindings: declarative input/output bindings connect to other services (e.g. read from blob, write to queue) with minimal code.
- Hosting plans: Consumption (scale-to-zero, per-execution billing), Premium plan (warm instances, VNet), and Dedicated App Service plan — the plan choice affects scaling and cost.
- Runs inside a Function App — the container grouped with app settings, identity, and runtime config.
- Durable Functions orchestrate stateful, long-running workflows.
- Runs on the Functions runtime; supports .NET, Java, Node, Python, PowerShell.
How it fits (diagram)
Exam notes
- Serverless ≠ no server: platform-managed servers, scale-to-zero, per-execution billing on Consumption plan.
- Choose Premium plan when you need warm instances / VNet integration / no cold-start at large scale.
- Triggers vs bindings: triggers start the function; bindings connect to input/output data.
- AZ-104: recognize scope — Functions are the serverless compute in the compute spectrum, alongside ACI and AKS. Function Apps often run under an App Service plan (Dedicated) too.
Related
Path MOC · app-service · aci · aks
📘 Source: Microsoft Learn — Azure Functions
Containers
Azure Container Instances (ACI)
What it is
Azure Container Instances (ACI) is Azure’s serverless container service: you run a Docker container (an OCI image) directly without managing a Kubernetes cluster or orchestrator. Each instance is a container (or a group of containers) scheduled by Azure, with your choice of CPU/memory and networking.
Why it exists
Running a container with AKS is powerful but heavy — you manage nodes and orchestration. Many jobs (a one-off batch, a small microservice, a CI/CD job, a web app) just need a container up quickly: no cluster to operate, pay per second, scales/schedules automatically.
Key ideas
- Container groups: ACI schedules containers into container groups that share a lifecycle, network, and storage (all containers in a group on one host; e.g. a sidecar + app).
- No orchestration needed: ideal for simple/short-lived workloads; for production-scale orchestration, choose AKS.
- Images from Azure Container Registry (or Docker Hub / public registries).
- Networking: exposed either with a public IP + DNS or on a virtual network (ACI supports VNet injection on select/standard SKU).
- Resource specs specified as
--cpu/--memoryataz container create. - Pricing: per-second billing for active containers; no infra to provision.
How it fits (diagram)
Exam notes
- ACI = serverless container — use when you need containers without that AKS Kubernetes overhead.
- Container groups are the ACI scheduling unit; containers in one group share the host/network.
az container create --acrpulls from ACR; can mount file shares (Azure Files).- Know the containers vs VMs decision: containers share the OS, VMs virtualize the OS — lighter, faster startup for microservices/batch.
- AZ-104 module Configure Azure Container Instances covers when to use ACI, its features, and container groups.
Related
Path MOC · aks · acr · azure-functions
📘 Source: Microsoft Learn — Aci
Azure Kubernetes Service (AKS)
What it is
Azure Kubernetes Service (AKS) is a managed Kubernetes offering: Microsoft provides the control plane (API server, etcd) for free, and you manage only the worker nodes in a node pool. It brings full Kubernetes orchestration — scheduling, scaling, self-healing, service discovery, rolling updates — to Azure.
Why it exists
When you outgrow single containers (ACI) and need fleet orchestration — dozens of containers, autoscaling, load balancing, health probes, rolling deployments — you need Kubernetes. Running K8s yourself is hard; AKS offloads the control plane so you focus on workloads, and integrates with Azure networking/storage/identity.
Key ideas
- Components: control plane (managed, free, SLA’d) + node pools (your VM-based nodes, billed); a kubelet runs on each node.
- Workload objects: Pods, Deployments, Services, Ingress; namespaces for isolation.
- Networking: integrates with Azure Virtual Network via CNI (Azure CNI or kubenet); Azure Load Balancer fronts
Service(LoadBalancer) workloads. - Storage: persistent volumes via Azure Disks / Azure Files CSI drivers.
- Scaling: Horizontal Pod Autoscaler (HPA) and cluster autoscaler to add/remove nodes; az aks` CLI manages the cluster.
- Registry: pulls images from Azure Container Registry (ACR integration).
- Identity: AKS uses managed identity + Azure RBAC / Kubernetes RBAC integration.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: aks/intro-kubernetes
Exam notes
- AKS = managed orchestration; you pay for nodes, control plane is included.
- Use AKS for fleet/orchestrated containers; ACI for single/serverless containers. “VMs vs containers vs orchestration” is a core AZ-104 decision.
- Commands:
az aks create,az aks get-credentials,kubectl apply. - AZ-104 focus is high-level: understand what AKS provides and when to pick it — not deep kubectl admin.
- Note: Functions (azure-functions) remain the serverless alternative to running your own pods.
Related
Path MOC · aci · acr · azure-functions
📘 Source: Microsoft Learn — Aks
Azure Container Registry (ACR)
What it is
Azure Container Registry (ACR) is a managed private registry for container images (and related OCI artifacts). You store, build, and distribute your container images locally in Azure, controlling access with Entra authentication and built-in security features (georeplication, retention, network isolation).
Why it exists
Public registries (Docker Hub) are outside your security perimeter and have pull limits. ACR keeps your images private, close to your compute, authenticates with Microsoft Entra identity, and lets you build images in the cloud — the trusted source that ACI and AKS pull from.
Key ideas
- SKUs: Basic / Standard / Premium — Premium adds georeplication, private endpoints, and increased throughput.
- Many registries → many repos → many images/tags; tag images with versions so ACI and AKS can pull updates.
- Build inside ACR via ACR Tasks (
acr build,acr task) so images don’t leave your network. - Security: Entra role-based auth (
AcrPull/AcrPush), anonymous pull off option, firewall/private-link on Premium. - Integration:
az container create --image <acr>/repo:tag(ACI) andaz aks create --attach-acr/ K8s imagePullSecrets (AKS) use it without exposing credentials. - Georeplication replicates images across regions for low-latency pulls and resilience.
How it fits (diagram)
Exam notes
- ACR is the private image store feeding ACI and AKS; authentication is Entra-based (not shared secrets).
- Premium SKU required for georeplication and private endpoints.
- ACR Tasks build images in-region (
acr build) — a common AZ-104/Docker workflow. - AZ-104: connect ACR ↔ ACI (
--acr) and ACR ↔ AKS (attached registry) for private pulls.
Related
📘 Source: Microsoft Learn — Acr