Deploy and manage Azure compute resources
Container Registry, Instances, and Container Apps
CoreSeparate image storage from execution and choose ACI or Container Apps from lifecycle and scaling requirements.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
Azure separates container image distribution from runtime, and administrators must match execution, networking, revisions, and scaling needs to the correct managed service.
Must Know
- Azure Container Registry stores private container images and artifacts; it does not execute them.
- Azure Container Instances runs container groups directly with assigned CPU, memory, environment, networking, and restart behavior.
- Azure Container Apps hosts application-oriented containers with environments, revisions, ingress, replicas, and automatic scaling rules.
- Container Apps can scale replicas from HTTP, event, or supported custom signals and can scale to zero for suitable configurations.
- The runtime needs permission and network reachability to pull a private image from ACR.
Compare and Distinguish
- ACR vs ACI vs Container Apps: image repository vs direct container-group runtime vs managed application platform with revisions and autoscaling.
- ACI vs Container Apps: simple isolated execution with explicit resources vs long-running or event-driven app operations with replicas, ingress, revisions, and scale rules.
- Container size vs scale: CPU and memory assigned to a container or replica vs number of replicas responding to demand.
- Container Apps vs App Service: container-centric environment and revision model vs web-app platform centered on App Service plans and apps.
Scenario examples
- Scenario: A scheduled maintenance image should run once and stop without an application platform. Think: Deploy an ACI container group with suitable restart behavior.
- Scenario: An HTTP API needs revisions, traffic splitting, and automatic replica scaling. Think: Deploy it to Azure Container Apps.
- Scenario: Both runtimes must pull an internal image. Think: Store it in ACR and grant each runtime a secure image-pull path.
Exam traps
- Pushing an image to ACR does not deploy a running container.
- Increasing CPU for one container is not horizontal replica scaling.
- ACI is not the better answer merely because the workload uses a container image; operational requirements decide the runtime.
Key takeaways
- Choose image storage independently from the service that runs the image.
- Use ACI for straightforward container groups and Container Apps for application revisions, ingress, and demand-driven replicas.
How it works
- The runtime authenticates to a registry, pulls an immutable image layer set, and starts containers with configured resources and settings.
- Container Apps creates revisions from configuration changes and a scale controller adjusts replicas within configured limits.
Objects and administrative surfaces
- Registry — repositories, image tags or digests, authentication, networking, and retention tasks.
- ACI container group — region, image, resources, restart policy, environment variables, storage, and network exposure.
- Container Apps environment and app — ingress, revisions, replicas, secrets, registry identity, and scale rules.
When to use it
- Use ACI for burst tasks, build agents, or simple services that do not need an application revision and autoscale model.
- Use Container Apps for HTTP or event-driven applications needing managed ingress, revisions, and replica scaling.
Security and governance implications
- Use managed identities for ACR pulls where supported and avoid registry admin credentials in application settings.
- Store secrets in protected settings and restrict public ingress to the endpoints that require it.
How to reason about this
- For image-pull failure, validate registry server, repository and tag, identity role, credentials, firewall, and DNS.
- For scaling failure, inspect rule source, authentication, minimum and maximum replicas, revision health, resource limits, and event availability.
More detail
- Create and manage ACR repositories and deploy images to ACI or Container Apps with the intended resources and environment configuration.
- Configure Container Apps ingress and scale boundaries without drifting into Kubernetes cluster administration.
Ready for the quiz?
- Which resource holds images but never runs them?
- Which runtime fits a short-lived isolated job?
- What makes Container Apps suitable for an autoscaled event-driven service?
Related objectives
- D3.3.S1 — Create and manage an Azure Container Registry
- D3.3.S2 — Provision a container by using Azure Container Instances
- D3.3.S3 — Provision a container by using Azure Container Apps
- D3.3.S4 — Manage sizing and scaling for containers, including Azure Container Instances and Azure Container Apps