Study guide
3.1 Create and Manage Data Assets
Microsoft AI-300: Operationalizing Machine Learning and Generative AI Solutions Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current Exam Facts 1.2 Skills Measured, Format, and How This Guide Is Organized 1.3 Candidate Profile, Azure ML v2, Foundry, and DevOps Tooling
2 Chapter 2: Azure Machine Learning Workspaces, Datastores, Compute, and IAM
2.1 Create and Manage Azure Machine Learning Workspaces 2.2 Create and Manage Datastores 2.3 Create and Manage Compute Targets 2.4 Configure Identity and Access Management for Workspaces
3 Chapter 3: Azure Machine Learning Data Assets, Environments, Components, and Registries
3.1 Create and Manage Data Assets 3.2 Create and Manage Environments 3.3 Create and Manage Components 3.4 Share Assets Across Workspaces with Registries
4 Chapter 4: Infrastructure as Code, GitHub, and Network Isolation for Azure ML
4.1 GitHub Integration and Git Source Control for Machine Learning Projects 4.2 Deploy Workspaces and Resources with Bicep and Azure CLI 4.3 Automate Resource Provisioning with GitHub Actions 4.4 Restrict Network Access to Machine Learning Workspaces
5 Chapter 5: MLflow Tracking, AutoML, Training Jobs, and Hyperparameter Sweeps
5.1 Configure Experiment Tracking with MLflow 5.2 Use Automated Machine Learning to Explore Optimal Models 5.3 Notebooks, Command Jobs, and Training Scripts 5.4 Automate Hyperparameter Tuning
6 Chapter 6: Distributed Training, Training Pipelines, and Job Comparison
6.1 Manage Distributed Training for Large and Deep Learning Models 6.2 Implement Training Pipelines 6.3 Compare Model Performance Across Jobs
7 Chapter 7: Model Registration, Responsible AI, and Lifecycle Management
7.1 Register MLflow Models and Package Feature Retrieval Specs 7.2 Evaluate Models with Responsible AI Principles 7.3 Manage Model Lifecycle and Archiving
8 Chapter 8: Online Endpoints, Batch Endpoints, Rollout, and Rollback
8.1 Deploy Models to Managed Online Endpoints 8.2 Deploy Models to Batch Endpoints 8.3 Test, Troubleshoot, Progressive Rollout, and Safe Rollback
9 Chapter 9: Data Drift, Production Metrics, Retraining, and Alerts
9.1 Detect and Analyze Data Drift 9.2 Monitor Production Metrics and Trigger Retraining or Alerts
10 Chapter 10: Microsoft Foundry Resources, IAM, Networking, and IaC
10.1 Create and Configure Foundry Resources and Project Environments 10.2 Managed Identities and RBAC for Foundry 10.3 Foundry Network Security and Private Networking 10.4 Deploy Foundry Infrastructure with Bicep and Azure CLI
11 Chapter 11: Deploying and Managing Foundation Models
11.1 Serverless API Endpoints and Managed Compute for Foundation Models 11.2 Select Foundation Models for Specific Use Cases 11.3 Model Versioning and Production Deployment Strategies 11.4 Provisioned Throughput Units for High-Volume Workloads
12 Chapter 12: Prompt Design, Variants, and Git Version Control
12.1 Design and Develop Prompts 12.2 Create Prompt Variants and Compare Performance 12.3 Version Control for Prompts with Git
13 Chapter 13: Evaluation Datasets, Quality Metrics, Safety, and Automated Workflows
13.1 Test Datasets and Data Mapping for Evaluation 13.2 Groundedness, Relevance, Coherence, and Fluency 13.3 Risk and Safety Evaluations 13.4 Built-in and Custom Automated Evaluation Workflows
14 Chapter 14: Continuous Monitoring, Performance, Cost, Tracing, and Logging
14.1 Continuous Monitoring in Microsoft Foundry 14.2 Latency, Throughput, Token Use, and Cost Metrics 14.3 Logging, Distributed Tracing, and Production Debugging
15 Chapter 15: Retrieval Tuning, Embeddings, Hybrid Search, and RAG Evaluation
15.1 Tune Similarity Thresholds, Chunk Sizes, and Retrieval Strategies 15.2 Select and Fine-Tune Embedding Models 15.3 Hybrid Search: Semantic and Keyword Retrieval 15.4 RAG Relevance Metrics and A/B Testing
16 Chapter 16: Fine-Tuning Methods, Synthetic Data, and Promotion to Production
16.1 Advanced Fine-Tuning Methods (LoRA, QLoRA, Full) 16.2 Create and Manage Synthetic Data for Fine-Tuning 16.3 Monitor, Optimize, and Promote Fine-Tuned Models
3.1 Create and Manage Data Assets
Key Takeaways Explain This Topic AI
An Azure Machine Learning data asset is a named, versioned identity that points at a URI; creating it stores metadata, not a second copy of the bytes (except a local-path create, which uploads to the workspace default datastore).
SDK/CLI v2 data types are uri_file (one file of any format), uri_folder (a directory of files), and mltable (a materialization blueprint stored next to your data).
A datastore is the workspace connection to Azure Blob, Azure Files, or Azure Data Lake Storage; a data asset is the versioned bookmark jobs consume as azureml:<name>:<version>.
Data asset versions are immutable by design: Azure Machine Learning does not support deletion because deletion would break job lineage and reproducibility. Archive unused names; fix a bad path by creating a new version.
Create from YAML with az ml data create -f data.yml (or az ml data create --path --name --version --type). Jobs can mint a new asset by setting name on an output.
Last updated: August 2026
Create and Manage Data Assets
Quick Answer: An Azure Machine Learning data asset is a versioned bookmark to data that already lives in storage. The three SDK/CLI v2 types are uri_file (one file), uri_folder (a folder), and mltable (a table blueprint). A datastore is the connection; a data asset is the named version you pass to jobs. Create with az ml data create -f data.yml . Versions are immutable — archive mistakes, do not expect deletion.
Domain 1 of Exam AI-300 asks you to create and manage data assets in an Azure Machine Learning workspace. That bullet is not “upload a CSV.” It is about giving Machine Learning Operations (MLOps) a durable identity for the data a job consumed so you can reproduce training, audit lineage, and stop embedding storage secrets in scripts.
Data asset versus datastore
Keep these two workspace objects separate. You studied datastores in Chapter 2; this section consumes them.
Object What it is What it is not Typical identity
Datastore A connection to an existing Azure storage account (Blob container, File share, Azure Data Lake Storage Gen1 or Gen2) The dataset itself azureml://datastores/<datastore>/paths/...
Data asset A versioned reference (name + version + type + path metadata) A second physical copy of the files (unless you created it from a local path) azureml:<name>:<version>
A datastore can use credential-based authentication (account key, shared access signature, service principal) or identity-based authentication (Microsoft Entra ID or a managed identity). Users with Reader on the workspace can retrieve credential-based secrets stored on the datastore, which is why identity-based access is the safer default for production. A data asset does not replace that connection. It uses a path — often a datastore URI — and records which version of “claims training images” a pipeline pinned.
Microsoft’s own analogy is a browser bookmark. You stop memorizing a 200-character wasbs:// or abfss:// string and instead ask for azureml:claims-images:2026-08-15 . Creating the asset writes a reference plus metadata . The bytes stay where they are, so you do not pay a second storage bill and you do not fork the source of truth.
Exception that the exam loves: if path is on your local computer , Azure Machine Learning uploads the file or folder into the workspace default datastore ( workspaceblobstore ) and then registers the asset against that cloud path. Local create is the one case where “registering” also copies bytes.
You are not required to create a data asset before a notebook or job can read data. Datastore URIs work immediately. Assets become valuable the moment a second person, a pipeline, or a later calendar quarter needs the same identity.
The three v2 types
A Uniform Resource Identifier (URI) can point at a file, a folder, or a table. Job inputs and outputs must pick one of these three data types :
uri_file — exactly one file, any format (CSV, Parquet, PNG, pickle, JSON). In v2 the job maps that file , not a parent folder you then os.path.join .
uri_folder — one directory. Canonical uses: a folder of Parquet or CSV files you load with pandas or Spark, or unstructured collections (images, audio, text, video) for deep learning.
mltable — Azure Machine Learning Tables. Use when the schema is complex or changes often, you need a subset of a large table, you run automated machine learning (AutoML) on tables, or files are spread across multiple storage locations . The materialization blueprint (which files, which read_delimited options, which filter / drop_columns ) lives in your storage as an MLTable file, so you can even use it disconnected from the workspace. Do not rename that file to MLTable.yaml ; the platform expects the name MLTable .
Embedded newlines inside quoted CSV fields are a classic misalignment bug. Register that file as mltable and set support_multi_line on read_delimited . A plain uri_file of CSV does not apply that transform.
You cannot change an asset’s type across versions. A wrong type means: archive the name, then create a new asset name with the correct type.
URIs, modes, and materialization versus reference
Supported path locations include a local folder, a datastore URI, a public https:// file, Blob ( wasbs:// ), Azure Data Lake Storage Gen2 ( abfss:// ), and Gen1 ( adl:// ). A job maps the URI onto the compute target filesystem using a mode :
Inputs: ro_mount (read-only mount), download , or direct (pass the URI string; your code talks to storage itself).
Outputs: rw_mount (read-write mount) or upload .
Reference is the default story for a data asset: metadata in the workspace, bytes in the original account. Materialization is what happens at job time — mount, download, or, for mltable , evaluate the blueprint ( eval_mount / eval_download ) so only the globbed files appear on the node. Azure Machine Learning’s data runtime (a lightweight Rust stack, no Java Virtual Machine) performs those mounts and table materializations with parallel load and background prefetch so GPUs are not stalled on disk.
Mount versus download is an operations choice: mounts stream; downloads pay copy time and local disk. direct is for code that already understands abfss:// and should not pretend the data is a local path.
- Create, version, tag, and consume
- A minimal data.yml for CLI v2: $schema: https://azuremlschemas.azureedge.net/latest/data.schema.json
- type: uri_folder
- name: claims-images
- version: "2026-08-15"
- description: Weekly claims photos through 15 Aug 2026
tags:
- medallion: silver
- sensitivity: nonPII
- path: azureml://datastores/adls_claims/paths/images/year=2026/week=33/
Submit with az ml data create -f data.yml . Python SDK v2 uses azure.ai.ml.entities.Data with type=AssetTypes.URI_FOLDER (or URI_FILE / MLTABLE ) and ml_client.data.create_or_update . Studio can create uri_file and uri_folder ; mltable authoring is still stronger in the SDK.
A finished command job can register its output by setting name on the output. That is how a preprocessing step publishes job_output_titanic_asset without a separate az ml data create .
Versioning practice that survives ETL: store data in time-partitioned folders ( year=2026/week=33 ) and, for tables or multi-folder image sets, freeze the included partitions inside an MLTable path list. Version 20260815 keeps last week’s glob even after week 34 lands. If you instead point uri_folder at a directory your overnight job overwrites , the asset identity is immutable but the bytes are not — reproducibility is a lie.
Tags are mutable extra metadata ( az ml data update --set tags.medallion=gold ). Use them for lakehouse medallion stage, sensitivity:PII , or RAI_audit:approved . Lineage in Studio lists jobs that consumed the asset, which is the first place you look when a pipeline regresses.
Lifecycle: why you cannot delete
Data asset deletion is not supported. Microsoft’s reasons are operational, not pedantic: production jobs would start failing, experiments would not reproduce, lineage graphs would have holes, and audit trails would lie. If the name is ugly or the team moved on, archive ( az ml data archive --name ... ). Archived assets hide from default lists but still run. Restore with az ml data restore . If the path is wrong, create a new version with the same name. If the type is wrong, archive and start a new name.
Exam scenario
A claims team drops JPEG folders into Azure Data Lake Storage Gen2 every Sunday. A data scientist trained from a raw abfss:// URI pasted into a notebook, using a personal shared access signature in the script. Six weeks later the signature expired, the production pipeline failed, and nobody could prove which week of images trained model claims-seg-12 . The MLOps fix is: create an identity-based datastore to that filesystem, register uri_folder (or mltable-of-paths) data assets named by week ( claims-images:2026-08-15 ), and pass azureml:claims-images:2026-08-15 into the training component. Credentials leave the script; lineage in Studio shows the asset on the job.
Common trap
Do not treat “I created a data asset” as “I snapshot-copied the lake.” Unless the create used a local path , you stored a pointer . Pair immutable asset versions with immutable paths (or an MLTable path list). Also do not confuse this with the workspace model registry or with Azure Machine Learning registries in section 3.4 — those share assets across workspaces; a workspace data asset is local until you promote it.