ML Workspace: Your AI Control Room
Every ML project starts with a workspace. Learn how to create, configure, and secure Azure Machine Learning workspaces — the central hub for all your MLOps and data science work.
AI-300 is a BETA exam. Content may change before general availability (~June-July 2026). This guide is based on the official study guide published by Microsoft. We’ll update as the exam evolves.
What is a Machine Learning workspace?
A workspace is like a fully equipped science lab.
Imagine a research lab where everything has its place: the chemicals (data), the equipment (compute), the notebooks (experiments), and the safety protocols (access control). You don’t mix Lab A’s experiments with Lab B’s. Each lab has its own budget, its own team, and its own locked door.
An Azure Machine Learning workspace works the same way. It’s the central hub where your team stores data, runs experiments, tracks results, and deploys models — all in one organised, secure space.
Workspace architecture
When you create a workspace, Azure automatically provisions these supporting resources:
| Resource | Purpose | Created Automatically? |
|---|---|---|
| Azure Storage Account | Stores experiment logs, model artifacts, datasets, snapshots | Yes |
| Azure Key Vault | Stores secrets — connection strings, API keys, passwords | Yes |
| Application Insights | Captures telemetry from deployed endpoints | Yes |
| Azure Container Registry | Stores Docker images for environments and deployments | Created on first use |
Scenario: Kai sets up NeuralSpark's first workspace
Kai Nakamura, MLOps engineer at NeuralSpark (a 50-person AI startup), needs to set up their first production workspace. Priya, the CTO, wants a workspace that:
- Keeps staging and production experiments separate
- Lets the data science team run experiments without touching production
- Doesn’t blow the cloud budget
Kai’s plan:
- One resource group for all ML resources (keeps billing visible)
- Two workspaces:
neuralspark-dev(experiments, cheap compute) andneuralspark-prod(production endpoints, managed compute) - Managed identity on both workspaces (no passwords stored anywhere)
- RBAC: data scientists get “AzureML Data Scientist” role on dev, read-only on prod
This two-workspace pattern is common for startups that want speed without production risk.
Creating a workspace
You can create a workspace through the Azure portal, Azure CLI, Python SDK v2, or Bicep/ARM templates.
Azure CLI (most exam-relevant):
# Create a resource group
az group create --name rg-ml-prod --location eastus
# Create the workspace
az ml workspace create \
--name ml-workspace-prod \
--resource-group rg-ml-prod \
--location eastusWhat’s happening:
- Line 1-2: Creates a resource group to hold all ML resources
- Line 4-7: Creates the workspace — Azure auto-provisions the Storage Account, Key Vault, and Application Insights
Python SDK v2:
from azure.ai.ml import MLClient
from azure.ai.ml.entities import Workspace
from azure.identity import DefaultAzureCredential
# Authenticate
credential = DefaultAzureCredential()
# Define the workspace
ws = Workspace(
name="ml-workspace-prod",
location="eastus",
resource_group="rg-ml-prod",
description="NeuralSpark production workspace"
)
# Create it
ml_client = MLClient(
credential=credential,
subscription_id="your-subscription-id",
resource_group_name="rg-ml-prod"
)
ml_client.workspaces.begin_create(ws).result()What’s happening:
- Lines 1-3: Import the SDK and authentication classes
- Line 6: Uses
DefaultAzureCredential— tries managed identity first, then Azure CLI, then environment variables - Lines 9-14: Defines workspace configuration as a Python object
- Lines 17-21: Creates an
MLClientto talk to Azure - Line 22: Sends the create request and waits for completion
Exam tip: SDK v2 vs SDK v1
AI-300 uses Azure ML SDK v2 (the azure-ai-ml package). If you see import paths like from azureml.core import Workspace, that’s SDK v1 — deprecated for new projects. The exam focuses on SDK v2 patterns:
MLClientinstead ofWorkspace.from_config()- YAML-based definitions instead of pure Python objects
azure.ai.ml.entitiesfor resource definitions
Identity and access management
Workspaces use Azure RBAC (Role-Based Access Control) to control who can do what:
| Feature | Can Create Compute | Can Run Experiments | Can Deploy Models | Can Manage Workspace |
|---|---|---|---|---|
| Reader | No | No (view only) | No | No |
| AzureML Data Scientist | Yes | Yes | Yes (to existing endpoints) | No |
| AzureML Compute Operator | Yes | No | No | No (compute only) |
| Contributor | Yes | Yes | Yes | Yes (except RBAC) |
| Owner | Yes | Yes | Yes | Yes (including RBAC) |
Managed identity is the recommended authentication method for workspaces:
- System-assigned managed identity — created automatically with the workspace, tied to its lifecycle
- User-assigned managed identity — you create it separately and attach it; can be shared across resources
Scenario: Dr. Fatima locks down Meridian's workspace
Dr. Fatima Al-Rashid, ML Platform Lead at Meridian Financial, needs enterprise-grade access control:
- Data scientists → “AzureML Data Scientist” role (can experiment, can’t change infrastructure)
- ML engineers → “Contributor” role (can deploy and manage endpoints)
- Compliance team → “Reader” role (audit experiments and model lineage)
- Service accounts for CI/CD → User-assigned managed identity with “AzureML Data Scientist” role
James Chen (CISO) insists on no passwords in code — managed identity handles all auth between the workspace and its backing resources (storage, key vault, container registry).
Exam tip: Managed identity vs service principal
The exam favours managed identity over service principals for workspace authentication. Key reasons:
- No secrets to manage or rotate
- Automatic credential lifecycle
- Works natively with RBAC
If a question asks about the “most secure” or “recommended” way to authenticate a workspace to other Azure services, the answer is almost always managed identity.
Multi-workspace strategies
Most organisations use more than one workspace. Common patterns:
| Strategy | Workspaces | Best For |
|---|---|---|
| Dev/Prod split | 2: dev + prod | Startups, small teams (Kai’s pattern) |
| Team-based | Per team: NLP, vision, forecasting | Large orgs with independent ML teams |
| Project-based | Per project: fraud-detection, churn-prediction | Regulated industries needing audit isolation |
| Environment-based | 3: dev + staging + prod | Enterprise CI/CD with promotion gates |
When to use one workspace vs many
One workspace when:
- Small team (under 10 data scientists)
- Single project or tightly related projects
- Want simplicity over isolation
Multiple workspaces when:
- Different teams need different access controls
- Regulatory requirements mandate data isolation
- CI/CD pipeline needs distinct environments (dev → staging → prod)
- Cost tracking per team or project is required
The exam may present a scenario where you need to choose between strategies. Focus on the requirement: isolation (security, compliance) favours more workspaces; collaboration (shared models, shared data) favours fewer.
Key terms flashcards
Knowledge check
Kai is setting up workspaces at NeuralSpark. He wants data scientists to run experiments freely but not modify production endpoints. Which role should he assign to data scientists on the production workspace?
Dr. Fatima needs Meridian's workspace to authenticate to Azure Storage without storing any credentials in code. What should she configure?
🎬 Video coming soon
Next up: Data, Environments & Components — the building blocks that make your experiments reproducible.