Provision and Manage Containers in Azure (AZ-104)

Before you deploy anything, you need to know what each Azure container service is for, because the exam tests the decision as much as the steps. All three services run OCI-compliant container images, but they solve different problems.

Azure Container Registry (ACR) is not a place to run containers; it is a private, managed registry that stores your images so your compute services can pull them. Almost every container workload starts by pushing an image to ACR.

Azure Container Instances (ACI) is the simplest way to run a container. You give it an image, a CPU and memory size, and it starts in seconds. There is no cluster and no orchestration, so it suits short-lived, isolated, or bursty tasks.

Azure Container Apps is a serverless platform for running containers that need to scale. It adds automatic scaling (including scaling to zero), HTTPS ingress, and revisions, so it fits microservices, APIs, and event-driven jobs without you managing any Kubernetes.

For heavier needs there is Azure Kubernetes Service (AKS), a fully managed Kubernetes cluster, but on AZ-104 you keep AKS at recognition level and focus on ACR, ACI, and Container Apps. Think of it as registry, run-it-once, and scale-it: that mental model answers most questions.

Azure Container Registry is a fully managed, private registry for storing and distributing container images and related artifacts. You create one from the portal with Create a resource > Containers > Container Registry, giving it a globally unique name; its login server becomes <name>.azurecr.io, and every image in it is addressed as <name>.azurecr.io/<repository>:<tag>.

Service tiers

ACR comes in three service tiers (SKUs). All three support the same core registry operations, Microsoft Entra authentication and repository-scoped tokens; they differ in included storage, throughput and a set of Premium-only features. You can change tier at any time without downtime.

Zone redundancy is not a Premium feature any more. Microsoft now makes every registry zone-redundant automatically, in every tier, in regions that support availability zones. Zone redundancy protects against a datacenter failure within one region; it does nothing for slow pulls from a distant region or for a whole-region outage. Those needs are met by geo-replication (Premium): one registry name, one push, with replicas in each region you add so each region pulls locally and keeps pulling if another region fails.

Use a private endpoint (Premium) when the registry must be reachable only on a private IP in your virtual network, with public network access disabled. When clients sit behind a strict firewall and cannot use Private Link, dedicated data endpoints (Premium) help: image layers normally download from a broad *.blob.core.windows.net storage domain, but with dedicated data endpoints enabled they come from <registry>.<region>.data.azurecr.io, one per region where the registry has a replica. The firewall then allows only the login server and those data endpoints instead of opening every Azure storage account.

Older material also lists content trust (Docker Content Trust, for signed images) as a Premium feature. Microsoft is retiring it: since 31 May 2026 it cannot be enabled on registries that did not already use it, and it will be removed on 31 March 2028. Image signing now uses the Notary Project instead.

Getting images into the registry

There are three ways to put an image into ACR, and the right one depends on where the image is and whether Docker is available:

• Push a local image. Sign in with az acr login --name <name>, then docker tag the local image with the fully qualified name (<name>.azurecr.io/repo:tag) and docker push that name. Docker uses the registry host in the image name to decide where to push, so an image tagged without the login server goes nowhere useful.
• Build in Azure with az acr build. ACR Tasks builds the image from a Dockerfile and build context you upload, then pushes the result to the registry. No local Docker daemon is needed, which is why it works from Azure Cloud Shell or a lightweight build agent.
• Copy from another registry with az acr import. Import copies an existing image from Docker Hub, another ACR or another public or private registry straight into yours, server-side, without pulling it to your machine. It does not build anything.

Authentication and least privilege

Choose the authentication method by who the client is and how little access it needs:

A service principal with AcrPull is least-privilege but still authenticates with a client secret or certificate that someone must store and rotate; a managed identity removes that secret entirely. For AKS, az aks update --attach-acr <registry> (or --attach-acr at cluster creation) assigns AcrPull on the registry to the cluster's kubelet managed identity, so nodes pull without any image pull secret.

Tokens are available in every tier. To push, a token's scope map needs both content/read and content/write on the repository (a push reads existing layers too). The built-in system scope maps (_repositories_pull, _repositories_push, _repositories_admin) apply to every repository, so single-repository access needs a custom scope map. Disabling or deleting one token revokes just that client.

Azure Container Instances is the quickest path from an image to a running container. You create a Container instance resource, point it at an image in ACR (or a public registry), set the number of CPU cores and amount of memory (GB), and Azure starts it in seconds: no VM to patch and no orchestrator to configure. ACI runs both Linux and Windows containers, although Windows is limited to single-container groups and cannot mount volumes (VNet deployment works for both).

Billing

ACI bills per second, for the vCPU and memory a container group requests, from the moment its image starts pulling until the group stops. The charge is on the allocation, not on measured utilisation: a group that requests 2 vCPUs and 4 GB pays for 2 vCPUs and 4 GB even if the application idles at a fraction of that. Right-sizing the request is therefore the main cost lever, and a run-to-completion job that stops (restart policy OnFailure or Never) stops billing.

