This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
   --> Implement container application hosting
      --> Build, store, version, and manage container images by using Azure Container Registry

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Container Registry (ACR) is a managed, private registry service in Azure for storing and managing container images and other OCI-compatible artifacts. It provides a central location from which containerized applications can obtain the images they need to run on services such as Azure App Service, Azure Container Apps, Azure Kubernetes Service (AKS), and Azure Container Instances.

For the AI-200: Developing AI Cloud Solutions on Azure exam, you should understand more than simply how to push an image into ACR. You should be comfortable with the hierarchy of registries, repositories, images, tags, manifests, and layers; image versioning strategies; building images using ACR Tasks; managing and deleting images; and selecting appropriate authentication and registry capabilities.

The current Microsoft Learn study guide specifically identifies this objective as part of Implement container application hosting. It also separately identifies ACR Tasks as an exam objective, so understanding how ACR stores images and how ACR Tasks builds them is particularly important.

1. What Is Azure Container Registry?

Azure Container Registry is a private container registry service hosted in Azure.

A container registry solves a fundamental problem in containerized application development:

Where do applications securely obtain the container images they need to run?

Instead of relying exclusively on a public registry, an organization can maintain its own private registry in Azure.

A typical workflow looks like this:

Developer
    |
    | Build container image
    v
Docker / ACR Tasks
    |
    | Push
    v
Azure Container Registry
    |
    +------------------+
    |                  |
    v                  v
Azure App Service     AKS
    |                  |
    v                  v
Container Apps       Container workloads

ACR provides capabilities for:

• Storing container images
• Storing OCI artifacts
• Organizing images into repositories
• Tagging and versioning images
• Pushing and pulling images
• Building images using ACR Tasks
• Managing image metadata
• Controlling access
• Replicating images across regions
• Integrating with Azure container services

Microsoft describes ACR as a private, managed registry that supports building, storing, and managing images for container deployments.

2. Understand the ACR Hierarchy

One of the most important concepts for AI-200 is understanding how ACR organizes container content.

The hierarchy can be thought of as:

Azure Container Registry
        |
        +-- Repository
        |      |
        |      +-- Image : Tag
        |      +-- Image : Tag
        |      +-- Image : Tag
        |
        +-- Repository
               |
               +-- Image : Tag
               +-- Image : Tag

The important concepts are:

1. Registry
2. Repository
3. Artifact/Image
4. Tag
5. Manifest
6. Layer
7. Digest

Understanding the distinctions between these concepts is a common source of exam questions.

2.1 Registry

The registry is the overall ACR resource.

For example:

contosoregistry.azurecr.io

The registry provides the endpoint through which clients push and pull container images.

A registry can contain many repositories.

2.2 Repository

A repository is a collection of related container images or artifacts.

For example:

contosoregistry.azurecr.io/customer-api

The repository could contain:

customer-api:v1
customer-api:v2
customer-api:v3

Repositories can also use namespaces:

contosoregistry.azurecr.io/marketing/campaign-api:v2

Namespaces help organize repositories logically, although they aren’t independent Azure resources or hierarchical security boundaries simply because they contain / characters.

Microsoft notes that repository names can include namespaces and are managed independently by the registry.

3. Container Image Tags

A tag provides a human-readable identifier for a particular version or variant of an image.

For example:

customer-api:v1
customer-api:v2
customer-api:2026-08-07
customer-api:production

The complete image reference might be:

contosoregistry.azurecr.io/customer-api:v2

The structure is:

<registry>/<repository>:<tag>

For example:

contosoregistry.azurecr.io/customer-api:v2

where:

Microsoft recommends using appropriate tagging strategies for deployment scenarios and notes that latest is used by default when no tag is specified in Docker commands.

4. Tagging and Versioning Strategies

Image versioning is extremely important for reliable deployments.

Consider:

customer-api:latest

This tag is convenient, but it does not necessarily identify an immutable version.

Suppose today’s latest points to:

Image A

and tomorrow the same tag is updated:

latest → Image B

