Design and implement an MLOps infrastructure

Every task in Azure Machine Learning happens inside a workspace: uploading a dataset, running a training job, publishing an endpoint. Provisioning that shared workspace is therefore the domain's first move, and creating one automatically brings up the Azure services it leans on, a Storage account for artifacts, a Key Vault for secrets, and Application Insights for endpoint monitoring, with an Azure Container Registry (ACR) added later, the first time you build a custom Docker image. What lives inside the workspace divides cleanly in two, and holding that line is the single most useful habit for this domain. Resources are the transient plumbing you consume, such as compute targets, datastores, jobs, and endpoints, while assets are durable, versioned objects you register once and then reference by name and version as azureml:<name>:<version>. The classic trap is treating the two alike: you version a data asset, an environment, or a component, but you never version a compute cluster.

The three subtopics walk the shared workspace from the ground up as three parts, built in order, and the first two map straight onto the resource-versus-asset split. First, Machine Learning Workspace Resources provisions the container and its plumbing: the workspace, its datastores (saved, often credential-free references to existing storage, so scripts read by a friendly name instead of embedding keys), the compute targets you match to the workload (a single-node compute instance for notebooks, an autoscaling compute cluster or serverless compute for training, managed online endpoints for inference), and the least-privilege role-based access control (RBAC) that lets a data scientist self-serve compute without Owner or Contributor. Second, Machine Learning Workspace Assets fills the workspace with the reusable objects, data assets, environments, and components, and shares them across workspaces through an Azure Machine Learning registry (which stores shared assets, not the Docker images that the Azure Container Registry above holds). Third, Infrastructure as Code for Machine Learning codifies all of it as declarative templates in Git, so an entire dev, test, and prod workspace rebuilds identically on demand from a machine learning operations (MLOps) pipeline. Reach for them in that order, because you cannot register an asset before the workspace exists, nor codify a design you have not settled by hand.

Across every subtopic the exam rewards the same instinct: choose the option that Azure manages for you, grants the narrowest access, and lives in code, over the one you wire by hand, grant broadly, or click together in the portal. That is why serverless compute beats a hand-built cluster when no standing cluster is needed, why pairing the AzureML Data Scientist and AzureML Compute Operator roles beats handing someone Contributor, why the workspace's own managed identity beats a stored connection string, and why OpenID Connect (OIDC) federation beats a saved service principal secret for a GitHub-to-Azure sign-in. When a scenario sets a manual or broadly permissioned answer beside a managed, least-privilege one that meets the same requirement, the managed one is almost always the key. The exception is a stated hard constraint: if the question names a non-negotiable, a specific network isolation mode, a required role, or a private-only path, satisfy that first and optimize within it.