Restart policy

The restart policy is set once per container group and applies to all its containers:

A service deployed with OnFailure or Never stays down after it exits, because OnFailure ignores a clean exit and Never ignores every exit. The restart policy cannot be changed on an existing group: you delete and recreate it (see sizing and updates below).

Container groups

A container group is the unit ACI schedules: a collection of containers placed on the same host that start and stop together and share one IP address and port namespace and any mounted volumes, similar to a Kubernetes pod. Containers in a group reach each other over localhost on their ports, which makes the sidecar pattern (a log shipper or proxy beside the app) natural; two containers in one group cannot both listen on the same port. The host provides the sum of each container's CPU and memory requests. Multi-container groups are Linux-only and are deployed from a YAML file (az container create --file) or an ARM/Bicep template; the portal's create wizard deploys a single container.

Networking and DNS

A group gets either a public IP or a private address in a virtual network:

• Public: add a DNS name label to get a stable host name under <region>.azurecontainer.io. The public IP itself is not guaranteed to survive a restart or redeploy, so clients should use the name. The DNS name label scope reuse policy (tenant, subscription, resource group, no reuse, or any reuse) controls who can claim the same label later; every policy except any reuse appends a generated hash to the label in the FQDN, which protects against someone else taking over a deleted name.
• Virtual network: deploy the group into a delegated subnet to reach private resources such as a VM on its private IP. A VNet-deployed group cannot have a public IP or a DNS name label. To publish it to the internet, put an Application Gateway (or a Standard Load Balancer) with a public frontend in front of it; outbound traffic must go through a NAT gateway on the subnet (the only supported outbound configuration), which also gives the group a fixed public outbound IP.

Attach a managed identity with AcrPull so the group can pull from ACR without stored credentials. ACI does not autoscale; it runs exactly what you deploy. Choose it for simple, isolated, or bursty tasks that need no orchestration.

ACI gives you three ways to hand configuration to a container, and the right one depends on whether the value is sensitive and whether the application expects a variable or a file. Volumes, in turn, decide whether data survives the container group.

ACI volume types and how long their data lives:

Mounting an Azure Files share has three constraints worth knowing: it is supported only for Linux containers, the deployment must supply the storage account name and storage account key, and the container must run as root. It is the only ACI volume whose data outlives the container group, so it is the answer whenever output must be available after the group is deleted or redeployed.

Azure Container Apps is a serverless container platform for applications that need to scale and talk to each other. It is built on Kubernetes, KEDA, Dapr, and Envoy, but Microsoft manages all of that for you: you never create or patch a cluster. It runs Linux (linux/amd64) container images only. You provision a Container App inside a Container Apps environment (a secure boundary that apps share, typically sending logs to a Log Analytics workspace and optionally placed in your own virtual network), choose an image, and set CPU and memory.

Its defining feature is automatic scaling driven by scale rules: Container Apps adds or removes replicas between a minimum and maximum based on HTTP traffic, TCP connections, CPU or memory, or KEDA event sources such as the length of a queue, and with the right rules it scales to zero (details in the sizing section). It also provides built-in ingress with automatic HTTPS certificates and load balancing, and revisions, immutable snapshots of a version that you can split traffic across and roll back to. Together these make Container Apps the right choice for microservices, background processors, and event-driven workloads that a single ACI container cannot scale to handle.

Who can reach a container app is decided at two levels: the environment, chosen once when you create it, and each app's ingress, which you can change at any time.

So an API that must be private to the network but callable by VMs in a peered VNet needs an internal environment plus app ingress accepting traffic from anywhere; internal app ingress would hide it from those VMs.

When you enable ingress you set the target port: the port the container actually listens on (for example 8080). Clients still connect on the standard ports, 443 for HTTPS (80 redirects to it by default), and Envoy forwards to the target port. Ingress is HTTP by default; TCP ingress serves non-HTTP protocols such as MQTT or a database wire protocol. External TCP ingress, and extra exposed TCP ports, require an environment with a custom virtual network, so if the environment was created without one you must create a new environment and redeploy the app there.

A revision is an immutable snapshot of a container app's template; changing the template creates a new revision. How revisions share traffic depends on the revision mode. The two generally available modes are (a newer deployment-labels mode is in preview):

• Single revision mode (the default): only one revision is active. A new revision replaces the old one once it is ready, so you cannot split traffic.
• Multiple revision mode: several revisions stay active and you assign traffic weights (for example 90/10 for a canary, then 0/100 to complete the rollout or back to roll back). Blue-green and canary releases need this mode.

Not every change creates a revision. Revision-scope changes (the container image, CPU and memory, environment variables, scale rules and other template properties) produce a new revision. Application-scope changes (secrets, ingress settings, traffic weights, revision mode, credentials and labels) apply to the app as a whole and create no revision. One consequence matters in practice: after you update a secret, running replicas keep the old value until you restart the revision or deploy a new revision.

