Azure Container Registry Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Containers

1. Introduction

Azure Container Registry is Azure’s managed, private registry service for storing and distributing container images and related Open Container Initiative (OCI) artifacts. If your team builds containers, you need a reliable place to push images, control who can pull them, and integrate that registry into CI/CD and runtime platforms like Azure Kubernetes Service (AKS), Azure Container Apps, and Azure Container Instances (ACI).

In simple terms: Azure Container Registry is “private Docker Hub for your organization” hosted in Azure, with Azure Active Directory (Microsoft Entra ID) authentication, Azure networking controls, and integrations with Azure’s container and DevOps ecosystem.

Technically, Azure Container Registry (often abbreviated ACR) is a regional Azure resource that implements the Docker Registry HTTP API v2 / OCI distribution patterns. It supports authenticated push/pull, webhook events, build automation (ACR Tasks), replication options, and enterprise security controls (for example, private connectivity and granular authorization depending on SKU and configuration). You typically place ACR close to your compute to reduce latency and egress costs, and you secure it with Entra ID + Azure RBAC, network restrictions, and auditing.

What problem it solves: It provides a secure, scalable, Azure-native way to store and deliver container artifacts—eliminating reliance on public registries for production workloads, enabling repeatable deployments, and improving governance over what runs in your clusters and container platforms.

2. What is Azure Container Registry?

Official purpose: Azure Container Registry is a managed service for storing and managing container images and OCI artifacts in Azure, with enterprise authentication/authorization and integrations for building and deploying containers. Official documentation: https://learn.microsoft.com/azure/container-registry/

Core capabilities

Private registry for container images (push/pull, tag management, repository organization).
OCI artifact support (container images and other OCI-compliant artifacts). Exact supported artifact types and tooling can evolve—verify in official docs for your scenario.
Authentication and authorization using Microsoft Entra ID (Azure AD) and Azure RBAC; optional registry credentials (admin user) for labs or legacy scenarios.
Automation features such as ACR Tasks for cloud builds and triggers (for example, build on commit, build on base image update, schedule builds).
Integrations with Azure container runtimes (AKS, Container Apps, ACI) and CI/CD systems (GitHub Actions, Azure DevOps, other pipelines).
Networking controls such as private connectivity options and firewall rules (availability can be SKU-dependent—verify in official docs).

Major components (conceptual)

Registry: The top-level ACR resource (e.g., mycompanyacr.azurecr.io) that hosts repositories.
Repositories: Logical groupings of artifacts (e.g., payments/api, platform/nginx).
Tags: Human-friendly pointers to immutable manifests (e.g., 1.4.2, prod, sha-...).
Manifests: Immutable references to image layers and metadata (OCI/Docker manifest).
Layers: The content blobs that make up images.

Service type

Managed PaaS registry service (you don’t manage VMs or storage accounts directly).
API-driven and compatible with standard container tooling (Docker, Podman, Kubernetes, Helm OCI workflows, and other OCI tools—verify tool compatibility for your versions).

Scope and locality

Resource scope: ACR is created in an Azure subscription and resource group.
Region: ACR is a regional Azure resource (you choose a region at creation). Some advanced capabilities (replication, zone redundancy, private features) may vary by region and SKU—verify in official docs.
Endpoint: A registry exposes a login server such as myregistry.azurecr.io.

How it fits into the Azure ecosystem

Azure Container Registry is commonly used as the artifact hub between: – Build systems (GitHub Actions, Azure DevOps, ACR Tasks) that produce images – Security tooling (Microsoft Defender for Cloud plans, policy enforcement, signing strategies—verify current recommendations) – Deployment targets (AKS, Azure Container Apps, ACI, App Service for Containers) – Identity and governance (Microsoft Entra ID, Azure RBAC, Azure Policy, Azure Monitor)

3. Why use Azure Container Registry?

Business reasons

Control and governance: Keep production artifacts in a registry you own and govern, rather than relying on public registries.
Reduced supply-chain risk: Support private distribution, controlled access, and security integrations.
Operational consistency: Standardize how teams publish and consume images across environments (dev/test/prod).

Technical reasons

OCI/Docker compatibility: Works with standard container tools and Kubernetes pull mechanisms.
Azure-native authentication: Integrates with Entra ID and Azure RBAC rather than separate registry accounts.
Regional placement: Put the registry close to compute for performance and predictable network costs.

Operational reasons

CI/CD-friendly: Fits naturally into pipelines; ACR Tasks can offload builds to Azure.
Eventing: Webhooks allow downstream automation on push/pull events.
Monitoring & logs: Integrates with Azure Monitor diagnostics for auditing and troubleshooting.

Security/compliance reasons

Identity-based access: Fine-grained access via Azure RBAC (and potentially additional registry-scoped constructs depending on SKU).
Private networking options: Support restricting exposure so registry traffic stays on private IP space (SKU/region dependent—verify).
Auditing: Diagnostic logs can capture authentication and repository events for investigations and compliance.

Scalability/performance reasons

Managed scaling: Azure operates the service; you select a SKU with performance characteristics appropriate to your workload.
Enterprise features: Premium options like geo-replication (and related capabilities) support multi-region deployments (Premium feature; verify details).

When teams should choose Azure Container Registry

You deploy containers on AKS, Container Apps, or ACI and want Azure-native integration.
You need private image hosting with Entra ID + Azure RBAC and enterprise networking.
You want build automation using ACR Tasks or seamless integration with Azure DevOps/GitHub.

When teams should not choose it

You don’t need private hosting and are satisfied with a public registry for non-sensitive development images.
Your organization is committed to a cross-cloud artifact platform and wants one registry for all clouds (you might prefer a neutral product like Harbor, Artifactory, or a multi-cloud artifact registry strategy).
You require features that may be better served by a broader artifact product (e.g., a universal artifact repository for many package types, not just OCI images/artifacts). In Azure, Azure Artifacts serves different use cases and is not a container registry.

4. Where is Azure Container Registry used?

Industries

SaaS and software: microservices, API platforms, internal developer platforms.
Finance and healthcare: stronger governance, private networking, audit trails.
Retail and media: high deployment frequency and multi-environment pipelines.
Manufacturing/IoT/edge: edge deployments can use patterns like connected registries (where applicable; verify SKU requirements).

Team types

Platform engineering teams building internal container platforms
DevOps and SRE teams managing CI/CD and runtime reliability
Security teams enforcing supply-chain controls
Application teams packaging services as containers