A deployment configured to use latest may therefore receive a different image without its configuration changing.

For production deployments, a better approach is generally to use unique version identifiers.

Examples:

customer-api:v1.0.0
customer-api:v1.1.0
customer-api:v1.2.0

or:

customer-api:20260807.1
customer-api:20260807.2

or a source-control commit identifier:

customer-api:a81f42c

A useful pattern is:

latest       → convenient development/testing reference
v1.4.2       → human-readable release
a81f42c      → unique build identifier

Exam Tip

If a question asks how to ensure that a deployment consistently uses a specific image version, be cautious about answers using:

:latest

A unique tag or, even more strongly, an image digest provides better version specificity.

5. Image Digests

Container images are also identified by a digest.

For example:

contosoregistry.azurecr.io/customer-api@sha256:abc123...

A digest identifies the content associated with a manifest.

Compare:

customer-api:v2

with:

customer-api@sha256:abc123...

A tag can be moved to point to another image.

A digest identifies a specific content-addressed version.

Microsoft specifically notes that pulling by digest guarantees the image version being retrieved even if an identically tagged image is subsequently pushed.

Exam Tip

Remember:

Tag = human-friendly version reference

Digest = content-addressed, precise image reference

6. Container Image Layers

Container images consist of one or more layers.

Dockerfiles commonly create multiple layers.

For example:

FROM python:3.12
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .

The resulting image is composed of layers.

One of the advantages of layers is reuse.

If two images share the same base layers, those layers don’t necessarily have to be independently stored and transferred each time.

This can reduce storage and transfer requirements.

7. Manifests

A container image is associated with a manifest.

The manifest contains information needed to identify the image and its layers.

Conceptually:

Image Manifest
      |
      +-- Configuration
      |
      +-- Layer 1
      +-- Layer 2
      +-- Layer 3

The manifest is also associated with the image’s digest.

This distinction matters when managing images in ACR.

For example, removing a tag doesn’t necessarily mean that all image data is immediately removed.

An untagged manifest and its associated layers may continue to consume storage until they are deleted and no longer referenced.

Microsoft specifically warns that repeatedly pushing modified artifacts with identical tags can create untagged artifacts that continue consuming registry storage.

8. Pushing an Image to ACR

A common workflow is:

Step 1: Build the image

docker build -t customer-api:v1 .

Step 2: Tag the image with the ACR login server

docker tag customer-api:v1 \
    contosoregistry.azurecr.io/customer-api:v1

Step 3: Authenticate to ACR

az acr login --name contosoregistry

Step 4: Push the image

docker push \
    contosoregistry.azurecr.io/customer-api:v1

The image is now stored in:

contosoregistry.azurecr.io/customer-api

with the tag:

v1

9. Pulling an Image

A client can pull the image by tag:

docker pull \
    contosoregistry.azurecr.io/customer-api:v1

Or by digest:

docker pull \
    contosoregistry.azurecr.io/customer-api@sha256:<digest>

The second approach provides stronger guarantees regarding exactly which image content is retrieved.

10. Azure Container Registry Tasks

One of the most important ACR features for AI-200 is ACR Tasks.

ACR Tasks allows container images to be built in Azure rather than requiring the developer to perform the build locally.

Microsoft describes ACR Tasks as a suite of capabilities for building, testing, and managing container images.

For example:

az acr build \
    --registry contosoregistry \
    --image customer-api:v1 \
    --file Dockerfile .

The command:

1. Sends the build context to Azure.
2. Uses the Dockerfile.
3. Builds the image in Azure.
4. Tags the resulting image.
5. Pushes the resulting image into the registry.

This is particularly useful when a developer doesn’t have Docker installed locally.

Microsoft’s current quickstart explicitly demonstrates building, pushing, and running an image using ACR Tasks without requiring a local Docker installation.

11. ACR Tasks Quick Tasks

A quick task is useful for an on-demand image build.

For example:

az acr build \
    --registry contosoregistry \
    --image customer-api:v1 \
    .

