Try 10 focused Microsoft AI-300 questions on MLOps infrastructure, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
Try Microsoft AI-300 on Web View full Microsoft AI-300 practice page
| Field | Detail |
|---|---|
| Exam route | Microsoft AI-300 |
| Topic area | MLOps Infrastructure |
| Blueprint weight | 19% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate MLOps infrastructure for Microsoft AI-300. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 19% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Design and Implement an MLOps Infrastructure
An ML operations team maintains Azure Machine Learning pipeline component YAML files and Bicep templates for workspace resources. Auditors need to see who changed each file and why, but the team does not want changes to automatically provision resources or run training jobs. Which configuration best matches this requirement?
Options:
A. Publish the component YAML files to an Azure Machine Learning registry.
B. Deploy the Bicep templates from a GitHub Actions workflow on pull request.
C. Run az ml job create from a GitHub Actions workflow on push.
D. Store the files in a Git repository and require pull requests.
Best answer: D
Explanation: Git source control is the right fit when the requirement is version history, authorship, diffs, and review of files such as component YAML and Bicep templates. GitHub Actions is for automation: running commands, provisioning infrastructure, starting training jobs, or deploying assets when a workflow event occurs. In this scenario, the team specifically wants auditability without automatic execution, so using a Git repository with pull requests matches the behavior. Automation can be added later with GitHub Actions if the team decides that approved changes should trigger Azure CLI or Bicep deployment steps.
Topic: Design and Implement an MLOps Infrastructure
A platform team maintains separate Azure Machine Learning workspaces for development, test, and production. A shared preprocessing component and its environment must be versioned once and reused by training pipelines in all three workspaces. The team wants to avoid manually copying or republishing the assets into each workspace.
Which implementation should the team use?
Options:
A. Publish the component and environment to an Azure Machine Learning registry.
B. Create the component as a local asset in the development workspace.
C. Register the trained model in the production workspace only.
D. Store the component files in a workspace datastore.
Best answer: A
Explanation: Azure Machine Learning registries are the appropriate mechanism for cross-workspace reuse of versioned assets such as components, environments, and models. In this scenario, the same preprocessing component and environment must be maintained once and consumed by pipelines in development, test, and production workspaces. Publishing those assets to a registry lets each workspace reference the same named versions without creating separate local copies.
Local workspace assets are useful when an asset is intended for one workspace. A datastore can hold files, but it does not provide the same governed, versioned cross-workspace asset catalog behavior. The key distinction is asset scope: registry for shared reuse, local workspace asset for workspace-specific use.
Topic: Design and Implement an MLOps Infrastructure
A team provisions an Azure Machine Learning workspace and related resources from GitHub Actions by running a Bicep deployment. The workflow uses OIDC with azure/login. The job fails before the workspace is created.
Log excerpt:
Run azure/login@v2
Login successful. Tenant: <tenant-id>
Run az deployment group create --resource-group mlops-rg --template-file infra/main.bicep
ERROR: AuthorizationFailed: The client '<app-id>' with object id '<object-id>'
does not have authorization to perform action
'Microsoft.MachineLearningServices/workspaces/write' over scope
'/subscriptions/<sub-id>/resourceGroups/mlops-rg'.
What is the best root cause to investigate first?
Options:
A. The workspace managed identity lacks datastore access
B. The Bicep file has invalid workspace syntax
C. The GitHub OIDC principal lacks resource group RBAC
D. The private endpoint DNS zone is misconfigured
Best answer: C
Explanation: The evidence points to an Azure RBAC authorization failure for the identity used by GitHub Actions. Because azure/login completed successfully, the OIDC federation and tenant authentication are working. The failure occurs when az deployment group create tries to create an Azure Machine Learning workspace, and the error names the exact missing action: Microsoft.MachineLearningServices/workspaces/write at the resource group scope. The next diagnostic step is to check whether the federated service principal or managed identity used by the workflow has an appropriate role, such as Contributor or a custom role including that action, on mlops-rg or a parent scope. This is different from runtime workspace identity permissions, which apply after the workspace exists.
AuthorizationFailed, not a template validation or parsing failure.Topic: Design and Implement an MLOps Infrastructure
A team is provisioning an Azure Machine Learning workspace with Bicep. Training pipelines will run on an Azure Machine Learning compute cluster and read Parquet files from one ADLS Gen2 container named training-data. The security requirement is to avoid storage keys, SAS tokens, and user-dependent access while granting the minimum required data access. Which implementation should you use?
Options:
A. Assign a user-assigned managed identity to the compute cluster and grant it Storage Blob Data Reader on training-data.
B. Grant each data scientist Reader on the storage account resource group.
C. Store a SAS token in the datastore and reference it from each pipeline job.
D. Grant the workspace system-assigned identity Storage Blob Data Owner on the storage account.
Best answer: A
Explanation: For secure Azure Machine Learning job access to storage, use managed identity and Azure RBAC at the narrowest practical scope. A compute cluster identity is appropriate because the training job runs on that compute and must access the ADLS Gen2 data without relying on a user’s interactive permissions. Granting Storage Blob Data Reader on only the training-data container provides the needed data-plane read permission without storage keys, SAS tokens, or broad account-level access. The key distinction is data-plane access to blobs, not management-plane access to the storage account.
Topic: Design and Implement an MLOps Infrastructure
A team trains a model in an Azure Machine Learning workspace named ml-dev. A GitHub Actions workflow then deploys a managed online endpoint in a separate workspace named ml-prod by referencing the same model name and version. The deployment fails with: Model asset credit-risk:7 was not found in workspace ml-prod. What is the most likely root cause?
Options:
A. The datastore path changed after training completed.
B. The model asset is scoped to ml-dev, not ml-prod.
C. The compute target is missing from ml-dev.
D. The endpoint must be deployed in the training workspace.
Best answer: B
Explanation: An Azure Machine Learning workspace is the coordination boundary for model lifecycle and operational assets such as models, environments, components, jobs, endpoints, and related metadata. The visible error says the deployment is looking for credit-risk:7 in ml-prod, but the model was registered in ml-dev. Being in the same subscription does not make workspace-scoped assets automatically available across workspaces. The next diagnostic check is whether the model version exists in the target workspace or has been promoted through an Azure Machine Learning registry or an equivalent controlled registration process. The issue is asset scope, not endpoint type or datastore access.
ml-prod.Topic: Design and Implement an MLOps Infrastructure
An Azure Machine Learning training job fails when reading a registered data asset from a datastore. The team must identify the most likely configuration issue before changing storage permissions.
Exhibit:
Datastore: rawdata
Backed by: storage account container ml-data
Access identity: workspace managed identity
RBAC: Storage Blob Data Reader on the storage account
Job input URI: azureml://datastores/rawdata/paths/training/2026/*.parquet
Storage browser shows: ml-data/train/2026/part-0001.parquet
Error: Authentication succeeded, but no files matched the requested path.
Which configuration change should the team make?
Options:
A. Recreate the datastore with an account key.
B. Update the input path to train/2026/*.parquet.
C. Grant the user Storage Blob Data Contributor.
D. Change the compute cluster VM size.
Best answer: B
Explanation: This failure points to the referenced path, not the datastore or identity. The datastore resolves to the correct container, and the workspace managed identity already has read access. The error also states that authentication succeeded, which rules out the most common identity/RBAC problem. The remaining mismatch is between the job input URI, which requests training/2026/*.parquet, and the actual files, which are under train/2026/. In Azure Machine Learning, datastore paths must match the container-relative folder structure used by the backing storage. Changing credentials or compute settings would not make a nonexistent path match files.
Topic: Design and Implement an MLOps Infrastructure
An Azure Machine Learning pipeline in the prod-ml workspace fails before the training script starts. The input is configured as azureml://datastores/churn_raw/paths/2026/05/train/.
Diagnostic evidence:
| Check | Result |
|---|---|
Datastore churn_raw | Exists in prod-ml |
| Datastore auth | Workspace managed identity |
| Error | AuthorizationPermissionMismatch for workspace managed identity object ID |
| Storage RBAC | Compute identity has Blob Data Reader; workspace managed identity has no storage role |
What is the most likely root cause?
Options:
A. The compute target cannot mount any Azure Blob datastore.
B. The pipeline input URI should use a direct abfss:// path.
C. The workspace managed identity lacks storage data-plane permissions.
D. The data asset version is missing from the workspace.
Best answer: C
Explanation: Azure Machine Learning datastores provide managed connections to storage for jobs and pipelines. In this case, the datastore exists and the pipeline is using an azureml://datastores/... URI, so the failure is not caused by a missing datastore reference. The evidence shows the datastore authenticates with the workspace managed identity, and the authorization error names that same identity. Because only the compute identity has Blob Data Reader, the identity actually used by the datastore does not have the required data-plane permission on the storage container.
Grant the datastore’s configured identity the appropriate storage role, or reconfigure the datastore to use an identity that already has access.
azureml://datastores/... is the managed Azure Machine Learning datastore reference pattern.Topic: Design and Implement an MLOps Infrastructure
A team is preparing an Azure Machine Learning training pipeline that must run repeatably against the same approved snapshot of training data. The data is stored in an Azure Storage account that the workspace can access. Which configuration should the team use?
Options:
A. Create a new datastore for each training data version
B. Use the datastore path directly in every pipeline job
C. Copy the files to the compute target before each run
D. Create a datastore, then register a versioned data asset
Best answer: D
Explanation: In Azure Machine Learning, a datastore is the workspace-level connection to an external storage service, such as Azure Blob Storage or Azure Data Lake Storage. It manages how the workspace reaches the storage location, but it is not itself a versioned dataset. For repeatable workflows, create a data asset that references the required path or files and assign it a version. Pipeline jobs can then use that specific data asset version, making the run reproducible even if other data appears later in the storage account.
The key distinction is connection versus governed input: datastore for access, versioned data asset for repeatable ML workflow inputs.
Topic: Design and Implement an MLOps Infrastructure
A platform team maintains reusable Azure Machine Learning components and environments for several project workspaces. A release pipeline must allow each workspace to reuse the same approved assets while preserving the exact asset version used in every training job for audit purposes. Which configuration should the team use?
Options:
A. Use one shared compute cluster for all workspaces
B. Publish assets to an Azure Machine Learning registry and reference explicit versions
C. Store component YAML files in a shared datastore path
D. Copy assets into each workspace and overwrite the default version
Best answer: B
Explanation: Azure Machine Learning registries are designed for sharing assets such as components, environments, and models across workspaces. To keep reuse traceable, jobs should reference registry assets by name and explicit version rather than relying on a mutable local copy or a latest/default alias. This lets each consuming workspace run approved assets while the job metadata remains tied to the exact asset version used. Copying files or centralizing compute may support operations, but it does not provide cross-workspace asset version governance by itself.
The key takeaway is to combine registry-based sharing with pinned asset versions.
Topic: Design and Implement an MLOps Infrastructure
A platform team maintains standard Azure Machine Learning components and environments for training pipelines. Three product teams use separate dev, test, and prod workspaces and must reuse the same approved asset versions without copying definitions manually into each workspace. Which implementation best meets this requirement?
Options:
A. Register the assets only in the prod workspace
B. Publish versioned assets to an Azure Machine Learning registry
C. Create one datastore in each workspace
D. Store component YAML files only in a GitHub repository
Best answer: B
Explanation: Azure Machine Learning registries are designed for sharing reusable assets across workspaces and environments. The platform team can publish approved versions of components, environments, and models to a registry, then product teams can reference those registry assets from their own dev, test, and prod workspaces. This preserves version control and avoids manual copying of asset definitions between workspaces.
A Git repository is useful for source control, but the operational reuse mechanism for Azure Machine Learning assets across workspaces is the registry.
Use the Microsoft AI-300 Practice Test page for the full IT Mastery practice bank, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Try Microsoft AI-300 on Web View Microsoft AI-300 Practice Test
Read the Microsoft AI-300 Cheat Sheet for compact concept review before returning to timed practice.