Manage Container Registries and Containers for AZ-104

This part of AZ-104 is about container administration in Azure, not full platform engineering. You are not being tested as an application developer. You are being tested on whether you can provision the right container surface, connect it to the right registry, and manage scale or sizing without confusing the registry, the runtime, and the web-hosting platform.

What Microsoft explicitly includes

The current outline covers Azure Container Registry, Azure Container Instances, Azure Container Apps, and sizing and scaling for containers in the Azure portal.

The operational frame to use

ACR stores images. ACI runs simple container workloads quickly. Container Apps adds a managed app platform with scaling and ingress behavior. If you know which layer each service owns, many exam questions become much easier.

Common traps

The common misses are assuming every container scenario needs the same platform, confusing the registry with the runtime, and sizing containers without checking whether the requirement is bursty app behavior or just simple container execution.

Lab moves worth practicing

• push an image into Azure Container Registry
• deploy one simple workload to ACI or Container Apps
• inspect container sizing and scaling settings and explain which service owns them

Hosting chooser

Registry versus runtime is a core distinction

If the question says “store image,” “push image,” or “private registry,” think ACR. If it says “run a container quickly,” think ACI. If it says “managed app platform with ingress and scaling,” think Container Apps.

Container runtime chooser

Use ACI when you want the smallest, quickest container runtime with minimal platform scaffolding. Use Container Apps when you need a managed application platform with ingress and scale behavior.

Objective coverage inside this page

Keep the boundaries clear:

• registry: ACR
• runtime: ACI and Container Apps
• operational control: sizing and scaling for the chosen container host

If the scenario is mostly about image storage or lightweight container execution, stay on the container side. If it is about managed web-hosting operations such as TLS, custom domains, slots, or App Service plans, move to 3.4 App Service Plans, TLS & Slots.

Azure CLI example: ACR plus ACI flow

This example shows the registry and runtime boundary that AZ-104 expects you to recognize quickly.

 1az acr create \
 2  --name acrdemo104 \
 3  --resource-group app-rg \
 4  --sku Basic
 5
 6az container create \
 7  --resource-group app-rg \
 8  --name aci-demo \
 9  --image acrdemo104.azurecr.io/web:1.0 \
10  --cpu 1 \
11  --memory 2

What to notice:

• ACR owns the image inventory
• ACI is one runtime option that can consume that image
• the sizing decision is attached to the runtime choice, not to the registry itself

Container sizing and scaling questions

The exam is not asking for deep Kubernetes design here. It is checking whether you can place the workload on the right Azure container surface.

Quiz

Next, move to 3.4 App Service Plans, TLS & Slots to cover the web-hosting administration features Microsoft tests separately from the container objective group.