A revision label gives a specific revision its own stable URL, independent of traffic weights. Move the label to a newer revision and the URL follows it, which suits a QA or preview endpoint while public traffic stays on the current revision (the revision's own URL changes with every revision, the label's does not).

The most common container question on AZ-104 is which service fits this workload. The answer hinges on how much scaling and orchestration you need versus how much control and operational effort you are willing to take on.

Read the scenario for signals. Run a single container quickly with no orchestration, or a Windows container job, is ACI. Serverless containers that scale to zero and handle variable traffic or events is Container Apps. Full control over Kubernetes, custom operators, or an existing Helm and YAML estate is AKS. Cost follows the same logic: ACI bills per second for what each group requests while it runs, Container Apps bills for replicas in use (nothing at zero on the Consumption plan), and AKS bills for the cluster nodes you keep running.

App Service can also run a custom container (covered in the App Service lesson) and brings managed HTTPS, custom domains and deployment slots, but an App Service plan always keeps at least one instance running, so it cannot scale to zero. When idle cost must drop to nothing, Container Apps is the fit. For AZ-104, ACI and Container Apps carry the weight; recognize AKS but reach for the simpler managed option unless the scenario explicitly demands raw Kubernetes.

Sizing and scaling work differently in each service, and the exam expects you to know which knobs exist and which changes need a redeploy.

Container Instances: fixed requests, limited in-place updates

For Azure Container Instances, sizing is a fixed request: you specify CPU cores and memory in GB for each container, and the group's host provides the sum. ACI has no autoscaling; for more capacity you deploy more container groups yourself. You update a running group by redeploying it with the same name (az container create again, or the same YAML/template), but only some properties can change that way:

An in-place update restarts the containers. Resizing a group therefore means deleting it and creating it again with the new values.

Container Apps: per-container allocations and workload profiles

In Azure Container Apps you set CPU and memory per container, but on the Consumption plan the total across all containers in the app (main container plus sidecars and init containers) must be one of the allowed pairs: vCPU in 0.25 steps with memory at twice the vCPU in Gi (0.25/0.5Gi, 0.5/1.0Gi, … up to 4 vCPU/8Gi; a Consumption-only environment tops out at 2 vCPU/4Gi). Adding a sidecar means choosing its allocation so the new total is still a valid pair.

A workload profiles environment offers two kinds of profile. The Consumption profile is serverless and billed per replica for what it uses. Dedicated profiles (general-purpose D-series and memory-optimized E-series sizes, plus GPU options) run on compute reserved for your environment, billed per node, and allow much larger replicas; choose Dedicated when replicas need more than the Consumption limits or the team wants predictable, reserved capacity.

Container Apps: scale rules and limits

Every app has a minimum and maximum replica count. The defaults are min 0 and max 10; the maximum can be raised (up to 1,000). Between them, scale rules add and remove replicas: HTTP (concurrent requests per replica), TCP (concurrent connections), custom rules backed by KEDA scalers (for example azure-servicebus on queue length, or an Azure Storage queue), and CPU or memory utilization.

• Scale to zero needs min replicas 0 and an HTTP, TCP or event-driven rule. CPU and memory rules cannot scale to zero, because there is no replica left to measure.
• Cold starts: with min 0 the first request after an idle period waits while a replica starts. Set min replicas to 1 or more to keep a replica warm (at a cost).
• Hitting the ceiling: if the revision runs at its maximum and requests still queue, raise the maximum replica count.

The practical rule: if a workload has steady, predictable demand or runs once and stops, size it with ACI. If demand rises and falls, such as spiky web traffic or a queue that fills and drains, let Container Apps scale it. Adding or removing replicas automatically by traffic or queue length is a Container Apps scale rule; ACI has no equivalent.

Consider two workloads in the same subscription, both using images stored in your Azure Container Registry.

Workload one: a nightly batch job. Every night a container must download files, transform them, and exit. It runs for a few minutes and does nothing the rest of the day, and it needs no scaling or ingress. This is a textbook fit for Azure Container Instances. You deploy a container instance sized to, say, 2 CPU and 4 GB, pull the image from ACR using a managed identity, and set the restart policy to OnFailure so it retries on error and stops when finished. Because ACI bills per second, you pay only for the few minutes it runs, with no idle cost and nothing to orchestrate.

Workload two: a public REST API. This service faces the internet, gets almost no traffic overnight, and spikes during business hours. Here you choose Azure Container Apps. You deploy the API with external HTTPS ingress, set the minimum replicas to 0 so it costs nothing when idle, and add an HTTP scale rule so replicas grow with concurrent requests and shrink again afterward. When you ship a new version, you release a new revision and split traffic to it, rolling back instantly if needed. Same registry, two workloads, two correctly chosen services.