ExamFinch.com My Study

Study guide

1.1 ACR: Build, Store, Version & Manage Images

Practice this exam

Exam AI-200: Developing AI Cloud Solutions on Azure Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Audience Profile & Study Path

2 Chapter 1: Container Registry & App Service Hosting

1.1 ACR: Build, Store, Version & Manage Images 1.2 ACR Tasks: Build & Run Images 1.3 Deploy Containers to Azure App Service

3 Chapter 2: Azure Container Apps & KEDA Scaling

2.1 Azure Container Apps: Environments, Config & Revisions 2.2 KEDA Event-Driven Scaling in Container Apps

4 Chapter 3: AKS Manifests & Container Troubleshooting

3.1 Deploy & Manage Apps on AKS with Manifests 3.2 Monitor & Troubleshoot AKS and Container Apps

5 Chapter 4: Cosmos DB for NoSQL Fundamentals

4.1 Cosmos DB for NoSQL: SDK Connect & Queries 4.2 Optimize RUs: Indexing Policies & Consistency Levels

6 Chapter 5: Cosmos DB Vectors & Change Feed

5.1 Embeddings & Vector Similarity Search in Cosmos DB 5.2 Change Feed Processor for New/Updated Items

7 Chapter 6: Azure PostgreSQL Foundations for AI

6.1 Azure Database for PostgreSQL: Connect & Query with SDKs 6.2 Schema Design, Data Types & Indexing Strategies 6.3 pgvector Indexing: Latency & Compute Overhead

8 Chapter 7: PostgreSQL Vector Workloads & RAG

7.1 Configure Compute, Memory & Storage for Vector Workloads 7.2 Vector Search, Semantic Retrieval & RAG with Metadata Filters 7.3 Connection Optimization for Throughput & Latency

9 Chapter 8: Azure Managed Redis for AI Solutions

8.1 Azure Managed Redis: Caching, Expiration & Invalidation 8.2 Redis Vector Indexing for Similarity Search

10 Chapter 9: Service Bus & Event Grid for AI Pipelines

9.1 Service Bus Queues & Message Processing 9.2 Topics, Subscriptions & Dead-Letter Queues 9.3 Event Grid: Custom Events & Filters 9.4 Event Grid Retries & Event-Driven Workflows

11 Chapter 10: Azure Functions for Serverless AI Back Ends

10.1 Azure Functions: Triggers & Bindings 10.2 Build Serverless APIs with Functions 10.3 Configure & Deploy Function Apps

12 Chapter 11: Key Vault & App Configuration

11.1 Azure Key Vault: Secret Storage & Retrieval 11.2 Key Vault Secret Rotation Patterns 11.3 Azure App Configuration for App Settings

13 Chapter 12: OpenTelemetry & KQL Observability

12.1 Distributed Tracing with OpenTelemetry SDKs 12.2 Correlating Traces into Azure Monitoring 12.3 Write KQL Queries to Analyze Logs 12.4 KQL for Metrics & Troubleshooting Scenarios

1.1 ACR: Build, Store, Version & Manage Images

Key Takeaways Explain This Topic AI

Azure Container Registry (ACR) is a managed private Docker registry that stores images for App Service, AKS, Container Apps, and other Azure runtimes

Basic, Standard, and Premium SKUs differ in storage, throughput, and Premium-only features such as geo-replication and customer-managed keys

Image tags are mutable aliases; digests (sha256:...) uniquely identify an immutable image manifest and should be used for production pins

Prefer Azure RBAC and managed identities over the registry admin user for push, pull, and CI/CD authentication

Retention policies, content trust, and repository permissions help you manage image lifecycle and reduce registry sprawl

Last updated: July 2026

Azure Container Registry (ACR) is the private registry most Azure AI and cloud developers use to build, store, version, and manage container images . On the AI-200 exam, ACR sits at the start of the containerized-solutions domain: you push images into ACR, then App Service, Azure Container Apps, or AKS pull those images to run. Treating ACR as a first-class artifact store—not a temporary Docker Hub mirror—keeps deployments repeatable and secure.

Why ACR Exists on Azure

Public registries work for demos, but production AI services need private images, Azure-native identity, and network controls. ACR gives you:

  • A fully managed Docker-compatible registry (OCI images and Helm charts)
  • Integration with Microsoft Entra ID , managed identities, and Azure RBAC
  • Optional private endpoints and firewall rules so images never traverse the public internet

Tight coupling to Azure build and deploy tools (ACR Tasks, App Service continuous deployment, AKS image pull secrets via managed identity)

When an App Service Linux web app is configured for a custom container, the default mental model is: build → push to ACR → App Service pulls the tagged (or digest-pinned) image .

