3.4 Share Assets Across Workspaces with Registries
Key Takeaways
- An Azure Machine Learning registry is a tenant-scoped, workspace-agnostic catalog that stores models, environments, components, and data assets and replicates them across regions you choose at create time.
- Workspace resources (compute, jobs, endpoints) are transient and workspace-specific; they do not live in a registry. Share assets, then run jobs and deployments in each workspace on that workspace's compute.
- Promotion pattern: train in a project (dev) workspace → register or az ml model share into the registry → deploy or retrain from test/prod workspaces using azureml://registries/<name>/models/... (and the same URI shape for environments and components).
- Registry names are 2–32 characters, unique in the Microsoft Entra tenant, start with alphanumeric, and cannot change because they are embedded in asset IDs. The primary region is immutable; additional replication regions can be updated.
- Reader plus registries/assets/read is enough to consume assets. Creating assets needs registries/assets/write (and delete). Built-in Contributor/Owner can also create and delete the registry resource itself — use a custom role if producers must not manage the registry.
Share Assets Across Workspaces with Registries
Quick Answer: An Azure Machine Learning registry is a central, multi-region catalog of assets (models, environments, components, and data). Resources (compute, jobs, endpoints) stay in each workspace. Train in dev, register or share into the registry, then deploy from test or prod with
azureml://registries/<registry>/.... That is the promotion pattern Domain 1 tests.
Chapter 2’s workspace is the sandbox where jobs run. This section is how a bank with dev, test, and prod workspaces — often in different subscriptions and regions — still shares one champion model and one training component without emailing MLflow folders.
Assets versus resources
| Category | Examples | Lifetime / scope |
|---|---|---|
| Assets | Models, environments, components, data (datasets) | Durable, workspace-agnostic. Register once; use from many workspaces |
| Resources | Compute clusters, jobs, online/batch endpoints | Transient, workspace-specific. An endpoint’s scoring URI belongs to one workspace instance |
A registry exists because security policy, billing subscriptions, and latency regions often force multiple workspaces. Without a registry you lose lineage: the prod endpoint cannot point back at the dev training job, metrics, code, environment, and data. With a registry, the model artifact carries that lineage across the boundary.
Microsoft compares a registry to a Git repository for ML artifacts: it decouples the catalog from any working copy (workspace).
Two scenarios dominate the exam:
- Cross-workspace MLOps — train in
dev-ml, deploy the same model identity totest-mlandprod-ml, preserving end-to-end lineage. - Share and reuse — publish a golden environment plus a feature-engineering component to a central catalog so other teams search Studio Registries and drop them into their pipelines.
Create a registry (what you must know)
Create with az ml registry create --file registry.yml, Studio Registries → Manage registries, Azure portal, or REST (2025-09-01 API as documented in 2026). YAML includes name, location (primary), and replication_locations (primary plus additional regions).
Constraints that show up as distractors:
- Name: 2–32 characters, unique in the Microsoft Entra tenant, start with alphanumeric, then alphanumerics, hyphen, underscore. No spaces. Cannot rename later because the name is inside model/environment/component IDs.
- Primary region: set once. Additional regions can be updated as the workspace map grows. Start with every region where you have or will have workspaces.
- Replication plumbing: creating a registry provisions Blob storage in each supported region and one Azure Container Registry with geo-replication so image pulls are local. Optional CLI-only storage SKU / hierarchical namespace (
storage_account_hns) picks Blob versus Azure Data Lake Storage Gen2 per region. - Workspace location: the workspace you train or deploy from must be in a region the registry supports. This is an explicit warning in the share-across-workspaces article.
Browse registries in the global Studio UI (https://ml.azure.com/registries), not only from inside one workspace’s left nav.
Promotion pattern (the MLOps loop)
The skills-measured phrasing is “share assets across workspaces by using registries.” Operationally:
- Author in a project workspace. Train with a component. Compute and training data stay local to that workspace.
- Publish assets to the registry. Same CLI verbs, different target:
az ml environment create --file env.yml --registry-name <reg>az ml component create --file train.yml --registry-name <reg>az ml model create --path ./artifacts/model --type mlflow_model --registry-name <reg>- Data:
az ml data create ... --registry-name(share-data article; registries store data assets as well as models/envs/components).
- Run or deploy from another workspace using registry URIs, for example
component: azureml://registries/<reg>/component/train_linear_regression_model/versions/1andmodel: azureml://registries/<reg>/models/nyc-taxi-model/versions/1.
SDK v2 uses two MLClient objects: one constructed with workspace_name, one with registry_name + registry_location. Create assets on the registry client; submit jobs and online deployments on the workspace client.
Share from workspace to registry when you want to test first: register the MLflow model in the workspace from azureml://jobs/<job>/outputs/artifacts/paths/model, smoke-test an endpoint, then az ml model share --name nyc-taxi-model --version 1 --registry-name <reg> --share-with-name ... --share-with-version .... Share-with name and version are required; the registry can use a different identity than the workspace model. The Python models.share() method is documented as experimental — prefer CLI on the exam if the item is picky.
You can also register a model in the registry directly from local MLflow files (az ml job download then az ml model create --registry-name). MLflow format is what lets later no-code online deployment work.
Because the component and environment live in the registry, the same az ml job create --file pipeline.yml can be pointed at dev-workspace, test-workspace, and prod-workspace (different --workspace-name / --resource-group). Each workspace still needs its own compute (for example cpu-cluster) and its own data. That is the point: assets travel; resources do not.
Nested assets: a pipeline component in a registry may only reference named environments and components that already exist in that registry. Create inner assets first.
Image pull security: the registry’s system-assigned managed identity has AcrPull on the registry ACR. When a workspace compute needs the image, the registry issues a scoped ACR token. Neither the workspace nor the compute managed identity needs direct ACR rights on the registry. User-assigned identity on endpoints is a special case: you may still need to grant AcrPull and Storage Blob Data Reader at subscription scope — don’t over-generalize that to ordinary cluster jobs pulling a registry environment.
Registry versus workspace model registry
Every workspace has a Models (and Environments, Components, Data) catalog. That is the workspace registry in casual speech. An Azure Machine Learning registry resource is different:
- Workspace catalog: visible to users of that workspace; promotion to another workspace is a manual export unless you share.
- Org registry: tenant-unique name, multi-region replica, URI starts with
azureml://registries/<registry>/..., lineage survives crossing subscriptions.
If an item asks “the model must be deployed from a production workspace in another subscription without retraining,” the answer is the registry, not “give prod contributors on the dev workspace” and not “zip the runs:/ folder.”
Curated environments already live in Microsoft’s azureml registry. Your org registry is how your golden images and components get the same treatment.
Permissions
You must be Owner or Contributor on the subscription or resource group to create the registry (or a custom role with Microsoft.MachineLearningServices/registries/write and /delete). After it exists, split duties:
- Consume only: built-in Reader, or custom
registries/read+registries/assets/read(list registries, browse and use assets in a workspace). - Produce assets: add
registries/assets/writeand usuallyregistries/assets/delete. - Do not hand producers Contributor/Owner if they must not create, update, or delete the registry resource. Those built-in roles include
registries/writeandregistries/delete. Custom roles are the documented way to separate “publish sklearn-env:4” from “delete the registry.”
Exam scenario
Contoso trains a claims model in workspace ml-dev (West US, development subscription). Production inference must run in ml-prod (East US, production subscription) with no training data exposure. The MLOps engineer creates registry contoso-ml-catalog with primary eastus and replication including westus. They create SKLearnEnv:1 and component train_claims:1 in the registry, submit the training pipeline job in ml-dev using that component (compute cpu-cluster in dev), share the resulting MLflow model claims-seg:12 into the registry, and in ml-prod create a managed online endpoint whose deployment model: URI points at azureml://registries/contoso-ml-catalog/models/claims-seg/versions/12. Prod never needed Reader on ml-dev. Lineage on the registry model still links the dev job.
Common trap
Do not put a compute cluster or online endpoint “in the registry.” Those are workspace resources. The trap sibling is treating the workspace Models blade as already cross-subscription. A third trap is creating the registry only in West US, then failing prod deploys because East US is not a replication location. A fourth is granting Contributor so a data scientist can az ml component create --registry-name — they can also delete the registry.
A model trained in workspace ml-dev must be deployed to an online endpoint in workspace ml-prod in another subscription, preserving lineage to the training job. Which pattern matches Azure Machine Learning registries?
How does an Azure Machine Learning registry differ from the Models list inside a single workspace?
You want data scientists to publish components into registry contoso-ml-catalog but not create or delete the registry resource. Which permission design matches Microsoft's registry RBAC guidance?