Module 1 — Azure ML workspace and resource organization

Before a single line of training code runs, Azure ML needs a workspace. That word hides four separate services and a set of role assignments that decide who can do what. Understanding the layout now avoids a whole class of "why does my job fail with a 403" tickets later.

The workspace is not one resource, it is five

When you click "Create workspace" in the portal — or run az ml workspace create — Azure provisions the workspace resource and four hard-linked companions in the same resource group:

• Storage account — holds default blob and file shares for logs, notebooks, and datastore-less experiments. Every job that does not specify an explicit datastore writes here.
• Key Vault — stores connection strings, secrets, and, importantly, the workspace-scoped managed identity credentials.
• Application Insights — receives telemetry from online endpoints: request rates, latencies, exceptions. Without it, az ml online-endpoint invoke returns numbers but nothing else does.
• Container Registry (ACR) — created on first environment build, not up front. Every custom environment becomes an image pushed here.

The workspace itself is thin: metadata about compute, data assets, environments, jobs, models, endpoints and pipelines. The heavy lifting is done by the four services above.

The demand-forecast project setup

For the running project — weekly demand forecasting for a grocery chain — a clean starting layout looks like:

az group create --name rg-forecast-prod --location westeurope

az ml workspace create \
  --name mlw-forecast \
  --resource-group rg-forecast-prod \
  --location westeurope \
  --tags project=demand-forecast owner=data-team costcenter=CC-4711

Two decisions matter here. Region is a hard commitment: workspaces cannot be moved across regions, quotas are counted per region, and cross-region data egress adds latency and cost. Pick the region closest to where the store point-of-sale data already lives. Tags are cheap now and priceless later: Module 10 will use them to break the monthly bill down by project and cost center.

Identities: who calls Azure ML

Three identity types show up in a normal workflow, and mixing them up is one of the top sources of failure.

• User identity — you, signed in with az login. Used from the CLI, the SDK on your laptop, and Studio.
• Managed identity — an Azure-managed service principal attached to a resource (a compute cluster, an online endpoint). A job running on a cluster uses the cluster's identity to reach storage, Key Vault, or another workspace.
• Service principal — a manual application registration, used by CI/CD pipelines (Module 9 will register one for GitHub Actions).

The rule that saves the most time: jobs and endpoints authenticate as themselves, not as you. If your notebook can read the sales table but the training job cannot, the difference is that the job runs under the compute's managed identity, and that identity has never been granted access.

Built-in RBAC roles

Azure ML publishes three purpose-built roles on top of the standard Azure ones. They are not obvious and they are almost always the right starting point:

Role	What it can do	Typical assignee
AzureML Data Scientist	Submit jobs, create assets, deploy endpoints; cannot manage compute or roles	Every data scientist on the team
AzureML Compute Operator	Create, resize, delete compute; cannot submit jobs	Platform / ops engineer
AzureML Reader	Read assets and results; no writes	Stakeholders, auditors

Grant the data scientist role on the workspace, not the resource group, so a mistake does not delete the storage account. Assign the compute operator role separately: it is the wall between "a scientist can launch too big a cluster" and "a scientist can only use what already exists".

Where the resource group fits

One workspace per environment (dev, staging, prod) in its own resource group is the layout that scales. A shared resource group across projects saves nothing and complicates cost attribution. Prefixes like rg-forecast-dev, rg-forecast-prod, mlw-forecast-dev, mlw-forecast-prod make the diagram obvious and let Module 10's cost queries filter by prefix.

Before you provision anything

Decide the region, decide who gets which of the three roles, and decide the tags. All three are painful to change later — the region because it is immutable, the roles because a permission mistake caught in production is embarrassing, the tags because they backfill only through a manual bulk update.

Summary

• A workspace comes with four attached services: storage, Key Vault, App Insights and, on first build, a container registry.
• Jobs authenticate as the compute's managed identity, not as the user who submitted them — plan RBAC on that basis.
• Prefer the three AzureML built-in roles (Data Scientist, Compute Operator, Reader) over generic Owner or Contributor grants.
• One workspace per environment, tagged from day one, in a dedicated resource group.

Next module: choosing the right compute — instance, auto-scaling cluster, serverless, or low-priority — for the demand-forecast training loop.