Connected registry - Azure Glossary

Understand the concept

In plain English

Connected registry means an Azure Container Registry capability that keeps container images available in remote, edge, or intermittently connected environments by syncing with a parent registry. Teams use it to serve image pulls near workloads, support edge operations, reduce dependency on constant cloud connectivity, and govern container artifacts across sites. In Azure work, operators usually see it in portal settings, deployment output, metrics, logs, API responses, and runbooks. The practical question is who owns it, what scope it affects, and what evidence proves it is working.

Why it matters

Connected registry matters because edge workloads can fail or run stale images if registry sync, access mode, credentials, or network assumptions are not tested before disconnection. The business impact is rarely abstract: users see slower workflows, blocked access, missing data, failed automation, audit gaps, support delays, or unexpected cost when the term is misunderstood. A strong glossary entry gives architects, developers, security reviewers, and operators the same language for design reviews and incident handoffs. It connects Azure configuration to measurable objectives, ownership, rollback paths, and evidence, so teams treat it as an operational control rather than a portal label. That discipline helps teams make safer changes under pressure.

Official wording and source

Connected registry is an Azure Container Registry Premium feature that creates an on-premises or remote replica that synchronizes container images and OCI artifacts with a cloud-based registry.

Open Microsoft Learn

Technical context

Technically, Connected registry is a deployed registry replica linked to a parent Azure Container Registry, often managed on Azure Arc-enabled Kubernetes with synchronization windows and access modes. Engineers verify it with resource IDs, configuration, logs, metrics, request records, and deployment evidence. Important configuration includes Premium registry, connected registry name, repository scope, access mode, sync schedule, client tokens, TLS, Arc extension, storage, and network path. Production reviews should capture owner, scope, region, identity, limits, recent changes, and diagnostics before changing behavior.

Exam context

Compare with

Azure Container Registry Container image

Where it is used

Where you see it

You see Connected registry in Azure Container Registry connected registry resources, tokens, sync schedules, and edge devices when confirming repository sync, parent registry, client token, and offline pull behavior for release, audit, or incident evidence.
You see Connected registry during troubleshooting when edge sites cannot pull required images during disconnection and operators must connect portal state, CLI output, logs, metrics, owners, and rollback notes.
You see Connected registry in architecture reviews when teams decide how container artifacts replicate to constrained locations, how evidence is gathered, and how it affects security, reliability, operations, cost, and performance.

Common situations

Deploy applications as images instead of server-specific installs.
Manage scaling, ingress, environment variables, secrets, and runtime isolation.
Separate build artifacts, cluster capacity, app revisions, and traffic routing.
Troubleshoot image pulls, identity, networking, probes, or rollout failures.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Factory edge image pulls Scenario, objectives, solution, measured impact, and takeaway.

Scenario

VanArsdel Manufacturing ran inspection workloads at plants where internet outages delayed Kubernetes rollouts from the central registry.

Goals

Keep critical images available during outages
Reduce plant rollout time by 50 percent
Limit each plant to approved repositories
Track stale image risk by site

Approach using Connected registry

Platform engineers deployed connected registry through Azure Arc-enabled Kubernetes at each plant. The parent Azure Container Registry used Premium SKU and repository-scoped permissions so plants received only inspection, gateway, and telemetry images. Sync windows ran before planned maintenance, and local image pulls used the connected registry endpoint. Azure Monitor collected extension health, sync status, pull failures, and stale tag alerts. Deployment pipelines published to the parent registry and triggered validation jobs before sites were marked ready. The runbook captured owner, environment, approval link, rollback condition, and the exact Azure evidence operators had to collect before and after each change. A dashboard tracked adoption, exceptions, and operational signals so support, security, and finance teams could review outcomes without relying on informal notes.

Potential outcomes

Plant rollout time fell 57 percent
Two internet outages caused no missed critical deployments
Repository scopes reduced exposed images by 72 percent
Stale image alerts caught three failed sync windows

