A city IT office is launching a permits forecasting pilot and wants data scientists to share one governed Azure Machine Learning project boundary instead of scattering experiments across personal subscriptions. What should they create first?
Select an answer to reveal the explanation.
Short Explanation
Think of this pilot like a shared city workshop: you need one keyed building everyone works from, not a compute cluster or a loose dataset with no home yet. That building is a dedicated Azure ML workspace — it gives you one governed place for jobs, assets, and access, instead of pieces that only make sense once a real project boundary exists. You'll still need that workspace first before a central registry helps, since there's nothing to share across workspaces until your pilot has its own home.
Full Explanation
A dedicated Azure Machine Learning workspace is the correct first control plane for a municipal permits forecasting pilot because it establishes one governed project boundary for experiments, jobs, datastores, environments, models, and role assignments. City IT can place that workspace in an approved subscription and resource group, attach managed identities, apply Azure Policy, and give data scientists a shared place to submit work without scattering credentials and datasets across personal subscriptions. That shared boundary is what turns an ad-hoc forecasting idea into an auditable MLOps pilot the municipality can operate, fund, and review.
A shared Azure Machine Learning compute cluster for the municipal MLOps pilot fails because a compute cluster is just shared execution power — it has no existence outside a workspace and supplies none of the governed boundary's role assignments, datastore registrations, or experiment history; naming it first gets the scoping question backward. A versioned Azure Machine Learning dataset for the municipal MLOps pilot confuses content with container: a data asset still has to be registered inside some workspace, so naming the dataset first leaves the actual governed boundary — and the identity, RBAC, and lineage that comes with it — undefined. A centralized Azure Machine Learning registry for the municipal MLOps pilot fails because a registry is for sharing versioned models, components, and environments across multiple workspaces — it provides no job execution, experiment history, or project-level RBAC for daily work, so creating it first does not establish the governed project boundary the pilot needs.
Exam caveat: Azure ML workspaces are resource-scoped project containers; creating a workspace is not the same as registering a datastore, defining compute, or deploying an endpoint. On scenario questions, choose the workspace when the stem asks for a shared governed project boundary rather than a specific data or compute artifact.
Operational check: after creating the workspace, confirm it sits in the intended civic subscription and resource group, diagnostic settings and RBAC are applied, and scientists can submit jobs without Owner rights on the wider tenant.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.