Workloads and architectures

Microservices on AKS
Event-driven apps on Azure Container Apps
Batch or short-lived tasks on Azure Container Instances
Hybrid patterns where images are built in Azure but deployed elsewhere (on-prem Kubernetes)

Real-world deployment contexts

Dev/test: smaller SKUs, fewer retention and replication needs, flexible access for developers.
Production: stronger access controls, private networking, monitoring, retention policies, and multi-region strategies.

5. Top Use Cases and Scenarios

Below are practical scenarios where Azure Container Registry is commonly used in real projects.

1) Private image hosting for AKS

Problem: Public registries add risk, throttling, and access sprawl.
Why ACR fits: Tight AKS integration, Entra ID auth, Azure RBAC, private networking options.
Example: An AKS cluster pulls payments/api:1.9.0 from companyacr.azurecr.io using AcrPull permissions.

2) CI/CD pipeline artifact hub

Problem: Need a consistent place to store artifacts produced by builds.
Why ACR fits: Standard push/pull; integrates with GitHub Actions and Azure DevOps.
Example: GitHub Actions builds on every merge to main and pushes webapp:<git-sha> to ACR; release pipeline deploys by digest.

3) Cloud-based container builds with ACR Tasks

Problem: Developers don’t want to run Docker builds locally; build agents may be constrained.
Why ACR fits: ACR Tasks builds images in Azure; supports triggers.
Example: A task rebuilds an image whenever a base image changes (base image update trigger).

4) Multi-environment promotion (dev → staging → prod)

Problem: Tagging and promoting images consistently is error-prone.
Why ACR fits: One registry with repositories/tags; promotion via immutable digests and controlled permissions.
Example: Only the release pipeline identity can retag :candidate to :prod.

5) Controlled access for partners or vendors