What to learn

Connected registry gives edge sites container autonomy only when sync, scope, and health evidence are operationalized.

Scenario 02 Remote mining cluster registry Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Northwind Minerals operated remote exploration clusters with limited satellite bandwidth and frequent disconnections from Azure.

Goals

Minimize satellite image-pull traffic
Support weekly application updates offline
Protect proprietary analytics images
Prove which image version each site ran

Approach using Connected registry

Architects configured connected registry replicas at remote camps and synchronized only the analytics repositories needed by each site. Images were pre-synced during scheduled bandwidth windows, and Kubernetes deployments referenced the local registry endpoint. TLS and client tokens were rotated through a documented operations process. A central dashboard compared parent tags, local sync status, pod image IDs, and pull errors. Security reviewed repository scopes so camps could not pull unrelated engineering workloads. The runbook captured owner, environment, approval link, rollback condition, and the exact Azure evidence operators had to collect before and after each change. A dashboard tracked adoption, exceptions, and operational signals so support, security, and finance teams could review outcomes without relying on informal notes. The team reviewed results after the pilot and kept the design in the standard platform checklist for future deployments.

Potential outcomes

Satellite pull traffic dropped 64 percent
Weekly updates completed despite two cloud-link interruptions
Image-version evidence was available for every camp
Security approved repository isolation for proprietary workloads

What to learn

Connected registry is practical for remote sites when bandwidth windows and image-version evidence are part of the design.

Scenario 03 Retail store rollout cache Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Tailspin Grocers deployed containerized point-of-sale services to stores, but simultaneous morning image pulls overloaded branch links.

Goals

Reduce morning rollout congestion
Keep stores running during WAN instability
Limit access to store-approved images
Improve release rollback evidence

Approach using Connected registry

The cloud platform team used connected registry at regional store hubs. The parent ACR synchronized point-of-sale, pricing, and receipt-service images overnight, then stores pulled from the local hub during rollout. Deployment tags were pinned rather than using latest, and rollback images stayed in the local registry for the approved retention window. Operations dashboards showed sync completion, pull latency, hub health, and failed deployments. Store support could verify local image tags before escalating to cloud engineering. The runbook captured owner, environment, approval link, rollback condition, and the exact Azure evidence operators had to collect before and after each change. A dashboard tracked adoption, exceptions, and operational signals so support, security, and finance teams could review outcomes without relying on informal notes. The team reviewed results after the pilot and kept the design in the standard platform checklist for future deployments.

Potential outcomes

Morning image-pull traffic across branch links fell 71 percent
Rollback time improved from forty minutes to nine
WAN instability no longer blocked planned releases
Support escalations included exact local image tags

What to learn

Connected registry can make distributed retail rollouts faster and safer when image scope and retention are deliberate.

Azure CLI

Use CLI checks to verify parent ACR, connected registry configuration, Arc extension health, repository scope, and sync evidence before edge rollout.

Useful for

Show the parent container registry and confirm Premium SKU.
List connected registry resources and repository scopes before deployment.
Verify Arc extension status and image availability at the remote site.

Before you run a command

Confirm the active tenant, subscription, resource group, workspace, account, or region before running commands.
Use least-privileged access and avoid storing secrets, tokens, prompts, connection strings, or personal data in command output.
Know whether the command is read-only, mutating, cost-impacting, security-impacting, or destructive before production use.

What the output tells you

Output confirms whether the live Azure configuration exists at the expected scope and matches the approved design.
Returned IDs, settings, metrics, timestamps, or logs help separate configuration drift from application behavior.
Differences between expected and actual state create evidence for rollback, escalation, audit, or owner follow-up.

Mapped commands

Acr operations

direct

az acr list --resource-group <resource-group>

az acrdiscoverContainers

az acr show --name <registry-name>

az acrdiscoverContainers

az acr repository list --name <registry-name>

az acr repositorydiscoverContainers