Registry SKUs: Basic, Standard, Premium

ACR ships three service tiers. You choose a SKU when you create the registry; you can change tiers later, but Premium-only features require the Premium tier.

  • SKU Typical use Notable capabilities
  • Basic Dev/test, low throughput Cost-optimized entry tier; limited storage and bandwidth

Standard Most production apps Higher storage and throughput; webhook support; suitable for many App Service and Container Apps workloads

Premium Enterprise / multi-region Geo-replication, zone redundancy options, private link, customer-managed keys, higher limits

Geo-replication (Premium concept)

Geo-replication replicates a Premium registry to additional Azure regions. Pulls from a nearby replica reduce latency and outbound transfer for regional AKS or App Service deployments. From a developer perspective you still push to one registry login server; ACR handles regional replicas behind the scenes. Exam scenarios often contrast a single-region Standard registry (fine for one App Service region) with Premium geo-replication when the same image must be pulled efficiently in multiple regions.

Remember: geo-replication is about image distribution , not about running containers. Compute (App Service, AKS) still runs where you deploy it; ACR replicas simply make the pull faster and more resilient.

Build and Push Images into ACR

You can build images locally with Docker and push them, or build in Azure (covered in the next section on ACR Tasks). A local flow looks like:

Authenticate: az acr login --name <registryName> (or use a service principal / managed identity in CI).

Tag the image with the ACR login server: <registryName>.azurecr.io/<repository>:<tag> .

Push: docker push <registryName>.azurecr.io/<repository>:<tag> .

Repository and naming conventions

Inside a registry, images live in repositories (for example ai-api , embeddings-worker ). Good practice for AI-200-style solutions:

  • One repository per deployable service
  • Tags that encode environment or build metadata ( dev , staging , 1.4.2 , git-abc1234 )
  • Avoid overwriting latest as your only production identifier
  • Versioning: Tags Versus Digests

This distinction appears frequently in Azure container questions.

Tags

A tag is a human-readable pointer to a manifest. Tags are mutable by default: pushing myapi:1.0 again can replace what 1.0 points to. That convenience is dangerous for production rollbacks and audits.

Digests

Every pushed image manifest has a content-addressable digest , typically written as sha256:<hex> . Referencing @sha256:... pins the exact bytes of the image configuration and layers. Even if someone retags v1 , the digest still resolves to the original content.

  • Reference style Example Behavior
  • Tag only contoso.azurecr.io/api:1.2.0 Convenient; may change if retagged
  • Digest contoso.azurecr.io/api@sha256:abc… Immutable pin
  • Tag + digest (some tools) Tag for readability, digest for deploy Best of both for CD pipelines

For App Service and Kubernetes manifests, prefer digest pins (or immutable tags enforced by policy) once a release is validated.

  • Manage Images Day to Day
  • Listing and inspecting

Use Azure CLI or the portal to list repositories, tags, and manifests. Inspecting a manifest shows architecture (amd64/arm64), layers, and created time—useful when debugging “wrong image” incidents after a push.

Retention and cleanup

Registries accumulate failed builds and intermediate tags. Retention policies (available on supported SKUs) can automatically untag or delete old manifests based on age or count. Pair retention with CI naming so you never delete the tag your production App Service still references.

Locking and permissions

Repository-scoped permissions and Azure RBAC roles ( AcrPull , AcrPush , AcrDelete , Owner ) limit who can mutate images.

Avoid enabling the registry admin user long-term; it uses a shared username/password. Prefer managed identities for App Service pull access and workload identities / service principals for pipelines.

Network and security controls

Premium registries support private endpoints , so pull traffic stays on your virtual network. Combine with Entra authentication and disable anonymous pull. For regulated AI workloads, also consider content trust / signed images where your pipeline requires provenance.

Connecting ACR to Downstream Hosts

ACR does not run your app; hosting services pull from it:

App Service : configure the container image URL (and optional continuous deployment webhook from ACR).

Azure Container Apps / AKS : use managed identity or pull secrets with AcrPull .

ACR Tasks : build and optionally run containers using ACR-managed compute (next section).

Exam-focused checklist

When a scenario asks how to store and version images for Azure hosting, map the answer to ACR capabilities:

Choose SKU based on geo-replication / private link needs.

Push to <name>.azurecr.io/repo:tag .

Prefer digests for production.

Authenticate with RBAC + managed identity.

Clean up with retention policies so registries stay manageable.

Mastering ACR image management is the foundation for every later container hosting skill on AI-200: if the wrong image lands in the registry—or the right image is tagged ambiguously—App Service and AKS will happily run the mistake at scale.