2.1 Create and Manage Azure Machine Learning Workspaces

Create and Manage Azure Machine Learning Workspaces

Quick Answer: The workspace is the top-level Azure Machine Learning resource. It needs a general-purpose Storage account (not BlobStorage-only, not premium, not hierarchical namespace), Key Vault, and Application Insights. Azure Container Registry is created later, when you first build a custom image. Create one workspace per project, use a hub for shared governance, and do not plan to move the workspace to another subscription or tenant.

The Azure Machine Learning workspace is the resource you live in for almost every Domain 1 task on Exam AI-300. Jobs, experiments, data assets, registered models, pipeline components, online and batch endpoints, compute targets, datastores, and networking or identity settings all hang off this one Azure resource. If you treat the workspace as “just a folder in studio,” you will miss questions about associated Azure resources, default storage constraints, hub versus project layout, and the hard subscription and tenant boundary.

Use SDK/CLI v2 throughout this guide (azure-ai-ml and the Azure CLI ml extension). Do not design new automation around SDK v1. Microsoft Foundry is the current brand for the generative AI portal that used to be called Azure AI Studio and then Azure AI Foundry; hub workspaces in Azure Machine Learning are the same resource type as Microsoft Foundry hubs, so a hub you create for MLOps can also be opened from Foundry.

What a workspace actually stores

A workspace is both a collaboration surface and a control-plane container. As you train and deploy, Azure Machine Learning writes:

• Job history: logs, metrics, lineage metadata, and a snapshot of the script that produced the run
• Asset metadata: data assets, environments, components, and registered models
• Resource configuration: compute targets, datastores, managed virtual networks, encryption, and identity

The heavy bytes do not live “inside” the workspace ARM resource. They live on the associated resources that every workspace must have.

Associated resources

When you create a workspace, you either bring existing Azure resources or let Azure Machine Learning create them. Four dependencies matter on the exam.

Azure Container Registry is the one that trips people. You can create a workspace without ACR if you only consume images from public or external registries. The first time a job needs a custom environment image, Azure Machine Learning provisions ACR automatically. If a subscription policy requires tags on every resource, that lazy ACR create fails, because Azure Machine Learning cannot stamp your required tags onto the registry it creates. Bring a pre-tagged ACR in that case.

If you allow Azure Machine Learning to auto-create ACR, the registry is created with the admin account enabled. Production MLOps practice is to disable the admin user and pull images with a managed identity plus AcrPull, not with admin passwords in notebooks.

Default storage is picky — extra datastores are not

The workspace default storage account is not “any Azure Storage you already have.” You cannot use an existing account as default storage when it is:

• Kind BlobStorage (blob-only, not general-purpose)
• Premium (Premium_LRS or Premium_GRS)
• Enabled for hierarchical namespace (the setting that makes the account Azure Data Lake Storage Gen2)

Those three account types are still useful. Attach them later as additional datastores. What you cannot do is make them the workspace’s own default account. Do not enable hierarchical namespace on the default account after you upgrade a general-purpose v1 account to v2; that change would convert the default store into ADLS Gen2 and break the workspace contract.

If you bring an existing general-purpose v1 account, you may upgrade it to general-purpose v2 after the workspace exists. Prefer creating the workspace against a general-purpose v2 account from day one.

You cannot move the workspace across subscription or tenant

Microsoft’s workspace concept documentation is blunt: you cannot move an Azure Machine Learning workspace to a different subscription, and you cannot move the owning subscription to a new Microsoft Entra tenant. Those operations cause errors. Design the subscription, tenant, and region as if they were permanent. Cost-center changes later are handled with tags, a new workspace, or a hub-and-project layout—not with a resource move of the workspace itself.

You can still share associated Storage, Key Vault, and ACR across several workspaces in the same subscription when IT wants one hardened landing zone. When you share those resources, enable data isolation at workspace create time so container, secret, and image names are prefixed with the workspace GUID and the workspace identity is scoped with an attribute-based access condition. Data isolation cannot be flipped on after create.

Hub workspaces versus project workspaces versus default workspaces

Azure Machine Learning now has three kinds of workspace you must be able to tell apart.

