This chapter covers the Azure Machine Learning workspace, the foundational resource for all ML activities in Azure. Understanding the workspace is critical for the AI-900 exam, as roughly 10-15% of questions touch on workspace components, security, and resource management. You will learn what a workspace is, its core components, how to create and configure it, and how it integrates with other Azure services. This knowledge directly supports exam objective 2.4, which focuses on managing ML resources.
Jump to a section
Imagine you run a custom furniture workshop. The workshop itself (the Azure Machine Learning workspace) is a physical space with specific resources: workbenches (compute instances), tool racks (datastores), cabinets for blueprints (datasets), a filing system for client orders (experiments and runs), and a wall of finished product photos (models). Each project you take on—say, building a dining table—requires a dedicated area within the workshop where you store wood, tools, and sketches. That dedicated area is like a workspace’s isolated environment, but the workshop’s overall resources (electricity, lumber inventory, shared tools) are available across projects. The workshop manager (Azure Resource Manager) ensures that different teams don’t conflict over tool usage and that each project’s materials are tracked. If a client wants a table identical to one built last month, you retrieve the exact blueprint (model) from the filing system and reuse it, saving time. The workshop also has a security guard (Azure Active Directory) who checks badges before anyone enters, ensuring only authorized carpenters access the blueprints or tools. This structured environment mirrors how an Azure ML workspace organizes compute, data, and models while enforcing governance and collaboration.
What is an Azure Machine Learning Workspace?
An Azure Machine Learning workspace is a top-level Azure resource that acts as a central hub for all machine learning activities. It provides a unified place to manage: - Compute targets: Virtual machines, clusters, and inference clusters for training and deployment. - Data: Datastores (connections to Azure storage) and datasets (versioned data references). - Experiments and runs: Tracked training jobs with metrics, parameters, and outputs. - Models: Registered models with versioning and metadata. - Pipelines: Reusable workflows for training and deployment. - Environments: Docker images and conda dependencies for reproducible runs. - Endpoints: Real-time inference endpoints and batch inference pipelines. - Notebooks and scripts: Code assets stored in the workspace.
Each workspace is associated with an Azure subscription and resource group. Within the workspace, resources like compute instances and clusters are created and managed. The workspace itself does not run code; it orchestrates resources and stores metadata.
How the Workspace Works Internally
When you create a workspace, Azure provisions several underlying resources:
- Azure Storage account: Contains four containers: azureml (experiment outputs, logs, snapshots), code (uploaded scripts), data (datasets), and models (registered model artifacts).
- Azure Container Registry: Stores Docker images for training and inference environments.
- Azure Key Vault: Manages secrets, such as connection strings and authentication keys.
- Azure Application Insights: Collects telemetry from deployed endpoints.
These resources are created automatically in the same region as the workspace. The workspace metadata (experiments, runs, models) is stored in a managed Azure Cosmos DB instance, which is not directly visible to users.
Key Components and Their Default Values
Compute Instance: A fully managed cloud workstation for data scientists. Default size: Standard_DS11_v2 (2 cores, 14 GB RAM). Can be stopped/started to save costs.
Compute Cluster: A scalable cluster of VMs for training. Default minimum nodes: 0 (auto-scale down). Idle time before scale-down: 120 seconds.
Inference Cluster: An Azure Kubernetes Service (AKS) cluster for deploying models. Default node count: 3 (minimum 1).
Datastores: By default, the workspace creates a datastore pointing to the workspace's own blob storage (workspaceblobstore). Additional datastores can be added (Azure Blob, Azure Data Lake Gen2, SQL, etc.).
Datasets: Two types: TabularDataset (structured data) and FileDataset (file references). Datasets are versioned and can be consumed in experiments.
Environments: Defined by a Docker image (e.g., mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04:latest) and a conda dependencies YAML file.
Creating a Workspace
You can create a workspace via the Azure portal, Azure CLI, Python SDK, or ARM templates. Example Azure CLI command:
az ml workspace create -w myworkspace -g myresourcegroup -l eastusThis creates the workspace and the associated resources (storage, ACR, key vault, App Insights). The -w flag specifies the workspace name, -g the resource group, and -l the location.
Configuration and Verification
After creating a workspace, you need to configure it for use. The Python SDK requires a config.json file containing the workspace subscription, resource group, and name. This file can be downloaded from the workspace in the portal (under Overview > Download config.json).
To verify connectivity using the SDK:
from azureml.core import Workspace
ws = Workspace.from_config()
print(ws.name, ws.resource_group, ws.location)This loads the config.json and connects to the workspace. If successful, it prints workspace details.
Interacting with Related Technologies
The workspace integrates with: - Azure DevOps / GitHub Actions: For CI/CD pipelines that train and deploy models. - Azure Synapse Analytics: For large-scale data preparation. - Power BI: To consume ML models via endpoints. - Azure Arc: To manage workspaces across on-premises and multi-cloud environments. - Azure Policy: To enforce governance rules (e.g., allowed VM sizes, mandatory encryption).
Security and Access Control
Workspace access is controlled via Azure RBAC. Built-in roles include: - Owner: Full access, can manage role assignments. - Contributor: Can create and manage resources but cannot assign roles. - Reader: Read-only access to workspace resources. - Azure ML Data Scientist: Can perform all actions within the workspace except resource creation/deletion.
Additionally, Azure AD integration allows use of managed identities for accessing Azure resources without storing credentials.
Monitoring and Logging
Workspace logs are sent to Azure Monitor. You can monitor: - Run status: Queued, running, completed, failed. - Compute utilization: CPU, memory, GPU metrics. - Endpoint metrics: Request count, latency, error rate.
Alerts can be configured for failed runs or high latency.
Best Practices
Use separate workspaces for development, testing, and production to isolate resources.
Enable diagnostic settings to send logs to Log Analytics for auditing.
Use managed identities instead of service principal credentials.
Set default datastore and compute target for convenience.
Use tags to organize workspaces for cost management.
Create Resource Group
First, create a resource group to logically group all workspace resources. In the Azure portal, navigate to Resource groups, click Create, provide a name (e.g., 'ml-rg') and region. This resource group will contain the workspace and its associated resources. Using a separate resource group for ML projects simplifies cost tracking and policy enforcement.
Create Workspace via Portal
Search for 'Machine Learning' in the Azure portal and click 'Create'. Fill in the workspace name (e.g., 'ml-workspace'), select the resource group, and choose a region. The portal will prompt you to create or reuse an existing storage account, container registry, key vault, and Application Insights instance. You can accept defaults or customize. Click 'Review + create' and then 'Create'.
Verify Associated Resources
After deployment, navigate to the workspace overview. You will see links to the storage account, container registry, key vault, and Application Insights. Click each to verify they were created. Note the storage account's blob containers: 'azureml', 'code', 'data', 'models'. These are automatically populated as you use the workspace.
Download config.json
In the workspace overview page, click 'Download config.json'. This file contains the workspace name, subscription ID, and resource group. Save it to your project directory. The Python SDK uses this file to authenticate. For production, consider using environment variables or managed identities instead of config.json.
Connect with Python SDK
Install the Azure ML SDK: `pip install azureml-sdk`. Then run the following code to connect: `from azureml.core import Workspace; ws = Workspace.from_config()`. This loads config.json and establishes a connection. If successful, you can list experiments, compute targets, and datasets. This step validates that your workspace is accessible and ready for ML workflows.
Enterprise Scenario 1: Retail Demand Forecasting
A large retailer uses Azure ML to forecast demand across 10,000 stores. They create a workspace per region (e.g., NA, EU, APAC) to isolate data and comply with data residency laws. Each workspace contains:
Compute clusters with low-priority VMs to reduce cost (scale down to 0 when idle).
Datastores linking to Azure Data Lake Gen2 with historical sales data.
Automated ML pipelines that retrain weekly.
Real-time endpoints deployed to AKS for low-latency predictions.
Misconfiguration: If the workspace does not have a dedicated container registry, training jobs fail due to missing Docker images. Solution: Enable Azure Container Registry during workspace creation.
Enterprise Scenario 2: Healthcare Model Compliance
A hospital chain trains models to predict patient readmission. They must comply with HIPAA and GDPR. Their workspace uses:
Customer-managed keys (CMK) for encryption at rest (storage and Cosmos DB).
Private endpoints to keep all traffic within the Azure backbone.
RBAC roles that restrict data scientists to read-only access on patient data.
Audit logs sent to a central Log Analytics workspace.
Common issue: Data scientists accidentally store PHI in notebooks within the workspace. Solution: Use Azure Policy to block storage of unencrypted data.
Enterprise Scenario 3: MLOps with CI/CD
A fintech company integrates Azure ML with Azure DevOps. Their workspace is configured as:
A single workspace per environment (dev, test, prod).
Service principal with contributor role on the workspace for automated pipelines.
Model registry that promotes models across environments via tags.
Endpoints with blue-green deployment for zero-downtime updates.
Performance consideration: AKS clusters for inference must be sized based on expected request rate. Autoscaling is configured with min=2, max=10 nodes. If min nodes are too low, cold starts cause latency spikes.
What AI-900 Tests on This Topic
Objective 2.4: 'Describe the Azure Machine Learning workspace.' The exam expects you to:
Identify the core components: compute, datastores, datasets, experiments, models, pipelines, environments, endpoints.
Understand that the workspace is a container for all ML assets.
Know that creating a workspace automatically creates storage, container registry, key vault, and Application Insights.
Recognize the difference between compute instance (single VM for development) and compute cluster (multi-node for training).
Understand that datasets are versioned references to data, not copies.
Know that environments define the software dependencies for runs.
Common Wrong Answers and Why
'A workspace is where ML code runs.' Wrong: The workspace itself does not run code. Compute targets (instances/clusters) execute code. The workspace manages metadata.
'Datasets store actual data.' Wrong: Datasets are references (pointers) to data in datastores. The data remains in the underlying storage.
'You must manually create storage, ACR, etc.' Wrong: These are auto-created when you create the workspace. You can optionally use existing resources.
'Workspaces can only be created via portal.' Wrong: They can be created via CLI, SDK, ARM, and Terraform as well.
Specific Exam Numbers and Terms
Default compute instance size: Standard_DS11_v2.
Compute cluster idle scale-down time: 120 seconds.
Minimum AKS nodes for inference cluster: 1 (default 3).
The four auto-created resources: Storage account, Container Registry, Key Vault, Application Insights.
Datastore types: Azure Blob, Azure Data Lake Gen2, Azure Files, Azure SQL Database, etc.
Dataset types: TabularDataset and FileDataset.
Edge Cases and Exceptions
If you delete the storage account associated with the workspace, the workspace becomes unusable. You must recreate the workspace.
Workspace names must be globally unique within a region (due to storage account naming).
You can have multiple workspaces in the same resource group.
The workspace itself is free; you pay for underlying resources (compute, storage, etc.).
How to Eliminate Wrong Answers
If a question asks where ML models are stored, look for 'model registry' or 'workspace' (not compute).
If a question asks about data storage, remember that data stays in the datastore; datasets are just pointers.
If a question asks about dependencies, the answer is 'environment'.
If a question asks about tracking runs, the answer is 'experiment'.
Use the underlying mechanism: workspace = metadata + orchestration; actual execution happens on compute.
An Azure ML workspace is a container for all ML assets: compute, data, experiments, models, pipelines, environments, and endpoints.
Creating a workspace automatically provisions a storage account, container registry, key vault, and Application Insights.
Compute instances are single VMs for development; compute clusters are multi-node auto-scaling clusters for training.
Datasets are versioned references to data, not copies; data remains in datastores.
Environments define Docker images and conda dependencies for reproducible runs.
Workspace access is controlled via Azure RBAC with built-in roles like Owner, Contributor, Reader, and Azure ML Data Scientist.
The workspace is free; you pay only for underlying resources like compute and storage.
You can create workspaces via portal, CLI, SDK, ARM, Bicep, or Terraform.
These come up on the exam all the time. Here's how to tell them apart.
Compute Instance
Single VM for development and testing.
Always on unless manually stopped.
Can be used as a Jupyter notebook server.
Not auto-scaling; fixed size.
Ideal for interactive work and small-scale training.
Compute Cluster
Multi-node cluster for distributed training.
Auto-scales from 0 to max nodes based on job queue.
Cannot be used for interactive development.
Supports low-priority VMs to reduce cost.
Ideal for large-scale batch training jobs.
Mistake
The workspace itself executes training scripts.
Correct
The workspace is a metadata container; it does not run code. Compute targets (instances, clusters) execute scripts. The workspace tracks runs and stores outputs.
Mistake
Datasets store the actual data files.
Correct
Datasets are versioned references to data stored in datastores. The data remains in the underlying storage (Blob, ADLS, etc.). Datasets only store metadata like file paths and schemas.
Mistake
You must manually create a storage account before creating a workspace.
Correct
Azure automatically creates a storage account, container registry, key vault, and Application Insights when you create a workspace. You can optionally provide existing resources.
Mistake
A workspace can only be created in the Azure portal.
Correct
Workspaces can be created using the Azure CLI, Python SDK, ARM templates, Bicep, Terraform, and the REST API.
Mistake
All workspace resources must be in the same region as the workspace.
Correct
The workspace and its associated resources (storage, ACR, etc.) are created in the same region by default, but you can specify different regions for the underlying resources if needed (e.g., using existing resources in another region).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A compute instance is a single virtual machine (default Standard_DS11_v2) that is always on unless manually stopped. It is used for interactive development, Jupyter notebooks, and small training jobs. A compute cluster is a multi-node cluster that auto-scales from 0 to a maximum number of nodes based on the number of queued training jobs. It scales down after 120 seconds of idle time and is ideal for large, distributed training. Compute instances are for data scientists; compute clusters are for production training.
No. When you create a workspace via the portal, CLI, or SDK, Azure automatically creates a storage account (along with a container registry, key vault, and Application Insights). You can optionally specify existing resources, but it is not required. The storage account contains four blob containers: 'azureml', 'code', 'data', and 'models'.
Datasets are versioned references to data stored in datastores. They do not copy data; they point to it. There are two types: TabularDataset (for structured data like CSV, SQL) and FileDataset (for file references like images). Datasets enable data versioning, reproducibility, and easy access in experiments. You can register a dataset in the workspace and use it in multiple runs.
Technically yes, but best practice is to use separate workspaces for each environment to isolate resources, manage access, and prevent accidental changes. For example, a development workspace might have lower-cost compute and more permissive RBAC, while a production workspace has strict access and AKS clusters for endpoints. You can promote models across workspaces using the model registry.
An environment defines the software dependencies for a training or deployment run. It includes a Docker base image (e.g., `mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04`) and a conda dependencies YAML file specifying Python packages. Environments ensure reproducibility by capturing the exact runtime configuration. They are versioned and stored in the workspace's Azure Container Registry.
Security is handled via Azure Active Directory (AAD) for authentication and Azure RBAC for authorization. Built-in roles include Owner, Contributor, Reader, and Azure ML Data Scientist. You can also use managed identities to allow the workspace to access other Azure resources without storing credentials. Network security is achieved via private endpoints and virtual network integration.
The workspace will become unusable because it relies on that storage account for storing experiment outputs, logs, code snapshots, and model artifacts. You would need to recreate the workspace and associated resources. Always use separate resource groups for workspaces to avoid accidental deletion.
You've just covered Azure Machine Learning Workspace — now see how well it sticks with free AI-900 practice questions. Full explanations included, no account needed.
Done with this chapter?