AI-300 MLOps infrastructure explained
Design and implement an MLOps infrastructure is worth 15–20% of AI-300. It covers the ground everything else stands on: the Azure Machine Learning workspace and its resources, the assets you reuse across jobs, and the infrastructure as code and GitHub Actions workflows that create them. Questions here are about setting things up correctly and securely, so that training and deployment can be automated later.
Workspace resources
A workspace is the top-level container for experiments, models, endpoints and assets. Creating one also links, or creates, a storage account, a Key Vault, Application Insights and optionally a container registry. Knowing which dependent resource does what answers a surprising number of questions: images for environments go to the registry, secrets to Key Vault, endpoint telemetry to Application Insights.
Datastores
A datastore is a named, stored connection to an Azure storage service, most often Blob Storage or Azure Data Lake Storage Gen2. It can authenticate with a credential or with identity-based access, where the user’s or compute’s own identity is used. Identity-based access avoids storing keys and is the usual right answer when a scenario mentions security requirements.
Compute targets
| Compute | Use it for |
|---|---|
| Compute instance | A personal development machine for notebooks |
| Compute cluster | Training jobs and pipelines; scales between a minimum and maximum node count |
| Serverless compute | Jobs without managing a cluster at all |
| Kubernetes compute | Training or inference on an attached AKS or Arc-enabled cluster |
A cluster with a minimum of zero nodes costs nothing while idle. A compute instance bills until it is stopped, which is why idle shutdown and schedules exist.
Identity and access
Access is granted with Azure RBAC. Built-in roles such as AzureML Data Scientist allow running jobs and managing assets without the right to change the workspace itself. Compute can carry a managed identity, which is how a training job reads data without keys.
Assets
- Data assets version a reference to data:
uri_filefor one file,uri_folderfor a folder,mltablefor tabular data with a schema. - Environments define the software a job runs in: curated environments from Microsoft, or custom ones built from a Docker image plus a conda file.
- Components are self-contained, versioned steps with defined inputs and outputs, written in YAML and reused in pipelines.
- Registries hold environments, components, models and data outside any single workspace, so dev, test and prod workspaces all consume the same version.
A registry is the answer whenever a scenario asks how to promote the same model or environment across workspaces without copying or retraining it.
Infrastructure as code
Bicep and the Azure CLI
Workspaces and their dependent resources can be declared in Bicep and deployed with az deployment group create. Assets and jobs are created with the az ml CLI extension from YAML files. The combination means an entire environment can be rebuilt from a repository.
GitHub Actions
A workflow logs in with the azure/login action. The preferred method is OpenID Connect with a federated credential: GitHub issues a short-lived token that Azure trusts, and no secret is stored in GitHub. Environments in GitHub, with required reviewers, gate deployments to production.
Source control
Code, component YAML, environment definitions, Bicep and prompts belong in Git. Branch protection and pull requests give you review and history; the workflow runs from the repository, not from someone’s laptop.
Network isolation
A workspace can use a managed virtual network, where Microsoft manages the network for compute and you choose an isolation mode: allow internet outbound, or allow only approved outbound traffic. Private endpoints give private access to the workspace itself, and public network access can be disabled. The typical trap is forgetting that dependent resources such as storage and the container registry need private access too, or jobs fail.
Sample questions
Question 1. Data scientists in three workspaces (dev, test and prod) must use exactly the same version of a custom training environment and a set of pipeline components. You want to avoid rebuilding them in each workspace. What should you use?
- A. Copy the YAML definitions into each workspace’s repository folder
- B. A shared datastore that all three workspaces register
- C. An Azure Machine Learning registry
- D. One compute cluster attached to all three workspaces
Show answer
Answer: C
An Azure Machine Learning registry stores environments, components, models and data outside a single workspace, and every workspace with access consumes the same version. Copying YAML files rebuilds separate copies that can drift. A datastore holds data, not environments. A shared compute cluster does not share assets.
Want more questions like this? Full AI-300 practice tests →
Question 2. A training job must read files from an Azure Data Lake Storage Gen2 account. The security policy forbids storing account keys or SAS tokens anywhere, including in the workspace. How should you configure access?
- A. Create an identity-based datastore and give the compute cluster’s managed identity a Storage Blob Data Reader role
- B. Create a datastore that uses the storage account key
- C. Store a SAS token in the workspace Key Vault
- D. Enable anonymous public read on the container
Show answer
Answer: A
An identity-based datastore uses the identity of the user or compute, and a managed identity on the cluster with a data reader role on the storage account removes stored credentials entirely. Keys and SAS tokens are stored credentials, and making the container public ignores the requirement altogether.
Want more questions like this? Full AI-300 practice tests →
Question 3. You enable a managed virtual network on a workspace with the isolation mode that allows only approved outbound traffic. A training job now fails when it installs a Python package from a public package index. What should you do?
- A. Switch the workspace back to no network isolation
- B. Enable public network access on the workspace
- C. Use a larger VM size for the compute cluster
- D. Add an outbound rule allowing the package index as an approved destination
Show answer
Answer: D
In the approved-outbound mode, compute can only reach destinations you have allowed, so adding an outbound rule for the package index restores the install while keeping everything else blocked. Disabling isolation or re-enabling public access weakens security, and a bigger VM size does not change network rules.
Want more questions like this? Full AI-300 practice tests →
What to practise
Write one Bicep file that creates a workspace, deploy it from a GitHub Actions workflow authenticated with OpenID Connect, and then register a datastore, an environment and a component from YAML in the same workflow. Share the environment through a registry. That covers most of the domain and makes the scenario questions read like your own setup.