az acr build --registry <registry-name> --image <image-name>:<tag> .

az acrprovisionContainers

az acr login --name <registry-name>

az acrsecureContainers

Architecture context

Technically, Connected registry is a deployed registry replica linked to a parent Azure Container Registry, often managed on Azure Arc-enabled Kubernetes with synchronization windows and access modes. Engineers verify it with resource IDs, configuration, logs, metrics, request records, and deployment evidence. Important configuration includes Premium registry, connected registry name, repository scope, access mode, sync schedule, client tokens, TLS, Arc extension, storage, and network path. Production reviews should capture owner, scope, region, identity, limits, recent changes, and diagnostics before changing behavior.

Security: Security for Connected registry starts with understanding registry permissions, repository scopes, client tokens, TLS certificates, Arc extension access, image trust, private network paths, and who can push or sync artifacts. Review identities, roles, secrets, network paths, data classification, logs, and who can change the setting. Prefer least privilege, private access when available, managed identity or protected credentials, and audit evidence. Watch for broad permissions, sensitive data in logs, shared keys, public endpoints, stale owners, and exceptions without expiry. Production use should include an approved owner, access boundary, alert routing, and a revocation process operators can execute during an incident. Security reviewers should tie every exception to risk acceptance and expiry.
Cost: Cost for Connected registry comes from Premium ACR requirements, connected registry charges, remote compute and storage, network transfer, image retention, monitoring, and operations time for edge support. Direct costs may be obvious, but indirect costs can appear as retries, duplicate processing, idle capacity, failed deployments, excessive logs, data movement, investigation time, or support effort. Review budgets, tags, usage metrics, quota, retention, SKU, and forecasts before enabling or scaling it. Connect spend to business-unit ownership and expected workload value. Define normal usage, alert thresholds, cleanup rules, and exception approval before the feature becomes a hidden default across environments. Finance teams need evidence that the cost aligns to real demand, not leftover experiments.
Reliability: Reliability for Connected registry depends on sync windows, parent registry availability, remote storage, local registry health, network interruptions, image retention, token expiry, and fallback for disconnected sites. Operators should know the expected failure mode, dependency chain, recovery target, and whether retries, failover, reprocessing, reauthentication, or manual approval are required. Monitor health, latency, quota, backlog, error rates, stale state, and downstream failures. Test behavior during maintenance, regional incidents, expired credentials, schema changes, policy changes, and burst traffic. Runbooks should explain how to validate current state, preserve evidence, reduce blast radius, and restore service without duplicate work or data loss. Reliability reviews should include the human handoff path, not only platform health.
Performance: Performance for Connected registry is about image pull latency, sync throughput, artifact size, repository scope, network bandwidth, local registry capacity, and Kubernetes rollout behavior at remote sites. Measure signals that reflect user or workload experience, such as latency, throughput, request units, connection counts, response time, queue depth, cache behavior, or throttled operations. Avoid tuning one setting in isolation when identity, network path, partitioning, model size, region, client behavior, or downstream capacity may be the real bottleneck. Compare baseline and peak results after changes, then document which limit would be reached first as demand grows. Keep tests close to production patterns.
Operations: Operationally, Connected registry needs clear ownership, naming, tagging, change records, and repeatable verification. Teams should know where it appears, which commands or queries prove state, which dashboard shows health, and what is safe to change during business hours. Keep examples, approvals, rollback notes, and exception records with the service runbook rather than personal notes. For production changes, capture before-and-after evidence, including resource IDs, region, tenant, policy assignment, deployment version, and linked services. Review stale resources and permissions regularly. Escalation contacts should stay current as teams reorganize. This prevents tribal knowledge from becoming the only support path. It also helps new operators support the service with confidence.

Common mistakes

Deploying connected registry without testing disconnected image pulls.
Using repository scopes that expose more images than the site needs.
Forgetting token expiry, TLS rotation, and parent registry SKU requirements.