Design Azure Machine Learning around environment-specific workspaces and explicitly versioned reusable assets. Each workspace provides the context for its jobs, compute and storage connections; a registry provides a shared distribution point for selected models, environments, components and data assets. Across development and production, reuse the approved asset versions while deliberately selecting the destination workspace's compute and data. This keeps a release understandable without requiring every environment to share its runtime infrastructure.
The architecture therefore has two connected decisions: where work executes, and which definitions or artifacts it consumes. A reproducible design records both. A model version alone cannot explain a training result if the team cannot identify the input data, code and software dependencies. This guide uses Azure Machine Learning command-line interface (CLI) and Python software development kit (SDK) v2 documentation verified on October 15, 2026; implementation examples from v1 need separate assessment.
Architecture Overview: Workspaces, Compute, Assets, and Registries
Microsoft's resources-and-assets overview distinguishes infrastructure resources—workspaces, compute and datastores—from versioned assets—models, environments, data and components. A workspace retains job history, including logs, metrics, outputs and script snapshots. Treat that history as the starting point for investigating how a particular result was produced.
For a team with distinct development and production controls, a useful design recommendation is to separate those workspaces and establish a shared registry for approved reusable assets. Make the split serve an operational reason, such as different data exposure, billing ownership or release permissions. A separate workspace adds coordination work, so document the boundary it is intended to enforce before creating it.
The conceptual flow is straightforward: storage supplies the data; a job in a chosen workspace runs a component with an environment on compute; its output can become a model asset; selected asset versions are shared through a registry. Subsequent consumers must still choose their execution context. No registry publication should be interpreted as proof that a model is suitable for production.
Core Components and Their Responsibilities
Storage connections and data assets
A datastore holds connection information for underlying Azure storage. A data asset identifies data rather than replacing the storage service. The v2 data abstractions include file and folder Uniform Resource Identifiers (URIs), plus MLTable for tabular data. These distinctions matter when deciding whether a job needs a file, a directory or a table abstraction.
As a design practice, describe the storage connection and the dataset separately in operational records. For example, “the production training datastore” answers where the data is accessed, while “the approved September training snapshot” answers which data should be used. Neither description is a sufficient substitute for the other.
Do not infer that a versioned reference freezes every byte behind it. If a team reuses a storage path and overwrites its contents, the reference alone is inadequate evidence of an unchanged dataset. A recommended control is to retain identifiable input snapshots and record their validation evidence. Decide how long those inputs must remain available before treating a historical run as reproducible.
Environments, components and models
An environment specifies software dependencies and settings. Azure Machine Learning offers curated environments and custom environments, including image-based definitions. A component packages a pipeline step with inputs and outputs. A model asset records model files and metadata.
Use these as separate review surfaces. A dependency change may deserve testing even when training code is unchanged; a changed component interface may affect callers even when the model family is unchanged. Recommended release records should identify the exact environment and component versions rather than describing either as “the current one.” For custom dependencies, also record the source definitions and chosen image reference so a reviewer can assess what was built.
The practical question is whether another engineer can identify the intended computation without opening the original author's notebook. Keep important settings in the reviewed definitions and job configuration rather than relying on an interactive session's memory. This is a reproducibility recommendation, not a claim that versioning automatically eliminates every source of variation.
Compute alternatives
The v2 overview identifies several compute choices. Their different responsibilities should inform the design before hardware sizing begins.
| Compute choice | Documented role | Design question to resolve |
|---|---|---|
| Compute instance | Managed development environment; also supports development and test training or inference | Does an individual need an interactive environment, and who owns its running cost? |
| Compute cluster | Managed CPU or GPU nodes | What capacity and scaling behavior does the repeatable workload require? |
| Serverless compute | Job compute whose lifecycle Azure Machine Learning manages | Can this workload use the supported serverless path without requiring a team-managed cluster? |
| Inference cluster | Deployment to Azure Kubernetes Service (AKS) | Does the inference design require AKS and its operational responsibilities? |
| Attached compute | Existing compute connected to the workspace | What responsibilities and compatibility checks come with that existing resource? |
These are starting points for selection, not interchangeable promises. Before committing to a compute design, check the intended job or serving path, required accelerator, region, available capacity, supported configuration and cost. Measure a representative workload before standardizing a size. A small experiment's memory use and runtime are more useful sizing evidence than an arbitrary preference for a large machine.
Treat interactive development and repeatable execution as different operational needs. The recommended progression is to use interactive work to understand the task, then make the job's dependencies and inputs explicit so another execution can be assessed. Detailed training algorithms, distributed launch settings and serving rollout procedures are separate design topics.
How Components Work Together Across Environments
A registry decouples reusable assets from an individual workspace. Microsoft's registry guidance supports two important patterns: promote a trained model to other workspaces, or share components and environments so a pipeline can run with another workspace's compute and training data. The first moves a candidate artifact toward deployment; the second reruns a computation against a different context. Choose which outcome is intended before calling either operation a promotion.
Consider an illustrative demand-forecasting team. The following is a proposed architecture, not a report of executed Azure jobs:
- In development, use a reviewed sample dataset to exercise a preparation component and a training component. Record the data snapshot, component versions, environment versions, parameters and resulting job identifier.
- Publish the accepted component and environment versions to the shared registry. Keep a release record explaining why those versions were selected and which input and output contracts consumers must satisfy.
- In production, select the production workspace, its intended compute and the approved production training dataset. Reuse the shared definitions. The resulting training job is a new execution requiring its own evidence; it is not the development result with a different label.
- Evaluate the resulting model under the team's release criteria. If accepted, identify the model version and originating job in the release record. Registry publication is a distribution step in this proposed process; model acceptance is a separate decision.
- Have deployment consumers select the intended model version deliberately. Preserve the relationship between that version and the evidence used to accept it, so an incident investigation can distinguish an artifact change from an execution-context change.
Alternatively, a team might train the intended candidate in development and share that exact model for deployment elsewhere. That choice can be appropriate when the development training context is itself approved for the intended data and outcome. It should not be confused with retraining against production data, which produces a separately assessed result.
The shared registry does not carry the complete runtime workspace with it. Job history remains important in the originating workspace, and the consuming environment still needs appropriate resources and data access. Sharing an asset is therefore only one part of moving work across environments.
Design Considerations for Reproducibility and Ownership
Decide what is reusable and what is local
Use a simple ownership record before implementing the architecture:
| Decision | Recommended record | Why it helps |
|---|---|---|
| Workspace boundary | Environment purpose and owner | Explains why execution contexts are separate |
| Storage and dataset selection | Connection purpose and identifiable data snapshot | Separates access location from intended input |
| Shared definitions | Registry asset name, version and interface expectations | Makes reuse deliberate and reviewable |
| Execution | Workspace, compute selection, parameters and job identifier | Shows the context in which definitions ran |
| Model distribution | Model version, originating job and acceptance evidence | Connects a consumer to an assessed artifact |
Registry data sharing is available, but it should be a deliberate choice. In the forecasting example, the recommendation is to share reusable computation while keeping environment-specific training-data selection explicit. A shared evaluation dataset might have a different justification. Review sensitivity, permitted consumers and retention before choosing a distribution boundary; this architecture alone does not establish authorization policy.
Test the boundary rather than assuming portability
Before adopting a shared component, rehearse consumption in the destination context. Recommended checks include whether the intended asset versions resolve, input contracts match, dependencies suit the selected compute and an identifiable output is produced. Also confirm that the necessary historical records can be found by the people responsible for an incident.
A successful run is evidence about execution. It does not, by itself, establish acceptable model quality or permission to release. Similarly, asset version pinning improves traceability but cannot promise identical numerical results for every training implementation. Define the level of repeatability the application needs and assess it with appropriate evidence.
For cost control, assign owners to compute and retained artifacts, review utilization, and define retirement criteria for unused resources. Avoid deleting the inputs or originating records required to explain a still-supported model. Identity and network implementation belong in AI-300: Securing Azure Machine Learning Access and Networks.
Common Mistakes
- Treating a datastore name as a dataset version. Record both the connection and the intended input snapshot.
- Capturing dependencies only in an interactive notebook. Review an explicit environment definition alongside the computation.
- Sharing a model and assuming the destination inherits the originating workspace. Verify the consumer's resources and retain the link to training evidence.
- Replacing a pinned version with an informal “latest” convention. Make the accepted version part of the release decision.
- Assuming one workspace split solves every operational problem. State the intended isolation and ownership boundaries, then test them.
- Calling registry publication production approval. Require the relevant evaluation and release evidence separately.
Certification Relevance
For AI-300, practice explaining the relationships behind a job: which workspace owns its execution record, how data is identified, what an environment contributes, why a compute choice fits and which assets a registry makes reusable. An architecture explanation should also identify what must be supplied again in a destination context. Detailed identity policy, provisioning automation and training methods need their own treatment.
Conclusion
Build around explicit execution contexts and deliberate reuse. Keep workspace resources, identifiable inputs, versioned definitions and model artifacts connected through understandable records. Use registries to distribute selected assets across environments, and assess each destination's execution and release requirements before treating reuse as a successful production transition.