Machine Learning Workspace Resources

A workspace is the top-level resource in Azure Machine Learning, and it is the first thing you create because every other task runs inside it: registering a dataset or model, submitting a training job, or publishing an endpoint. Treat it as the hub a team shares, with everything else on this page hanging off it, the storage it uses, the datastores that reach your data, the compute that runs your code, and the identity and roles that govern who can do what.

When you create a workspace and do not bring your own, Azure ML automatically provisions the Azure services it depends on (What is an Azure Machine Learning workspace?^[1]):

• An Azure Storage account holds artifacts such as job logs and notebook files, and it is where uploaded data and job outputs land by default.
• An Azure Key Vault stores secrets and other sensitive information the workspace needs.
• Azure Application Insights collects diagnostics and monitors your inference endpoints.
• An Azure Container Registry (ACR) stores the Docker images the workspace builds. It is created lazily: only the first time you build a custom environment image or deploy an AutoML model. Until then the workspace has no ACR at all.

That ACR timing is a common trap. Because the registry appears only when a custom image is first built, a brand-new workspace legitimately has none attached, so a missing ACR is not a misconfiguration to go fix.

Hub workspaces for shared governance

A hub workspace groups several project workspaces under one set of security settings, connections, and compute, which is how a platform team centralizes governance. A hub is the same resource type as a Microsoft Foundry hub, so the same hub works from both Azure Machine Learning studio and Foundry. This is the one place where the classic ML workspace and the generative-AI side of the platform share a container. Mind the boundary the other way: a plain Foundry project is for building generative AI apps and agents and does not replace the workspace as the home for classic training assets.

One thing you cannot do: move it

A workspace cannot be moved to a different subscription, and the owning subscription cannot be moved to a new tenant (What is an Azure Machine Learning workspace?^[1]). Placement is effectively permanent, so settle the subscription, resource group, and region up front. If the workspace needs to live somewhere else later, recreate it there rather than migrating it.

Suppose a training script needs a CSV that lives in a Blob container. You could paste the storage connection string and account key straight into the code, but then the secret travels with every copy of the script and rotating it breaks every job. A datastore removes that problem. It is a saved reference to an existing Azure storage service, kept in the workspace, that holds the connection details and credentials once so scripts connect by a short, friendly name.

The indirection is the point: a datastore does not create storage and does not hold your data. It stores a pointer to the underlying storage plus the information needed to authenticate to it. The bytes stay in Blob, Azure Data Lake Storage (ADLS) Gen2, Files, or OneLake; the datastore is just the named, secured connection in front of them.

Storage types and how they authenticate

A datastore can target four storage services, each authenticated one of a few ways (Use datastores^[2]):

Storage service	Typical use	Credential options
Azure Blob Storage	General artifact and file storage	Account key, SAS token, or credential-less
Azure Data Lake Storage Gen2	Hierarchical / analytics data	Service principal or credential-less
Azure Files	Shared file share	Account key or SAS token
OneLake (Microsoft Fabric)	Fabric lakehouse data	Service principal or credential-less

A credential-less (identity-based) datastore stores no key or token at all; access uses the caller's Microsoft Entra identity at the moment the data is read. That is the pattern to reach for whenever the requirement is to connect without storing secrets. One retirement to remember: Azure Data Lake Storage Gen1 datastores are gone, because Gen1 itself retired on February 29, 2024, so use Gen2.

The default datastore

Every workspace is created with a built-in default named workspaceblobstore. Azure ML uploads data and writes job outputs there unless you point them elsewhere, so you can start working before creating any datastore of your own. Its paths take the form azureml://datastores/workspaceblobstore/paths/....

Creating an identity-based Blob datastore (CLI v2)

The YAML below defines a credential-less Blob datastore. Because it names no account_key and no sas_token, access falls back to the caller's Entra identity. Register it with az ml datastore create:

# my_blob_datastore.yml
$schema: https://azuremlschemas.azureedge.net/latest/azureBlob.schema.json
name: my_blob_ds
type: azure_blob
account_name: my_account_name
container_name: my_container_name
# no credentials: block  =>  credential-less (identity-based) access

az ml datastore create --file my_blob_datastore.yml

Here the absent credentials block is exactly what makes the datastore identity-based. Adding an account_key or a sas_token under a credentials: key instead would make it credential-based, which stores that secret in the workspace.

An environment defines the software a job needs; a compute target provides the hardware it runs on. The workspace offers several targets, and the exam almost always tests whether you can match the right one to a described workload.

Start from the split the rest of the page uses: three of these targets run training or interactive work, differing only in how much you manage, from single-node and interactive, to a multi-node cluster that autoscales per job, to fully managed with nothing to size; the other two serve a deployed model for inference. The five to recognize:

• A compute instance is a single-node managed workstation for one user, for authoring and running notebooks. It keeps billing while it is running, so its cost control is idle shutdown, not scaling to zero.
• A compute cluster (AmlCompute) autoscales between a minimum and maximum node count, giving each submitted job its own dedicated nodes (so jobs stay isolated) and de-allocating back to the minimum when idle. Set the minimum to 0 and you pay nothing between runs while still getting per-job isolation, the combination a compute instance cannot give you.
• Serverless compute goes one step further: there is no cluster to create at all. Omit the compute parameter on a command, sweep, or AutoML job and Azure ML creates, scales, and tears down the compute for you.
• A managed online endpoint runs low-latency real-time inference on Microsoft-managed compute.
• Attached Kubernetes (Azure Kubernetes Service or Arc-enabled) serves high-scale or on-premises and edge inference on a cluster you own and patch.