This is useful during the development inner loop.

Instead of:

Developer machine
    |
    +-- docker build
    +-- docker tag
    +-- docker push

you can use:

Developer
    |
    | az acr build
    v
Azure
    |
    +-- Build
    +-- Tag
    +-- Push
    v
ACR

12. Automated ACR Tasks

ACR Tasks can also be configured to automatically execute when certain events occur.

For example:

Git commit
     |
     v
ACR Task
     |
     +-- Build image
     +-- Test image
     +-- Push image

ACR Tasks can also respond to base image updates.

For example, suppose an application uses:

FROM python:3.12

A base-image update can trigger an ACR Task to rebuild the application image.

This is useful for keeping application images current when their base images change.

Microsoft documents ACR Tasks triggers for Git commits and base-image updates.

13. Multi-Step ACR Tasks

ACR Tasks can execute more sophisticated workflows.

For example:

Build application image
        |
        v
Run application
        |
        v
Run test container
        |
        v
Push image

Multi-step tasks are defined using YAML.

A simplified example is:

version: v1.1.0
steps:
  - build: -t $Registry/customer-api:$ID .
  - push:
      - $Registry/customer-api:$ID
  - cmd: $Registry/customer-api:$ID

ACR Tasks supports three major step types:

Exam Tip

If a question describes a workflow that needs to build, test, and push multiple containers, think:

ACR Tasks multi-step task

14. ACR Tasks and External Registries

ACR Tasks can also interact with other registries.

For example, a task may need to:

ACR
 |
 +-- Pull base image from another registry
 |
 +-- Build application
 |
 +-- Push application image to ACR

Credentials can be configured for tasks when access to another registry is required.

For more secure scenarios, ACR Tasks can use managed identities to access protected Azure resources without embedding credentials directly in task definitions.

15. Authentication to Azure Container Registry

ACR is generally private, so clients need appropriate authentication and authorization to access it.

Common authentication approaches include:

• Microsoft Entra identities
• Managed identities
• Service principals
• Administrator credentials
• Repository-scoped access mechanisms
• Anonymous pull, where explicitly configured and supported

Microsoft’s documentation emphasizes that ACR operations such as push and pull require authentication unless anonymous pull is enabled.

16. Managed Identity and ACR

Managed identities are particularly important in Azure-native applications.

Suppose an AKS cluster needs to pull an image:

AKS
 |
 | Managed Identity
 v
Azure Container Registry
 |
 v
customer-api:v1

Rather than storing a registry password in application configuration, the Azure resource can use a managed identity and appropriate permissions.

For a non-ABAC-enabled registry, a common pull-only role is:

AcrPull

For push and pull:

AcrPush

For ABAC-enabled registries, Microsoft documents repository-scoped roles such as:

Container Registry Repository Reader
Container Registry Repository Writer

The exact role depends on the registry’s authorization model.

Exam Tip

When the question says:

“An Azure service needs to pull images from ACR without storing credentials.”

Think:

Managed identity + appropriate ACR permissions

17. ACR Pricing Tiers

Azure Container Registry currently provides three pricing tiers:

• Basic
• Standard
• Premium

The tiers provide increasing capacity and capabilities.

All three tiers provide core registry capabilities, while Premium adds advanced capabilities and higher limits.

Important Exam Distinction

If the requirement is:

“Replicate a registry across multiple Azure regions.”

Think:

Premium ACR

Geo-replication is a Premium feature.

18. Geo-Replication

Geo-replication allows an ACR to replicate its content across multiple Azure regions.

For example:

                 Azure Container Registry
                          |
             +------------+------------+
             |                         |
             v                         v
         East US                  West Europe
        Geo-replica               Geo-replica
             |                         |
             v                         v
          AKS US                  AKS Europe

When an image is pushed to the geo-replicated registry, its content is synchronized to the configured replicas.

The advantage is that applications can access images from regions closer to where they run.

Microsoft describes geo-replication as providing a single registry management experience while synchronizing content across selected regions.

Don’t confuse:

Availability zones and geo-replication.

Availability zones provide resilience across zones within a region.

Geo-replication distributes registry content across different Azure regions.

Current Microsoft documentation states that zone redundancy is enabled by default for ACR registries in supported regions across Basic, Standard, and Premium tiers.

19. Managing Images and Repositories

You can manage repositories and images through:

• Azure portal
• Azure CLI
• REST APIs
• SDKs
• Docker/OCI tooling

For example, you can list repositories:

az acr repository list \
    --name contosoregistry \
    --output table

List tags:

az acr repository show-tags \
    --name contosoregistry \
    --repository customer-api \
    --output table

You can also inspect manifests and image metadata.

The Azure portal exposes repositories and their image tags through the registry’s Repositories interface.

20. Deleting Images

Suppose a repository contains:

customer-api:v1
customer-api:v2
customer-api:v3

You can remove an image tag using Azure CLI.

For example:

az acr repository untag \
    --name contosoregistry \
    --image customer-api:v1

However, remember an important distinction:

Untagging an image does not necessarily immediately remove the underlying image data.

The manifest may become untagged while its layers continue consuming storage.

Microsoft specifically warns about the accumulation of untagged artifacts when images are repeatedly pushed using the same tags.

21. Retention of Untagged Manifests

ACR supports a retention policy for untagged manifests.

The purpose is to automatically remove untagged manifests after a configured period.

For example:

Image:v1
Image:v2
Image:v3

If v2 is removed:

Image:v2 → untagged manifest

A retention policy can eventually remove the untagged manifest.

The current Microsoft documentation identifies the untagged-manifest retention policy as a Premium feature and currently documents it as a preview feature. The policy can be configured for a retention period from 0 through 365 days.

Important Warning

If an application relies on pulling an image by its digest, automatically deleting untagged manifests can make that image unavailable.

This is an important operational consideration and a potential exam scenario.

22. Image Tagging Best Practices

A strong production tagging strategy should make image identification predictable.

A useful approach is to use multiple tags for different purposes.

For example:

customer-api:v2.4.1
customer-api:build-1847
customer-api:a81f42c

You might also maintain:

customer-api:production

as a deployment-oriented alias.

However, don’t rely on a mutable tag such as production or latest when you require immutable deployment behavior.

A good pattern is:

Human-readable release
        +
Unique build identifier
        +
Optional environment alias

For example:

customer-api:v2.4.1
customer-api:build-1847
customer-api:production

The production deployment can ultimately be pinned to a specific immutable image reference/digest.

23. Common ACR Mistakes

Mistake 1: Using latest for production deployments

latest can change.

Better: use unique version tags and/or digests.

Mistake 2: Assuming deleting a tag deletes the image immediately

An untagged manifest may continue consuming storage.

Better: understand manifests, layers, untagging, deletion, and retention.

Mistake 3: Giving every workload push permissions

An application that only needs to run an image generally doesn’t need permission to push images.

Better: follow least privilege.

For example:

Application → AcrPull
Build pipeline → AcrPush

Mistake 4: Storing registry passwords in application code

This creates unnecessary credential-management risks.

Better: use managed identities or another appropriate identity mechanism.

Mistake 5: Choosing Premium solely because it sounds better

Premium should be selected because its capabilities are required.

Examples include:

• Geo-replication
• Private endpoints
• Content trust
• Higher throughput
• Advanced networking
• Dedicated Tasks agent pools

Mistake 6: Confusing ACR with ACR Tasks

They are related but different concepts.

ACR:

Stores and manages container images.

ACR Tasks:

Builds, tests, and automates container image workflows.

A single ACR resource can therefore be used to store images while ACR Tasks provides the automation to build those images.

24. Important AI-200 Concepts to Know

For this exam objective, make sure you can explain the following without referring to documentation:

25. AI-200 Scenario Patterns to Recognize

The exam is likely to test your ability to choose the appropriate Azure capability based on a scenario.

Scenario: Build without Docker locally

Requirement: Developers don’t have Docker installed.

