AI-300 · LESSON 1
Design and implement an MLOps infrastructure15–20% · 3 topics
Learn how to set up assets such as compute, data and environments around the Azure Machine Learning workspace, and build them reproducibly with code (IaC) such as Bicep.
1.1Create and manage resources in a Machine Learning workspace
Concept
A workspace is the unit of work in Azure Machine Learning, managing training, deployment and assets together. On creation it is associated with a Storage account, Key Vault, Application Insights and Container Registry. Compute options include compute instances (personal development VMs), compute clusters (autoscaling for jobs) and serverless compute (run jobs without managing clusters).
How it works / steps
- Create a workspace and check its related resources (Storage, Key Vault, ACR, Application Insights)
- Provide a compute instance per developer and set idle auto-shutdown
- Create a compute cluster for jobs with minimum nodes 0 and a maximum node count to control costs (or use serverless)
- Close the network with a managed virtual network (allow internet outbound / allow only approved outbound) and private endpoints
- Minimize permissions with Azure RBAC (such as AzureML Data Scientist)
Workplace example
A five-person analytics team shares a workspace; each compute instance stops after 30 minutes idle, and training jobs run on a cluster with minimum 0 nodes so overnight cost is zero.
Common confusions and exam tips
- Compute instances are for personal development and unsuitable for large parallel training (use clusters or serverless for jobs)
- Setting minimum nodes to 1 or more bills even while unused
- With the managed VNet’s “allow only approved outbound,” explicitly allow required external destinations
Mini quiz
Q1. In Azure Machine Learning, you want to run training jobs on multiple nodes only when needed and keep costs down when idle. Which compute is appropriate?
- Always-on GPU compute instances, one for each job
- A compute cluster with minimum nodes set equal to maximum nodes
- Run training jobs on serverless Spark compute
- An autoscaling compute cluster with minimum nodes set to 0
Show answer and explanation
Answer: D An autoscaling compute cluster with minimum nodes set to 0
Clusters scale with load, and a minimum of 0 keeps idle costs down. [Other options] Instances are single-node and billed continuously. Setting minimum equal to maximum bills while idle. Serverless Spark is for data processing, not an option for multi-node training jobs.
Q2. A bug occurred because library versions differed between training and inference. What should you use to improve reproducibility?
- An environment that defines dependencies and the image
- The compute instance’s default Python kernel
- Running pip install at the start of the training script
- The latest curated environment specified per job
Show answer and explanation
Answer: A An environment that defines dependencies and the image
Defining and versioning an environment lets training and inference use the same dependencies. [Other options] pip install at run time does not pin versions. The instance kernel is not reproduced at inference. Always using the latest environment cannot prevent version differences.
Reference links
1.2Create and manage assets in a Machine Learning workspace
Concept
Assets are reusable, versioned building blocks such as data assets, environments, components and models. A datastore is connection information to Blob or ADLS Gen2; a data asset references specific data in it (uri_file, uri_folder, mltable) by name and version. An environment is a pair of a Docker image and conda dependencies.
How it works / steps
- Register datastores (identity-based access is recommended; avoid embedding credentials)
- Register data assets by name and version, and reference them from jobs as azureml:name:version
- Register a curated environment or your own (Dockerfile, conda.yml) with versions
- Register preprocessing, training and so on as components and reuse them in pipelines
Workplace example
Register each month’s data as version 2026.10 of sales-data so you can trace which model was trained on which data version.
Common confusions and exam tips
- A datastore is a “connection”; a data asset is a “reference to the data itself.” They are easily confused
- Use mltable when you want to define a read schema for tabular data
- Without pinning environment versions, library updates break reproducibility
Mini quiz
Q1. Which correctly describes the relationship between datastores and data assets?
- A datastore is a versioned reference; a data asset is the storage account connection setting
- A data asset holds storage credentials; a datastore holds a copy of the data itself
- A datastore is connection information to storage; a data asset is a versionable reference to data
- Datastores and data assets are the same thing, just named differently in job YAML
Show answer and explanation
Answer: C A datastore is connection information to storage; a data asset is a versionable reference to data
Separating the connection (datastore) from the reference (data asset) lets you work with data without exposing credentials. [Other options] Data assets hold no credentials and datastores do not copy data. The first option reverses the roles. They are different concepts.
Q2. You want to use a model and environment created in the development workspace in the production workspace too. Which method is appropriate?
- Let production reference the development workspace’s datastore
- Share assets across workspaces with a registry
- Retrain the model with the same data in the production workspace
- Download the model and register it manually in the production workspace
Show answer and explanation
Answer: B Share assets across workspaces with a registry
A registry is the mechanism for sharing assets across workspaces. [Other options] Retraining does not produce the same model. Manual registration breaks lineage. Sharing a datastore cannot hand over models and environments.
Reference links
1.3Implement IaC for Machine Learning
Concept
Infrastructure as Code (IaC) defines workspaces and compute in code so the same configuration can be created any number of times. In Azure use Bicep, ARM templates or Terraform; ML assets are defined in YAML for the Azure CLI ml extension (v2) or the Python SDK v2.
How it works / steps
- Define workspaces, networking and compute in Bicep and manage them in Git
- Separate parameter files for development, test and production
- Define jobs, environments and endpoints in YAML and create them with az ml commands
- Apply them from GitHub Actions or Azure Pipelines, authenticating with a service principal or workload identity federation
Workplace example
All changes to the production workspace go through pull request review, and Bicep is deployed from the pipeline so there is no drift from manual settings.
Common confusions and exam tips
- Manual changes in the portal diverge from IaC (drift)
- CLI v1 (azureml extension) and v2 (ml extension) are different; the exam assumes v2 YAML
- Do not write secrets in code; use Key Vault or GitHub secrets
Mini quiz
Q1. You want to reproduce the creation of a workspace and related resources with the same configuration every time. Which method is appropriate?
- Define them with Bicep templates and Azure CLI and run them automatically with GitHub Actions
- Create them in a Python SDK notebook and keep the cell output as a record
- Export an ARM template after creating them in the portal and attach it to the runbook
- Have staff run Azure CLI commands by hand each time following a runbook
Show answer and explanation
Answer: A Define them with Bicep templates and Azure CLI and run them automatically with GitHub Actions
Defining with IaC eliminates configuration drift and leaves reviews and change history. [Other options] An exported ARM template is a record, not a mechanism for continuous reproduction. Manual work and notebook runs do not guarantee the same configuration.
Q2. When configuring federated credentials (OIDC), what is most appropriate to specify on the Entra ID side as the trust condition?
- The GitHub organization, repository, branch or environment (subject)
- The GitHub user’s username and personal access token
- The IP address of the runner executing the workflow
- The workflow YAML file name and the job name to run
Show answer and explanation
Answer: A The GitHub organization, repository, branch or environment (subject)
Federated credentials specify which repository, branch or environment tokens to trust (the subject). [Other options] Trust is determined by subject (repository, branch, environment). File names, IPs and personal tokens are not conditions.
Reference links
Lessons are written by this site based on public information and do not guarantee exam content. Product specifications change, so check the latest information at the reference links.
Notes (unofficial, original questions, no pass guarantee)
- The questions on this site are original practice questions written by this site based on publicly available skills outlines and exam guides. They are not actual exam questions.
- Microsoft, Azure, Copilot, Microsoft 365, Dynamics 365 and Power Platform are trademarks of the Microsoft group of companies. This site is not affiliated with or endorsed by Microsoft.
- This content is a study aid and does not guarantee a pass. Exam content, format and prerequisites may change without notice; always check the latest information on the official page before taking the exam.
- Your accuracy on the mock exam cannot be converted to the official (scaled) score and does not predict a pass or fail.
- Progress is saved only in this browser (localStorage) unless you sign in with Google to sync it. You can delete it from the Cookie & storage settings page (Japanese).