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. After you sign in with az acr login --name <name>, you push images with docker push and your services pull them with docker pull.

ACR comes in three SKUs (tiers) that differ mainly in included storage, throughput, and features:

Geo-replication, keeping the same registry synchronized across regions so each region pulls locally, is a Premium-only feature.

You control access with one of three authentication methods. The admin user is a single built-in account with a username and password; it is disabled by default and Microsoft recommends it only for testing. For production you use Microsoft Entra ID identities with RBAC roles such as AcrPush and AcrPull, or a managed identity so that ACI, Container Apps, or AKS can pull images without any stored credentials. On the exam, a private image store points to ACR, and pulling without secrets points to a managed identity.

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. Because it is serverless, you are billed per second for the vCPU and memory you request, only while the container runs.

ACI supports a restart policy of Always, OnFailure, or Never, which is what makes it ideal for run-to-completion jobs: set OnFailure or Never and the container stops (and stops billing) once the work is done. You can give it a public IP and DNS name, or deploy it into a virtual network for private access, and attach a managed identity so it can pull from ACR securely.

For workloads that need more than one container together, ACI offers container groups: a collection of containers scheduled on the same host that share a lifecycle, network (a single IP and set of ports), and storage volumes, similar to a Kubernetes pod. Sizing a group means the host provides the sum of each container's CPU and memory. ACI does not autoscale; it runs exactly what you deploy. Choose ACI for simple, isolated, or bursty tasks that need no orchestration.

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. You provision a Container App inside a Container Apps environment (a secure boundary that apps share, backed by a Log Analytics workspace and optionally your own virtual network), choose an image, and set CPU and memory.

Its defining feature is automatic scaling driven by scale rules. You set a minimum and maximum replica count, and Container Apps adds or removes replicas based on HTTP traffic, TCP connections, CPU or memory, or KEDA event sources such as the length of a queue. Setting the minimum to zero gives you scale-to-zero: when there is no traffic, the app runs no replicas and costs nothing, then spins back up on the next request or event.

Container Apps also provides built-in HTTPS ingress (external or internal, with automatic certificates and load balancing) and revisions, which are immutable snapshots of a version. You can split traffic across revisions to do blue-green or canary releases, and roll back by shifting traffic to a previous revision. 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.

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 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 exactly what runs, Container Apps bills for active replicas (nothing at zero), and AKS bills for the cluster nodes you keep running. 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. For Azure Container Instances, sizing is a fixed request: you specify CPU cores and memory in GB for each container, and a container group's host provides the sum of those requests. ACI has no autoscaling; if you need more capacity, you deploy more container instances yourself. That fixed, predictable footprint is part of why ACI suits well-defined, one-off jobs.

Azure Container Apps also lets you set CPU and memory per container, but its real power is scale rules. Every app has a minimum and maximum replica count; between them, Container Apps adds and removes replicas automatically. You define rules based on HTTP concurrency (requests per replica), TCP, resource metrics, or KEDA event sources such as messages in a Service Bus queue or an Azure Storage queue. Setting the minimum replica count to 0 enables scale-to-zero, so an idle app costs nothing.

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. On the exam, add or remove replicas automatically by traffic or queue length always points to Container Apps scale rules, never to ACI.

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.