Answer: ACR Tasks / az acr build.

Scenario: Automatically rebuild after a Git commit

Requirement: Every source-code commit should trigger an image build.

Answer: ACR Task with a source-code trigger.

Scenario: Rebuild after base image updates

Requirement: Automatically rebuild application images when their base image changes.

Answer: ACR Tasks base-image trigger.

Scenario: Run the same image in several Azure regions

Requirement: Applications in multiple regions should access registry content efficiently.

Answer: ACR Premium with geo-replication.

Scenario: Application only needs to pull images

Requirement: A workload should retrieve images but shouldn’t be able to modify them.

Answer: Grant an appropriate pull-only role, such as AcrPull where applicable, or the appropriate repository reader role for an ABAC-enabled registry.

Scenario: Avoid credentials in application configuration

Requirement: An Azure-hosted application needs to access ACR without storing passwords.

Answer: Managed identity + appropriate registry permissions.

Scenario: Guarantee a specific image

Requirement: A deployment must always retrieve exactly the same image content.

Answer: Use an image digest rather than relying solely on a mutable tag.

26. Quick Review

The following mental model is useful for the exam:

                    AZURE CONTAINER REGISTRY
                             |
             +---------------+---------------+
             |                               |
        Repositories                    ACR Tasks
             |                               |
      +------+------+                  Build/Test/Push
      |             |
   Image          Image
      |             |
    Tags          Tags
      |             |
   Manifest      Manifest
      |
    Layers

And remember the major distinction:

ACR
 ↓
Store/manage images
ACR Tasks
 ↓
Build/test/automate images

For production deployments:

Avoid:
    :latest
Prefer:
    :v2.4.1
    :build-1847
    @sha256:<digest>

For authentication:

Azure workload
      |
      | Managed Identity
      v
     ACR
      |
      | Appropriate least-privilege role
      v
    Pull image

For global deployments:

ACR Premium
     |
     +---- Region 1
     |
     +---- Region 2
     |
     +---- Region 3

Practice Exam Questions

Question 1

A development team has a Dockerfile and wants to build a container image directly in Azure. Developers should not need Docker installed on their local computers. The resulting image should be pushed to Azure Container Registry.

Which Azure capability should you use?

A. Azure Container Registry Tasks

B. Azure App Service deployment slots

C. Azure Container Apps revisions

D. Azure Kubernetes Service Jobs

Answer: A

Explanation: Azure Container Registry Tasks can build container images in Azure using a Dockerfile. The az acr build command provides an on-demand build capability and can push the resulting image to ACR. A local Docker installation isn’t required for this workflow.

Question 2

An application image is stored as:

contosoregistry.azurecr.io/orders:v4

What does v4 represent?

A. The registry name

B. The image tag

C. The image digest

D. The repository namespace

Answer: B

Explanation: In an image reference such as:

registry/repository:tag

the portion after the colon is the tag. Therefore, v4 is the image tag. Tags are commonly used to identify image versions.

Question 3

A production application must always retrieve exactly the same container image content. Developers are concerned that a tag could later be reassigned to a different image.

Which image reference should the application use?

A. :latest

B. :production

C. :stable

D. @sha256:<digest>

Answer: D

Explanation: Tags can be moved to different image versions. A digest is a content-addressed identifier and can be used to pull a specific image version. Microsoft specifically identifies digest-based pulls as a way to guarantee the image version being retrieved.

Question 4

An organization deploys applications to Azure regions in North America and Europe. The organization wants container images to be replicated to both regions while maintaining a single ACR management experience.

Which ACR capability should be used?

A. Repository namespaces

B. Availability zones

C. Geo-replication

D. Image tags

Answer: C

Explanation: ACR geo-replication synchronizes registry content across selected Azure regions while allowing the organization to manage the registry as a single logical registry. Geo-replication is a Premium ACR capability.

Question 5

An AKS workload needs to pull private container images from ACR. The organization does not want to store registry passwords in Kubernetes configuration.

Which approach is most appropriate?