Autoscaling and low-priority cost control

Two levers keep training compute cheap. The first is scale-to-zero. On a compute cluster, setting min_instances: 0 lets Azure ML de-allocate every node when no job is running, so an idle cluster costs nothing (Create compute clusters^[3]); any minimum above 0 keeps that many nodes billing even while idle. The second is discounted capacity. Training and batch compute can run on Azure's surplus low-priority (Spot) capacity, which is much cheaper but can be evicted mid-job. On a compute cluster you request it with tier: low_priority; on serverless you set queue_settings.job_tier: Spot. Real-time serving (managed online endpoints, Azure Container Instances, and AKS) has no low-priority tier.

Creating an autoscaling low-priority cluster (CLI v2)

This spec creates an AmlCompute cluster that scales from 0 to 2 nodes and runs on low-priority VMs. The min_instances: 0 line is what enables zero idle cost, and tier: low_priority is what selects Spot capacity. Register it with az ml compute create:

# create-cluster.yml
$schema: https://azuremlschemas.azureedge.net/latest/amlCompute.schema.json
name: low-pri-example
type: amlcompute
size: STANDARD_DS3_v2
min_instances: 0
max_instances: 2
idle_time_before_scale_down: 120
tier: low_priority

az ml compute create --file create-cluster.yml

Serverless: the no-infrastructure answer

When a scenario says to run training jobs without provisioning or managing infrastructure, the answer is serverless compute, reached by omitting the compute target, not a compute cluster, Azure Container Instances, AKS, or local compute (Model training on serverless compute^[4]). Serverless still consumes the same Azure ML compute quota, and if you also leave out the resources block, it defaults the instance count and picks an instance_type from your quota so the job does not fail on an insufficient-quota error. For a pipeline job you select it by setting the pipeline's default_compute to serverless (azureml:serverless in CLI YAML).

Access to a workspace is governed by Azure role-based access control (Azure RBAC), and the exam rewards choosing the narrowest role that still lets a person do their job. Azure ML ships built-in roles tuned for exactly that (Manage roles in your workspace^[5]):

Built-in role	What it grants
AzureML Data Scientist	Every action in the workspace except creating or deleting compute, and except modifying the workspace itself
AzureML Compute Operator	Create, manage, delete, and access compute
AzureML Registry User	Read, write, and delete assets in a registry, but not create or delete the registry resource
Reader / Contributor / Owner	The general Azure roles: view only; full management without role assignment; and full control including role assignment

The intended pattern combines the two narrow roles: grant a data scientist AzureML Data Scientist plus AzureML Compute Operator and they can run experiments and self-serve compute without ever holding Owner or Contributor. Reaching for Owner or Contributor just to let someone work is the classic over-privileging mistake.

The workspace's own identity

Users are not the only principal that needs access; the workspace itself must reach its dependent Storage, Key Vault, and Container Registry. It does so with a managed identity (system-assigned by default, or user-assigned if you supply one), so no credential is embedded anywhere (Set up authentication between Azure Machine Learning and other services^[6]). A managed identity is a service principal whose certificate Azure creates and rotates for you, and it comes in two forms: system-assigned, tied to the workspace's lifecycle and deleted with it, and user-assigned, a standalone resource you can share across workspaces.

The scope of that identity changed for the better. For workspaces created after 2024-11-19, the system-assigned identity is granted the Azure AI Administrator role on the resource group, a role scoped to just what the workspace needs. Workspaces created before that date received the broader Contributor role instead, and Microsoft recommends converting them (with the az ml workspace update --allow-roleassignment-on-rg true command) to the narrower role (Manage roles in your workspace^[5]). Prefer this scoped managed-identity model over embedding credentials or handing out blanket Contributor access.

The workspace-resources questions are mostly of one shape: pick the single best resource for a stated requirement. The stems become easy once you map the trigger phrase to the resource.

• Run training jobs without provisioning or managing infrastructure points to serverless compute (omit the compute target). Distractors offering a compute cluster, Azure Container Instances, AKS, or local compute all still make you size or manage something.
• Isolated per-job compute at zero cost when idle is a compute cluster with min_instances: 0. A compute instance is wrong because it bills while running and only idle-shuts-down; a fixed-size cluster is wrong because a minimum above 0 keeps billing.
• Least-privilege role so a data scientist can run experiments is AzureML Data Scientist (add AzureML Compute Operator if they must create compute). Owner and Contributor are the over-privileged distractors.
• Connect to storage without storing keys or secrets is a credential-less (identity-based) datastore, which uses the caller's Entra identity. Account-key and SAS-token datastores are the tempting but wrong answers.
• The workspace needs to build a custom Docker image is when the Azure Container Registry is created; a stem implying the registry should already exist on a fresh workspace is testing the lazy-creation fact.
• Top-level container for classic ML training assets is the workspace, not a Foundry project; the Foundry project is for generative-AI apps and agents.
• Move the workspace to another subscription has no valid do-it answer; the correct response is that it is not supported, so you recreate it in the target.

Across all of these the meta-pattern is least privilege and least management: choose the resource or role that meets the requirement with the least standing cost, the least infrastructure to babysit, and the narrowest permissions.