Design and implement an MLOps infrastructure Study Guide — AI-300

Design and Implement an MLOps Infrastructure

This domain tests your ability to design, deploy, and manage Azure Machine Learning infrastructure using code-first approaches, enforce identity controls, and integrate CI/CD pipelines. It represents 19% of the AI-300 exam, making it one of the highest-weighted domains. Questions focus on Azure ML workspace architecture, Infrastructure as Code (IaC), GitHub Actions automation, network security, and the lifecycle of shared ML assets. Expect scenario-based questions where you must select the correct Azure service, configuration parameter, or code construct.

Workspaces, Datastores, and Compute Targets

Azure Machine Learning Workspaces

An Azure ML workspace is the top-level resource that organizes all ML assets. It is created in an Azure subscription and resource group. Creating a workspace automatically provisions four dependent resources:

• Azure Storage Account – default datastore for artifacts, outputs, and logs
• Azure Key Vault – stores secrets, credentials, and certificates
• Azure Container Registry (ACR) – stores Docker images for environments
• Azure Application Insights – logs metrics and telemetry

The workspace supports two tiers:

Note: As of current Azure ML, the distinction between Basic and Enterprise tiers has been collapsed. All workspaces operate under a single unified model.

Datastores

A datastore is a workspace-level abstraction over Azure storage that stores connection information (credentials or identity references) without copying data. It is not the data itself.

The default datastore (workspaceblobstore) is created automatically with the workspace and points to the associated storage account. You can register additional datastores but cannot delete the default one.

Authentication to datastores uses either account key/SAS token (credential-based) or managed identity (credential-less). Credential-less is recommended for secure, Zero Trust architectures.

Compute Targets

A compute target is a resource where training jobs and inference endpoints run.

Key limits to memorize:

• Compute cluster max nodes: up to 100 nodes per cluster by default (quota-limited)
• Compute instance: single-node only, cannot be shared across users natively
• Idle shutdown can be configured on compute instances to reduce cost
• Serverless compute requires no cluster pre-provisioning; Azure manages the underlying infrastructure

Common traps:

• Confusing Compute Instance (dev/notebook use) with Compute Cluster (batch training). The exam presents scenarios requiring auto-scaling → choose Compute Cluster.
• Selecting AKS for training jobs. AKS is for inference/deployment, not training.
• Thinking datastores store data — they store connection references only.
• The default datastore cannot be deleted, only replaced as the default.

Worked scenario: A data scientist needs to run a 3-hour training job overnight with minimal cost. The job uses 10 GPUs and should scale down after completion. Reasoning: Use Compute Cluster with min_instances=0 and max_instances=10. It scales to zero when idle, eliminating costs. A Compute Instance cannot scale and persists. Serverless compute is valid but if you need GPU SKU control, Compute Cluster is preferred.

Identity and Access Management for Workspaces

Role-Based Access Control (RBAC)

Azure ML uses Azure RBAC at the workspace level. The built-in roles are:

The AzureML Data Scientist role is the least-privilege role for ML practitioners. It is commonly tested as the correct choice when the requirement is "submit jobs and run experiments but not manage infrastructure."

Managed Identity

A managed identity eliminates the need for credentials in code. Two types:

When a workspace uses a managed identity to access the default storage account, you assign the Storage Blob Data Contributor role to the workspace's managed identity on the storage account.

For compute clusters accessing datastores with credential-less auth, the compute's managed identity must have appropriate roles on the target storage.

Common traps:

• Choosing Contributor instead of AzureML Data Scientist — Contributor grants too many permissions (creates compute, manages secrets).
• Confusing system-assigned and user-assigned managed identity — if the question says "shared across workspaces," the answer is user-assigned.
• Forgetting that managed identity must be explicitly granted RBAC on the storage account, not just the workspace.