A. Use a managed identity with appropriate ACR permissions

B. Store the ACR administrator password in the container image

C. Make the repository publicly accessible

D. Embed an ACR password in the application source code

Answer: A

Explanation: Azure resources can use managed identities to authenticate to ACR without storing credentials in application code or configuration. The identity must be granted the appropriate pull permissions.

Question 6

A development team wants an automated container workflow that performs the following:

1. Builds an application image.
2. Runs a test container.
3. Builds another image.
4. Pushes the resulting images.

Which ACR capability should the team use?

A. ACR repository namespaces

B. ACR multi-step Tasks

C. ACR geo-replication

D. ACR anonymous pull

Answer: B

Explanation: ACR Tasks supports multi-step workflows using YAML. The workflow can build, run/test, and push one or more images. The available step types include build, push, and cmd.

Question 7

An organization repeatedly pushes new builds using the same image tag. After several months, the registry contains significant amounts of storage that cannot be explained by the currently tagged images.

What is the most likely explanation?

A. ACR automatically creates a new repository for every push

B. Geo-replication is duplicating every image within the same region

C. Previous manifests became untagged while their image data remained in the registry

D. ACR stores every Dockerfile indefinitely

Answer: C

Explanation: Repeatedly pushing modified images using the same tag can result in previous manifests becoming untagged. Their layers can continue consuming registry storage until the underlying content is deleted.

Question 8

A company needs to automatically rebuild its application container whenever a new version of the application’s base container image becomes available.

Which capability should be configured?

A. Azure App Service deployment slots

B. ACR geo-replication

C. ACR repository tagging

D. An ACR Task with a base-image update trigger

Answer: D

Explanation: ACR Tasks can automatically trigger builds when a base image is updated. This is useful for rebuilding application images when their underlying base images change.

Question 9

An organization requires private connectivity to its Azure Container Registry through Azure Private Link. Which ACR pricing tier supports this capability?

A. Premium

B. Basic

C. Standard

D. All three tiers

Answer: A

Explanation: Azure Container Registry Premium supports private endpoints through Private Link. Basic and Standard do not provide this capability according to the current ACR SKU documentation.

Question 10

An administrator removes the v1 tag from an image in an ACR repository. The administrator assumes that the underlying image data has immediately been removed from the registry.

Which statement is correct?

A. Removing a tag always immediately deletes every associated layer

B. Removing a tag converts the image automatically into a public image

C. Removing a tag deletes the entire repository

D. The manifest can become untagged while its data continues consuming storage

Answer: D

Explanation: Removing a tag can leave the manifest untagged while its associated data remains in the registry. Untagged artifacts can continue consuming storage until they are deleted. ACR provides mechanisms such as retention policies for eligible untagged manifests.

Final AI-200 Takeaways

For this particular AI-200 objective, concentrate on these distinctions:

Azure Container Registry

Store and manage container images and artifacts.

ACR repository

Organizes related images.

Tag

Human-readable version/reference that can be reassigned.

Digest

Content-addressed identifier for a specific image version.

Manifest

Describes the image/artifact and its layers.

ACR Tasks

Build, test, and automate container image workflows.

az acr build

Perform an on-demand cloud-based container build.

Multi-step ACR Task

Build/test/push multiple images or perform multi-stage workflows.

Managed identity

Authenticate Azure workloads to ACR without managing passwords.

AcrPull

Pull permission for applicable non-ABAC registry scenarios.

AcrPush

Push/pull permission for applicable non-ABAC registry scenarios.

Premium

Required for capabilities such as geo-replication and private endpoints.

Geo-replication

Replicate registry content across Azure regions.

Retention

Help clean up eligible untagged manifests.

The most important exam mindset is to distinguish where the image is stored, how it is identified, how it is built, and how the workload is authorized to retrieve it. Those four dimensions—registry/repository, tag/digest, ACR Tasks, and authentication/RBAC—cover a large portion of the practical knowledge behind this objective.

Go to the AI-200 Exam Prep Hub main page