• Default workspace: a standalone project container with its own associated resources. This is the classic “one workspace” you create from studio or az ml workspace create.
• Hub workspace: a governance parent. It owns the shared managed virtual network, encryption, connections, compute quota, and associated resources. Hub workspaces are the same Azure resource type as Microsoft Foundry hubs, so one hub can serve Azure Machine Learning studio and Foundry (classic hub-based projects).
• Project workspace: a child created from a hub. It inherits security and shared resources. Uploaded data is isolated per project (containers prefixed with the project workspace GUID). You still assign Azure RBAC on the project so only that team can see it.

Use a hub when a platform team must pre-secure networking and identity once, then let application teams self-serve projects. Users who create project workspaces need a role that includes Microsoft.MachineLearningServices/workspaces/hubs/join/action (the built-in Azure AI Developer role is one example). If the hub has a default project resource group, those users can create projects there without resource-group Contributor.

Hub and project workspaces are not feature-identical to default workspaces. Compute clusters are not supported on hubs (use serverless compute instead). Bring-your-own virtual network is not supported on hubs (use a managed virtual network). Batch endpoints and parallel run step are called out as unsupported on the hub/project path. You cannot convert an existing default workspace into a hub; you create a hub and new project workspaces.

How to organize workspaces in a real MLOps program

Microsoft’s own workspace guidance, which maps cleanly to AI-300 scenario items, is:

• One workspace per project so Azure cost reports, datastores, and access reviews line up with a funded effort rather than a shared sandbox.
• Microsoft Entra groups for access, not one-off user assignments on every workspace.
• Share associated Azure resources (Storage, Key Vault, ACR) when the platform team already hardened them, with data isolation enabled.
• Share ML assets (models, environments, components, data) across workspaces with Azure Machine Learning registries, not by copying files between default blob stores.
• Enable self-serve: IT pre-creates the hub or the associated resources; data scientists create project workspaces without waiting for a ticket for every experiment.

A single mega-workspace for an entire company looks cheaper on day one and becomes unmanageable: one RBAC blast radius, one datastore namespace, and one cost report that finance cannot split.

Creation paths you must recognize

You can create a workspace from any of these surfaces. AI-300 expects you to pick the right one for the constraint in the stem.

• Azure Machine Learning studio (ml.azure.com): fastest path with defaults. Good for a sandbox, weak for repeatable production settings.
• Azure portal: point-and-click with more identity, encryption, and networking options than studio’s quick create.
• Bicep or Azure Resource Manager (ARM) templates: declarative, reviewable in pull requests, the production default for platform teams. Terraform is the documented alternative if the org standard is HashiCorp rather than Bicep.
• Azure CLI v2: az ml workspace create (YAML file or flags). Pair with az configure --defaults group=... workspace=... so later az ml commands do not repeat -g and -w.
• Python SDK v2: MLClient.workspaces.begin_create with a Workspace entity. Use this inside notebooks or Python-based bootstrap jobs, not as a substitute for Bicep in enterprise landing zones.
• REST APIs and the VS Code Azure Machine Learning extension: platform integration and inner-loop create.
• Hub create: portal, ARM/Bicep, or SDK/CLI. Project workspaces created from a hub do not take their own security or associated-resource parameters; they inherit the hub.

A minimal CLI create looks like this:

az group create -n rg-mlops-prod -l eastus
az ml workspace create -n mlw-claims-prod -g rg-mlops-prod -l eastus

Pass existing resource IDs when IT already provisioned Storage, Key Vault, and ACR. That is how you keep tags, private endpoints, and diagnostic settings under platform control.

Tools after the workspace exists

Studio is the data-science surface. RBAC still happens in the Azure portal, CLI, ARM, or PowerShell. If a question says “assign AzureML Data Scientist without giving the user the Azure portal,” the honest answer is that role assignment is an Azure control-plane operation, not a studio-only click.

Exam scenario

Contoso’s MLOps team wants each product squad to see only its own jobs and costs, but security insists on one private-link path and one customer-managed key. Create a hub workspace (Foundry hub resource type) with the managed virtual network and encryption settings, then create a project workspace per product. Share environments and components through a registry. Do not put every squad in one default workspace “because networking is hard.”

Common trap

Candidates reuse an ADLS Gen2 account (hierarchical namespace) as the default workspace storage because “that is where the data lake already lives.” The create fails, or the exam answer is that you must use a general-purpose account without hierarchical namespace for the workspace itself and register the lake as an additional datastore. A second trap is planning a subscription migration of an existing workspace; the documented answer is that you cannot move the workspace to another subscription or tenant.