Problem: Need to share a subset of images without giving broad access.
Why ACR fits: You can scope access using RBAC and (depending on SKU) more granular constructs like scope maps/tokens—verify requirements.
Example: External vendor gets pull-only access to partner/* repositories.

6) Internal platform “golden images”

Problem: Teams need secure base images (hardened OS, approved runtime).
Why ACR fits: Central store with policy and security scanning integrations.
Example: Platform team maintains base/dotnet:8-alpine-hardened consumed by all services.

7) Import images from upstream registries

Problem: Need to mirror upstream images to reduce external dependency and improve performance.
Why ACR fits: Import workflows can copy images into ACR (e.g., from Docker Hub or other registries).
Example: Nightly import mirrors nginx:stable into companyacr.azurecr.io/mirror/nginx:stable.

8) Webhook-driven automation

Problem: Need automated actions when images are pushed.
Why ACR fits: Webhooks can notify external systems on push events.
Example: On push to release/*, a webhook triggers a deployment orchestrator.

9) Edge and disconnected scenarios (where supported)

Problem: Remote sites have limited connectivity and need local image distribution.
Why ACR fits: Connected registry patterns can provide local presence (SKU-dependent; verify).
Example: Retail stores sync a subset of images locally to keep deployments fast and resilient.

10) Multi-region deployment performance optimization

Problem: Global applications need fast pulls in multiple regions.
Why ACR fits: Geo-replication (Premium) can replicate content closer to clusters.
Example: AKS clusters in East US and West Europe pull from their nearest ACR replica.

11) Compliance-driven auditing of image access

Problem: Need to know who pulled what and when.
Why ACR fits: Diagnostic logs can capture login and repository events.
Example: Security team queries Log Analytics for pull events during an incident response.

12) Migration from self-hosted Docker Registry

Problem: Maintaining self-hosted registry infrastructure is operationally heavy.
Why ACR fits: Managed service with Azure governance and scaling.
Example: Move from a VM-hosted registry to ACR, then update Kubernetes imagePullSecrets / identities.

6. Core Features

This section focuses on important current capabilities. Some capabilities are SKU- or region-dependent—verify details in official docs for your environment.

Managed private registry (OCI/Docker distribution)

What it does: Stores and serves images and OCI artifacts via standard registry APIs.
Why it matters: Standard tooling works; fewer bespoke integrations.
Practical benefit: Developers can use docker push/docker pull (or Podman) with minimal changes.
Caveats: Throughput/performance and certain advanced features vary by SKU.

Multiple SKUs (Basic / Standard / Premium)

What it does: Provides tiered capacity/performance and advanced capabilities.
Why it matters: Lets you align cost and features with environment needs.
Practical benefit: Use Basic for dev/test; use Premium for multi-region, advanced networking, and enterprise governance.
Caveats: Feature availability (replication, tokens/scope maps, private networking options, retention features) can differ—verify in docs and pricing page.

Microsoft Entra ID authentication + Azure RBAC authorization

What it does: Uses Entra ID identities (users, groups, service principals, managed identities) and Azure RBAC roles like AcrPull / AcrPush.
Why it matters: Central identity governance, conditional access, least privilege.
Practical benefit: AKS/ACI can pull without embedding static passwords if configured with managed identities or cluster integration.
Caveats: Some scenarios still use imagePullSecrets or admin user credentials; avoid for production when possible.

Admin user (username/password) option

What it does: Enables a static credential pair for the registry.
Why it matters: Simple for quick tests and some legacy tooling.
Practical benefit: Fast onboarding for labs.
Caveats: Not recommended for production; harder to rotate and audit; prefer Entra ID and managed identities.

ACR Tasks (cloud builds and automation)

What it does: Builds container images in Azure and can run tasks triggered by commits, base image updates, or schedules.
Why it matters: Offloads build infrastructure; improves reproducibility.
Practical benefit: Build images without installing Docker locally; consistent builds in controlled environment.
Caveats: Task pricing is separate from registry storage; build context size and network access patterns matter. Verify current ACR Tasks billing on pricing page.

Webhooks

What it does: Sends HTTP callbacks on registry events (e.g., push).
Why it matters: Enables event-driven pipelines and integrations.
Practical benefit: Trigger deployments, scans, notifications, or metadata updates.
Caveats: Webhook endpoints must be reachable and secured; consider retries and idempotency.

Geo-replication (Premium)

What it does: Replicates registry content to additional regions for local pulls.
Why it matters: Reduces latency and cross-region egress; improves resilience.
Practical benefit: Multi-region AKS clusters pull from nearest replica.
Caveats: Premium only; replication adds cost and operational considerations (regional availability, failover patterns). Verify in docs.

Private connectivity and network controls

What it does: Options to reduce public exposure (for example, private endpoints) and restrict inbound access (firewall rules).
Why it matters: Registry access is a critical supply-chain path; limiting exposure reduces attack surface.
Practical benefit: AKS nodes pull images over private IP, not public internet.
Caveats: Availability may depend on SKU and region; DNS configuration becomes important with private endpoints.

Import / transfer utilities

What it does: Imports images from other registries into ACR.
Why it matters: Reduces dependency on external registries and stabilizes builds.
Practical benefit: Mirror base images and pin by digest in your own registry.
Caveats: Licensing and usage policies of upstream images still apply.

Retention and cleanup features (SKU-dependent)

What it does: Helps manage storage growth (e.g., retention policies for untagged manifests in some tiers).
Why it matters: Registries can grow quickly in CI-heavy environments.
Practical benefit: Reduce storage cost and clutter.
Caveats: Policies can delete artifacts you still need if tag strategy is weak; test in non-prod first. Verify exact policy options by SKU.

Observability: metrics and diagnostic logs

What it does: Exposes metrics (throughput, storage, etc.) and logs (authentication, repository events) via Azure Monitor.
Why it matters: You need evidence for troubleshooting, auditing, and cost control.
Practical benefit: Alert on unusual pull patterns or auth failures; investigate who pulled a vulnerable image.
Caveats: Storing logs in Log Analytics or Storage has separate costs.

7. Architecture and How It Works

High-level service architecture

At a high level: 1. A developer or CI system authenticates to ACR. 2. The build system pushes an image (layers + manifest) to a repository. 3. A runtime (AKS/Container Apps/ACI) authenticates and pulls the image by tag or digest. 4. Logs and metrics flow to Azure Monitor if diagnostics are enabled.

Request/data/control flow

Control plane: Azure Resource Manager (ARM) manages the ACR resource (create registry, configure networking, enable admin user, manage replications, configure diagnostics).
Data plane: Docker/OCI registry API traffic for pushing/pulling layers and manifests.
Identity: Entra ID issues tokens; Azure RBAC authorizes operations (push/pull/delete depending on role).
Eventing: Webhooks post events to external endpoints (e.g., a deployment service).

Integrations with related Azure services

Common integrations include: – AKS: attach ACR, or grant AcrPull to kubelet identity / managed identity. – Azure Container Apps: pull images from ACR; typically uses managed identity or registry credentials depending on setup. – Azure Container Instances: run a container directly from ACR. – Azure DevOps / GitHub Actions: build and push images. – Azure Key Vault: for customer-managed keys (if enabled/supported) and for pipeline secret management. – Azure Monitor / Log Analytics: store and query logs, create alerts. – Microsoft Defender for Cloud: container registry security posture and vulnerability scanning plans (capabilities and licensing vary—verify in Defender documentation).

Dependency services (conceptual)

Microsoft Entra ID (identity)
Azure Resource Manager (management)
Azure Monitor (observability)
Azure networking (Private Link/private endpoints, DNS, firewalls—where used)

Security/authentication model (practical)

Preferred: Entra ID + Azure RBAC with managed identities for workloads.
Alternative: Service principals for CI/CD (with least privilege and secret rotation).
Fallback/lab: admin user credentials (avoid for production).

Networking model (practical)

Default: public registry endpoint protected by auth.
Hardened: limit access via firewall rules and/or use private endpoints (where supported), then ensure private DNS resolution for *.azurecr.io (and any relevant data endpoints depending on your configuration).

Monitoring/logging/governance considerations

Enable diagnostic settings to send logs to Log Analytics for:
authentication/login events
repository events (push/pull/delete)
Add Azure Policy guardrails:
enforce private endpoints (where required)
enforce tags and naming conventions
restrict creation to approved regions/SKUs

Simple architecture diagram (Mermaid)

flowchart LR
  Dev[Developer or CI] -->|docker push| ACR[Azure Container Registry]
  ACR -->|docker pull| Runtime[AKS / Container Apps / ACI]
  Dev -->|Entra ID auth| Entra[Microsoft Entra ID]
  Runtime -->|Entra ID token| Entra

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph DevSecOps
    Code[Git repo] --> Pipeline[CI Pipeline\n(GitHub Actions/Azure DevOps)]
    Pipeline -->|Build & push| ACR[(Azure Container Registry)]
    ACR --> Webhook[Webhook to CD/Automation]
  end

  subgraph Security
    Defender[Microsoft Defender for Cloud\n(Container Registry plan)\nVerify capabilities] --> ACR
    Policy[Azure Policy] --> ACR
    Logs[Azure Monitor + Log Analytics] <-->|Diagnostics| ACR
  end

  subgraph Network
    PE[Private Endpoint\n(if enabled)] --- ACR
    DNS[Private DNS Zone] --- PE
  end

  subgraph Runtime
    AKS1[AKS Cluster - Region A] -->|Pull by digest| ACR
    AKS2[AKS Cluster - Region B] -->|Pull from replica| ACR
  end

8. Prerequisites

Azure account and subscription

An active Azure subscription with billing enabled.
Permission to create resources in a resource group.

Permissions / IAM roles

You typically need one of: – Owner or Contributor on the subscription/resource group to create the registry, or – Fine-grained permissions to create Microsoft.ContainerRegistry/registries.

For pushing/pulling images: – Use built-in roles: – AcrPull: pull images – AcrPush: push/pull images – Owner/Contributor: includes broader rights (avoid granting broadly in production)

Tools

Choose one of these environments: – Azure Cloud Shell (has Azure CLI; Docker may not be available) – Local machine: – Azure CLI (az) – https://learn.microsoft.com/cli/azure/install-azure-cli – Docker Desktop or Docker Engine, or Podman – Optional: kubectl (if integrating with AKS), Git

Region availability

ACR is available in many Azure regions. Advanced capabilities (geo-replication, zone redundancy, some networking features) can vary by region and SKU. Verify in official docs:
https://learn.microsoft.com/azure/container-registry/

Quotas and limits (high level)

Registry name must be globally unique (under *.azurecr.io) and follow naming rules.
Throughput, storage, webhook limits, and replication limits depend on SKU. Check the current limits page in official docs before production rollout.

Prerequisite services (for this lab)

A resource group
Azure Container Registry
Docker/Podman locally (recommended for the hands-on steps below)
Optional for “run it” verification: Azure Container Instances

9. Pricing / Cost

Azure Container Registry pricing is SKU-based plus usage-based. Exact prices vary by region, SKU, and sometimes by feature usage. Always validate with: – Official pricing page: https://azure.microsoft.com/pricing/details/container-registry/ – Azure Pricing Calculator: https://azure.microsoft.com/pricing/calculator/

Pricing dimensions (typical)

Common cost components include: 1. Registry SKU (Basic / Standard / Premium) – Determines included capabilities and performance profile. 2. Storage – Stored image layers/manifests consume storage over time. – CI systems can create many tags/digests; storage growth is a primary driver. 3. Data transfer – Pulling images across regions or to the internet can incur egress costs. – Pulling from ACR to compute in the same region can be cheaper than cross-region pulls (depending on your architecture). 4. Build automation (ACR Tasks) – If you use ACR Tasks, builds are billed separately based on the tasks pricing model (compute time/resources). Verify current billing details on the pricing page. 5. Premium features that scale with usage – Geo-replication adds additional regional replicas (additional cost). – Private networking features themselves may not be priced as “ACR add-ons,” but they can create costs in dependent services (e.g., Private Endpoint and Private DNS, plus network processing). Verify current Private Link pricing in Azure networking docs.

Free tier?

ACR generally does not present as a “free tier” in the same way as some services; however, new Azure accounts sometimes have credits or free offers that can offset early usage. Verify current Azure free offerings: https://azure.microsoft.com/free/

Cost drivers (what actually moves your bill)

Number and size of images (multi-arch images, large base layers, debug symbols)
CI frequency and tag strategy (e.g., tagging every commit without retention)
Cross-region pulls (multi-region AKS pulling from a single region)
Geo-replication count (Premium)
Task build frequency and build context sizes (ACR Tasks)

Hidden/indirect costs

Log Analytics ingestion for diagnostic logs (can be significant at high pull/push volume).
Networking: egress, Private Link, DNS queries (usually small, but can add up).
Security scanning: Microsoft Defender for Cloud plans are billed separately.
Developer tooling: build agents, runners, and storage for pipeline artifacts.

How to optimize cost

Keep registry and compute in the same region when possible.
Prefer small base images and multi-stage builds.
Implement a tagging and retention strategy:
Keep immutable release tags
Clean up ephemeral CI tags
Consider SKU features for retention policies (verify availability)
Use image digests for deployments to avoid accidental re-pulls of mutated tags.
If multi-region: evaluate geo-replication vs. cross-region pulls and egress.

Example low-cost starter estimate (no fabricated numbers)

A low-cost dev/test setup usually looks like: – One Basic registry – Minimal image set (a few services) – No geo-replication – Limited diagnostic logging (or short retention)

To estimate: 1. Pick your region and SKU on the official pricing page. 2. Estimate storage: total GB stored (images + tags you keep). 3. Estimate pulls/pushes and egress if any. 4. Add ACR Tasks if you use them.

Example production cost considerations

Production environments commonly add: – Standard or Premium SKU – Private networking – Geo-replication (Premium) for multi-region clusters – Diagnostic logs to Log Analytics with retention policies – Defender for Cloud plans

In production, the biggest surprises are often: – Unbounded registry storage due to CI tags – Cross-region or internet egress due to topology – Log Analytics ingestion volumes

10. Step-by-Step Hands-On Tutorial

Objective

Create an Azure Container Registry, build a container image, push it to Azure Container Registry, then pull and run it to confirm end-to-end functionality. Optionally, run it in Azure Container Instances to validate registry-to-runtime integration.

Lab Overview

You will: 1. Create a resource group and an Azure Container Registry (Basic). 2. Authenticate to the registry using Entra ID (az acr login). 3. Build a small container image locally (or adapt to ACR Tasks if you prefer). 4. Tag and push the image to Azure Container Registry. 5. Verify the repository and tags in ACR. 6. (Optional) Run the container in Azure Container Instances using registry credentials. 7. Clean up all resources.

Expected cost: Low for a short lab, but not zero. Storage and any ACI runtime minutes will incur charges. Always delete resources when finished.

Step 1: Set variables and create a resource group

On your machine (or Cloud Shell), sign in:

az login
az account show

Set variables (adjust region as needed):

RG="rg-acr-lab"
LOCATION="eastus"
ACR_NAME="acr$(date +%s)"   # makes a mostly-unique name; must be globally unique

Create the resource group:

az group create --name "$RG" --location "$LOCATION"

Expected outcome: A resource group exists in your chosen region.

Verify:

az group show --name "$RG" --query "{name:name, location:location}" -o table

Step 2: Create Azure Container Registry (Basic)

Create the registry:

az acr create \
  --resource-group "$RG" \
  --name "$ACR_NAME" \
  --sku Basic \
  --admin-enabled false

Expected outcome: ACR is created and ready to accept pushes.

Verify:

az acr show --resource-group "$RG" --name "$ACR_NAME" \
  --query "{name:name, loginServer:loginServer, sku:sku.name, provisioningState:provisioningState}" -o table

Capture the login server:

LOGIN_SERVER="$(az acr show -g "$RG" -n "$ACR_NAME" --query loginServer -o tsv)"
echo "$LOGIN_SERVER"

Step 3: Authenticate to Azure Container Registry

az acr login --name "$ACR_NAME"

Expected outcome: Your Docker/Podman client can authenticate to the registry.

Verification idea (Docker):

docker logout "$LOGIN_SERVER" 2>/dev/null || true
az acr login --name "$ACR_NAME"

If you use Podman, you can often login with:

podman login "$LOGIN_SERVER"

(If Podman prompts for username/password, you may need to use an access token or admin credentials. Behavior varies by client version. Verify in official docs if needed.)

Step 4: Build a small container image locally

Create a working folder:

mkdir acr-lab && cd acr-lab

Create a tiny web app using NGINX and a static page.

Create index.html:

cat > index.html <<'EOF'
<!doctype html>
<html>
  <head><meta charset="utf-8"><title>ACR Lab</title></head>
  <body>
    <h1>Hello from Azure Container Registry</h1>
    <p>If you can read this, your image build/push/pull worked.</p>
  </body>
</html>
EOF

Create Dockerfile:

FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html

Build:

IMAGE_REPO="samples/hello-acr"
IMAGE_TAG="v1"
docker build -t "${IMAGE_REPO}:${IMAGE_TAG}" .

Expected outcome: A local image exists.

Verify:

docker images | head
docker inspect "${IMAGE_REPO}:${IMAGE_TAG}" --format='{{.Id}}'

Step 5: Tag and push the image to Azure Container Registry

Tag the image with your ACR login server:

docker tag "${IMAGE_REPO}:${IMAGE_TAG}" "${LOGIN_SERVER}/${IMAGE_REPO}:${IMAGE_TAG}"

Push:

docker push "${LOGIN_SERVER}/${IMAGE_REPO}:${IMAGE_TAG}"

Expected outcome: The image is uploaded to Azure Container Registry.

Verify in ACR:

az acr repository list --name "$ACR_NAME" -o table
az acr repository show-tags --name "$ACR_NAME" --repository "$IMAGE_REPO" -o table

You can also view manifests (useful for digest-based deployments):

az acr repository show-manifests --name "$ACR_NAME" --repository "$IMAGE_REPO" -o table

Step 6 (Optional but recommended): Pull from ACR and run locally

Remove your local tagged copy to prove it pulls from ACR:

docker rmi "${LOGIN_SERVER}/${IMAGE_REPO}:${IMAGE_TAG}" || true
docker pull "${LOGIN_SERVER}/${IMAGE_REPO}:${IMAGE_TAG}"

Run it:

docker run --rm -d -p 8080:80 --name hello-acr "${LOGIN_SERVER}/${IMAGE_REPO}:${IMAGE_TAG}"

Test:

curl -i http://localhost:8080 | head -n 20

Stop:

docker stop hello-acr

Expected outcome: You see an HTTP 200 response and your “Hello from Azure Container Registry” page.

Step 7 (Optional): Run the image in Azure Container Instances (ACI)

This demonstrates a managed runtime pulling from ACR. For a simple lab, the fastest path is to enable the ACR admin user temporarily (not recommended for production).

Enable admin user:

az acr update --name "$ACR_NAME" --admin-enabled true

Fetch credentials:

ACR_USER="$(az acr credential show -n "$ACR_NAME" --query username -o tsv)"
ACR_PASS="$(az acr credential show -n "$ACR_NAME" --query passwords[0].value -o tsv)"

Create a container group:

ACI_NAME="aci-hello-acr"
DNS_LABEL="helloacr$RANDOM"

az container create \
  --resource-group "$RG" \
  --name "$ACI_NAME" \
  --image "${LOGIN_SERVER}/${IMAGE_REPO}:${IMAGE_TAG}" \
  --registry-login-server "$LOGIN_SERVER" \
  --registry-username "$ACR_USER" \
  --registry-password "$ACR_PASS" \
  --dns-name-label "$DNS_LABEL" \
  --ports 80

Get its FQDN:

FQDN="$(az container show -g "$RG" -n "$ACI_NAME" --query ipAddress.fqdn -o tsv)"
echo "http://$FQDN"

Test:

curl -i "http://$FQDN" | head -n 20

Expected outcome: The ACI instance serves the same HTML page, proving ACI can pull from your ACR.

Security note: After the test, disable admin user again:

az acr update --name "$ACR_NAME" --admin-enabled false

A production approach would use managed identity and AcrPull role assignment where supported—verify current ACI + ACR identity features in official docs.

Validation

Use this checklist: – az acr show returns your registry and login server. – az acr repository list shows samples/hello-acr. – az acr repository show-tags shows v1. – docker pull <loginServer>/samples/hello-acr:v1 succeeds. – (Optional) ACI endpoint returns HTTP 200 and the expected content.

Troubleshooting

Problem: `az acr login` succeeds but `docker push` fails with unauthorized

Common causes: – Docker is using a different credential store context than expected. – You are signed into the wrong Azure subscription/tenant.

Fixes:

az account show -o table
az account set --subscription "<your-subscription-id>"
az acr login --name "$ACR_NAME"
docker logout "$LOGIN_SERVER"
az acr login --name "$ACR_NAME"

Problem: Registry name is not available

ACR names must be globally unique. – Choose another name and re-run creation. – Avoid uppercase and special characters.

Problem: ACI fails to pull image

Common causes: – Wrong registry server, username, or password. – Image name mismatch (repository path differs).

Fix: – Confirm image exists: bash az acr repository list --name "$ACR_NAME" -o table – Confirm exact image reference: bash echo "${LOGIN_SERVER}/${IMAGE_REPO}:${IMAGE_TAG}" – Check ACI events/logs: bash az container logs -g "$RG" -n "$ACI_NAME" az container show -g "$RG" -n "$ACI_NAME" --query instanceView.events -o table

Problem: `curl` to ACI FQDN times out

The container group may still be provisioning.
Corporate firewall might block outbound HTTP.

Fix: – Wait and retry. – Check the IP and FQDN: bash az container show -g "$RG" -n "$ACI_NAME" --query ipAddress -o json

Cleanup

Delete the resource group (removes registry and optional ACI):

az group delete --name "$RG" --yes --no-wait

If you created local files, delete them:

cd .. && rm -rf acr-lab

11. Best Practices

Architecture best practices

Keep registry close to compute (same region as AKS/Container Apps) to reduce latency and egress.
Use digest-based deployments in production (image@sha256:...) to guarantee immutability.
For multi-region apps:
Consider geo-replication (Premium) to avoid cross-region pulls.
Design failover patterns intentionally (verify replica behavior and operational procedures).

IAM/security best practices

Prefer managed identities for Azure-hosted runtimes.
For CI/CD:
Use a dedicated service principal with AcrPush to specific registries.
Store secrets in Azure Key Vault or GitHub/Azure DevOps secret stores.
Rotate credentials and limit scope.
Avoid enabling admin user in production.
Use least privilege: runtime should typically have AcrPull only.

Cost best practices

Implement retention policies (where supported) and delete unused tags regularly.
Avoid storing large, duplicate images:
Use shared base images
Use multi-stage builds
Control log volume:
Enable diagnostics intentionally
Apply Log Analytics retention policies

Performance best practices

Use smaller images; remove build-time dependencies.
Keep pull paths short and avoid unnecessary layers.
Consider Premium throughput for heavy CI/CD and high pull volume.

Reliability best practices

Treat your registry as a critical dependency in your delivery chain.
Document recovery steps:
Rebuild images from source if needed
Mirror critical base images
For mission-critical workloads, evaluate multi-region strategies (Premium geo-replication).

Operations best practices

Enable diagnostic settings and create alerts for:
spikes in 401/403 (auth failures)
unusual pull volumes
Standardize naming:
Registry: acr-<org>-<env>-<region>
Repos: <domain>/<service>
Tags: semantic version + git SHA, avoid mutable latest in production

Governance/tagging/naming best practices

Apply Azure tags to the registry resource:
env=dev|staging|prod
costCenter=...
owner=...
Use Azure Policy (where appropriate) to enforce:
approved SKUs
private access requirements
diagnostic settings enabled

12. Security Considerations

Identity and access model

Entra ID + Azure RBAC is the recommended model.
Common roles:
AcrPull for runtime
AcrPush for build pipelines
Consider separating registries by environment (dev/prod) to reduce blast radius.

Encryption

In transit: TLS is used for registry traffic.
At rest: ACR data is encrypted at rest by Azure. Options such as customer-managed keys may be available depending on SKU/region—verify in official docs.

Network exposure

Default registry endpoints are reachable publicly but require auth.
For stricter postures:
Use private endpoints (where supported) and restrict public network access.
Ensure DNS is correct (private DNS zones/records).
Use firewall rules where applicable.

Secrets handling

Avoid embedding registry passwords in:
container images
source code
Kubernetes manifests checked into Git
Prefer:
managed identity pulls
workload identity patterns (AKS) where applicable
secret stores (Key Vault, external secrets operators) when static creds are unavoidable

Audit/logging

Enable diagnostic logs to capture:
login/auth events
repository events
Route to Log Analytics for query and alerting.

Compliance considerations

ACR supports common enterprise controls (identity, logging, network restriction).
Your compliance requirements may require:
private networking
key management policies
data residency constraints (region choice)
retention requirements for logs
Validate against the latest Azure compliance documentation and ACR docs.

Common security mistakes

Leaving admin user enabled permanently.
Using a shared service principal across many pipelines and environments.
Allowing broad Owner/Contributor access when AcrPull/AcrPush is enough.
Deploying with mutable tags like latest (hard to audit what actually ran).
No logging/diagnostics, making incident response difficult.

Secure deployment recommendations

Use separate registries for prod vs non-prod, or at least separate repos with strict permissions.
Require:
private endpoints (where mandated)
least privilege roles
immutable tagging strategy + digest pinning
Integrate with supply-chain controls:
vulnerability scanning via Defender for Cloud (licensed separately)
image signing strategy (verify current recommended tooling for ACR and OCI signing)

13. Limitations and Gotchas

Limits and feature availability can change. Confirm current behavior in official docs before production decisions.

SKU feature differences: Premium-only features (e.g., geo-replication) are common; some auth/networking granularity may also depend on SKU.
Name constraints: Registry name must be globally unique and follow strict naming rules.
Tag sprawl: CI pipelines can create thousands of tags quickly, increasing storage and making cleanup hard.
Mutable tags: Using latest (or reusing a version tag) causes drift and breaks auditability.
Cross-region pulls: Pulling images from a registry in another region can add latency and data transfer cost.
Private endpoint DNS complexity: Private connectivity requires correct DNS resolution; misconfiguration leads to pull failures that look like auth errors.
Tooling version mismatches: Older Docker/Helm/OCI tooling may not support newer artifact patterns; verify tool versions.
Logging cost: Diagnostic logs to Log Analytics can be surprisingly expensive at scale.
Deletion semantics: Image deletion affects tags/manifests; understand digest references so you don’t break rollbacks.

14. Comparison with Alternatives

Azure Container Registry is Azure-native, but there are good alternatives depending on your cloud, compliance posture, and ecosystem.

Options to consider

Within Azure
Azure Container Registry (this service) is the main managed container registry.
GitHub Container Registry (GHCR) is common for GitHub-centric workflows (not an Azure resource).
Other clouds
Amazon Elastic Container Registry (ECR)
Google Artifact Registry
Self-managed / third-party
Harbor
JFrog Artifactory
Sonatype Nexus Repository
Self-hosted Docker Registry (generally not recommended for most teams unless necessary)

Option	Best For	Strengths	Weaknesses	When to Choose
Azure Container Registry	Azure-hosted container platforms	Entra ID + Azure RBAC, Azure networking, AKS integration, managed service	Azure-specific governance and patterns; some features SKU-dependent	You run containers on Azure and want native integration
GitHub Container Registry (GHCR)	GitHub-first teams	Tight GitHub integration, repo-scoped permissions	Not Azure-native; different enterprise controls model	You build/deploy from GitHub and want registry near code
Amazon ECR	AWS workloads	Deep AWS IAM integration, strong AWS ecosystem fit	Cross-cloud complexity if you’re on Azure	Your workloads are primarily on AWS
Google Artifact Registry	GCP workloads	Supports multiple artifact types, GCP integration	Cross-cloud complexity if you’re on Azure	Your workloads are primarily on GCP
Harbor (self-managed)	Regulated or hybrid environments	Full control, can run anywhere, rich policy features	You operate and patch it; scaling/HA is your job	You need on-prem control or strict isolation
JFrog Artifactory / Nexus	Enterprises needing many artifact types	Multi-format artifact management	Licensing cost; operational complexity	You want one platform for containers + many package types

15. Real-World Example

Enterprise example: multi-region AKS platform with strict security

Problem: A global enterprise runs multiple AKS clusters across regions. They need private image distribution, audit trails, and consistent release promotion. They also need resilient pulls and controlled access across many teams.
Proposed architecture:
Azure Container Registry (Premium) in a primary region
Geo-replication to secondary regions used by AKS clusters
Private endpoints and restricted public access (where required)
Entra ID groups mapped to Azure RBAC roles:
- Platform pipeline identity: AcrPush
- Runtime identities: AcrPull
Diagnostic logs to Log Analytics + alerts
Defender for Cloud plan for container registry scanning (licensed separately; verify exact capabilities)
Why ACR was chosen: Native AKS integration, Azure RBAC governance, and enterprise networking controls fit the organization’s standards.
Expected outcomes:
Faster pulls across regions
Reduced supply-chain exposure
Clear audit logs for compliance
Standardized release promotion using immutable digests

Startup/small-team example: simple CI to ACR for Container Apps

Problem: A small team needs private images for a containerized API without managing infrastructure.
Proposed architecture:
One Azure Container Registry (Basic or Standard depending on needs)
GitHub Actions builds and pushes images on merge to main
Azure Container Apps pulls images for staging and production
Simple cleanup job to remove old CI tags
Why ACR was chosen: Lowest operational overhead inside Azure; good fit for a small team already using Azure.
Expected outcomes:
Repeatable deployments from a trusted registry
Minimal ops burden
Clear path to Premium features if the product scales globally

16. FAQ

1) Is Azure Container Registry the same as Docker Hub?
No. Docker Hub is a public registry service. Azure Container Registry is a managed private registry in Azure, designed for enterprise identity, networking, and Azure integrations.

2) What can I store in Azure Container Registry?
Primarily container images and OCI artifacts supported by ACR and your tools. For exact artifact support and recommended tooling, verify the current official docs: https://learn.microsoft.com/azure/container-registry/

3) Do I need AKS to use Azure Container Registry?
No. You can use ACR with many runtimes: AKS, Azure Container Apps, Azure Container Instances, App Service for Containers, or even non-Azure Kubernetes.

4) How do I control who can pull images?
Use Azure RBAC with roles like AcrPull assigned to users, groups, service principals, or managed identities at the registry scope (or narrower scopes where supported).

5) Should I enable the admin user?
For production, typically no. Use Entra ID + Azure RBAC and managed identities. Admin user is convenient for labs or legacy tooling but increases risk.

6) What’s the difference between Basic, Standard, and Premium?
They differ in performance and available features (for example, geo-replication is Premium). Always compare using the official pricing and feature documentation.

7) How do I reduce image pull latency for multi-region clusters?
Consider geo-replication (Premium) or place registries closer to compute. Also use smaller images and stable layers.

8) Can I restrict registry access to private networks only?
ACR supports private connectivity patterns (e.g., private endpoints), but availability and exact configuration can be SKU/region dependent. Verify current docs and test DNS behavior.

9) How do I delete old images safely?
Adopt a tag strategy: – Keep release tags (and/or pin by digest) – Remove ephemeral CI tags – Use retention policies if available in your SKU (verify) Test cleanup in non-prod first.

10) Can ACR build images without Docker on my laptop?
Yes, via ACR Tasks (cloud builds). Verify current ACR Tasks features and billing in official docs.

11) How do I integrate ACR with GitHub Actions?
Authenticate to Azure (OIDC recommended) and then docker build + docker push to the ACR login server. Microsoft has official GitHub Actions for Azure login—verify current recommended workflow in GitHub/Microsoft docs.

12) Does ACR scan images for vulnerabilities by default?
ACR itself is a registry. Vulnerability scanning typically comes from Microsoft Defender for Cloud plans or third-party tools. Verify the current Defender capabilities and licensing.

13) Is it okay to deploy using the latest tag?
Avoid it in production. Use immutable version tags and/or deploy by digest to ensure the exact artifact is deployed.

14) How do I troubleshoot unauthorized pull errors in Kubernetes?
Check: – The identity used by nodes/workloads – RBAC role assignments (AcrPull) – If using imagePullSecrets, confirm credentials – Network/DNS if private endpoints are in use

15) Can I mirror upstream images into ACR?
Yes, using import capabilities and/or pipeline workflows. Ensure you respect upstream licensing and keep track of digests for reproducibility.

16) What logs should I enable for auditing?
Enable ACR diagnostic logs to Log Analytics for login/auth events and repository events, then create alerts for anomalies.

17) How do I estimate ACR cost?
Use the official pricing page and calculator: – https://azure.microsoft.com/pricing/details/container-registry/ – https://azure.microsoft.com/pricing/calculator/
Estimate SKU + stored GB + pull/push patterns + optional tasks and logs.

17. Top Online Resources to Learn Azure Container Registry

Resource Type	Name	Why It Is Useful
Official documentation	Azure Container Registry documentation	Canonical reference for features, auth, networking, tasks, and operations: https://learn.microsoft.com/azure/container-registry/
Official quickstart	Quickstart: Create a private container registry using the Azure CLI	Step-by-step creation and push/pull patterns (official): https://learn.microsoft.com/azure/container-registry/container-registry-get-started-azure-cli
Official concepts	About registries, repositories, and images	Clarifies core concepts and terminology: https://learn.microsoft.com/azure/container-registry/container-registry-concepts
Official how-to	ACR authentication options	Explains Entra ID integration, service principals, and admin user: https://learn.microsoft.com/azure/container-registry/container-registry-authentication
Official how-to	Azure Container Registry Tasks	Cloud builds, triggers, and automation: https://learn.microsoft.com/azure/container-registry/container-registry-tasks-overview
Official how-to	Geo-replication (Premium)	Multi-region replication details and constraints: https://learn.microsoft.com/azure/container-registry/container-registry-geo-replication
Official how-to	Private Link / private endpoints for ACR	Secure networking patterns and DNS considerations (verify SKU requirements): https://learn.microsoft.com/azure/container-registry/container-registry-private-link
Official monitoring	Monitor Azure Container Registry	Metrics, logs, and diagnostic settings: https://learn.microsoft.com/azure/container-registry/monitor-container-registry
Official pricing	Azure Container Registry pricing	SKU and usage pricing details: https://azure.microsoft.com/pricing/details/container-registry/
Pricing tool	Azure Pricing Calculator	Build scenario-based estimates: https://azure.microsoft.com/pricing/calculator/
Architecture guidance	Azure Architecture Center (Containers)	Broader container architecture patterns: https://learn.microsoft.com/azure/architecture/guide/architecture-styles/microservices
Official samples	Azure Container Registry samples (GitHub search starting point)	Practical scripts and examples (verify repository authenticity): https://github.com/Azure-Samples
Community learning	Kubernetes image management best practices	Helps with tagging/digests, rollout patterns, and pull secrets; validate against your cluster/runtime versions

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	CI/CD, containers, Kubernetes, Azure DevOps practices	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate DevOps learners	SCM, CI/CD foundations, DevOps toolchains	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers, operations teams	Cloud operations, monitoring, reliability practices	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, operations engineers	SRE principles, observability, incident response	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops and DevOps teams exploring AIOps	Automation, AIOps concepts, operational analytics	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps / cloud training content (verify offerings)	Engineers seeking hands-on guidance	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training and mentoring (verify offerings)	Beginners to intermediate DevOps practitioners	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps consulting/training platform (verify offerings)	Teams needing practical enablement	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and training resources (verify offerings)	Ops/DevOps teams needing troubleshooting help	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify service catalog)	Architecture, CI/CD, container platforms	ACR + AKS design, CI pipeline hardening, migration from self-hosted registry	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and enablement	DevOps transformation, platform enablement	ACR governance model, build/push standards, multi-team onboarding	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting services (verify service catalog)	Assessments, implementations, operations	Secure ACR setup, private networking patterns, monitoring and cost optimization	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Azure Container Registry

Containers fundamentals
Dockerfile basics, image layers, registries, tags vs digests
Linux basics
Processes, ports, filesystems (helps with container debugging)
Azure fundamentals
Subscriptions, resource groups, IAM (Azure RBAC), networking basics
Git + CI/CD basics
pipelines, secrets, artifacts, environments

What to learn after Azure Container Registry

Azure Kubernetes Service (AKS)
attaching ACR, workload identity patterns, image pull strategies
Azure Container Apps
revisions, traffic splitting, managed identity pulls
Supply-chain security
vulnerability scanning, SBOM concepts, signing/verification (verify current recommended tooling for ACR)
Observability
Azure Monitor, Log Analytics queries, alerting on registry and runtime signals

Job roles that use it

DevOps Engineer
Platform Engineer
Site Reliability Engineer (SRE)
Cloud Engineer
Security Engineer (container security)
Software Engineer (microservices)

Certification path (Azure)

ACR appears within broader Azure and Kubernetes learning paths rather than as a standalone certification topic. Relevant certification tracks often include: – AZ-104 (Azure Administrator) – AZ-305 (Azure Solutions Architect) – AZ-400 (DevOps Engineer Expert) – Kubernetes-related certifications (CNCF) can complement Azure container platform skills

Verify current certification details on Microsoft Learn: https://learn.microsoft.com/credentials/

Project ideas for practice

Build a CI pipeline that pushes images to ACR with semantic tags and git SHA tags.
Deploy to AKS using digest pinning and validate rollbacks.
Implement retention and cleanup automation (scripted cleanup + approvals).
Enable diagnostic logs and build a Log Analytics dashboard for pull/push and auth failures.
Implement private endpoints and validate DNS + network paths from AKS node pools.

22. Glossary

ACR: Azure Container Registry.
OCI: Open Container Initiative; defines standards for container image formats and distribution.
Repository: A named collection of related artifacts/images inside a registry (e.g., team/service).
Tag: A mutable label pointing to a specific image manifest (e.g., v1.2.0).
Digest: Immutable cryptographic identifier of an image manifest (e.g., sha256:...).
Manifest: Metadata describing an image and its layers.
Layer: A filesystem diff stored as a blob; images consist of multiple layers.
AcrPull/AcrPush: Azure RBAC roles granting pull-only or push+pull permissions.
Managed identity: Azure identity for services to authenticate without stored secrets.
Private endpoint (Private Link): Private IP interface to an Azure PaaS service.
Geo-replication: Replicating registry content to other Azure regions (typically Premium).
Retention policy: Rules that automatically delete artifacts based on criteria (availability depends on SKU and feature support).
CI/CD: Continuous Integration / Continuous Delivery or Deployment.
Image promotion: Process of moving an image through environments (dev → staging → prod), ideally by digest.

23. Summary

Azure Container Registry is Azure’s managed private registry for container images and OCI artifacts. It matters because it sits on the critical path between building software and running it—so it needs strong identity, auditing, networking, and operational controls.

In Azure container architectures, Azure Container Registry is typically the central artifact store feeding AKS, Container Apps, and other runtimes. Cost is primarily driven by SKU selection, stored image volume, data transfer, build automation usage (ACR Tasks), and observability/log storage. Security hinges on Entra ID + Azure RBAC, least privilege (AcrPull/AcrPush), avoiding admin credentials, and using private networking where required.

Use Azure Container Registry when you want Azure-native container artifact management with enterprise controls and integrations. Next, deepen your skills by integrating ACR with AKS or Azure Container Apps, enabling monitoring/diagnostics, and implementing a production-ready tag/digest promotion strategy.

Category

1. Introduction

2. What is Azure Container Registry?

Core capabilities

Major components (conceptual)

Service type

Scope and locality

How it fits into the Azure ecosystem

3. Why use Azure Container Registry?

Business reasons

Technical reasons

Operational reasons

Security/compliance reasons

Scalability/performance reasons

When teams should choose Azure Container Registry

When teams should not choose it

4. Where is Azure Container Registry used?

Industries

Team types

Workloads and architectures

Real-world deployment contexts

5. Top Use Cases and Scenarios

1) Private image hosting for AKS

2) CI/CD pipeline artifact hub

3) Cloud-based container builds with ACR Tasks

4) Multi-environment promotion (dev → staging → prod)

5) Controlled access for partners or vendors

6) Internal platform “golden images”

7) Import images from upstream registries

8) Webhook-driven automation

9) Edge and disconnected scenarios (where supported)

10) Multi-region deployment performance optimization

11) Compliance-driven auditing of image access

12) Migration from self-hosted Docker Registry

6. Core Features

Managed private registry (OCI/Docker distribution)

Multiple SKUs (Basic / Standard / Premium)

Microsoft Entra ID authentication + Azure RBAC authorization

Admin user (username/password) option

ACR Tasks (cloud builds and automation)

Webhooks

Geo-replication (Premium)

Private connectivity and network controls

Import / transfer utilities

Retention and cleanup features (SKU-dependent)

Observability: metrics and diagnostic logs

7. Architecture and How It Works

High-level service architecture

Request/data/control flow

Integrations with related Azure services

Dependency services (conceptual)

Security/authentication model (practical)

Networking model (practical)

Monitoring/logging/governance considerations

Simple architecture diagram (Mermaid)

Production-style architecture diagram (Mermaid)

8. Prerequisites

Azure account and subscription

Permissions / IAM roles

Tools

Region availability

Quotas and limits (high level)

Prerequisite services (for this lab)

9. Pricing / Cost

Pricing dimensions (typical)

Free tier?

Cost drivers (what actually moves your bill)

Hidden/indirect costs

How to optimize cost

Example low-cost starter estimate (no fabricated numbers)

Example production cost considerations

10. Step-by-Step Hands-On Tutorial

Objective

Lab Overview

Step 1: Set variables and create a resource group

Step 2: Create Azure Container Registry (Basic)

Step 3: Authenticate to Azure Container Registry

Step 4: Build a small container image locally

Step 5: Tag and push the image to Azure Container Registry

Step 6 (Optional but recommended): Pull from ACR and run locally

Problem: `az acr login` succeeds but `docker push` fails with unauthorized

Problem: `curl` to ACI FQDN times out