ExamFinch.com My Study

Study guide

4.2 Deploy Workspaces and Resources with Bicep and Azure CLI

Practice this exam

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

4.2 Deploy Workspaces and Resources with Bicep and Azure CLI

Key Takeaways Explain This Topic AI

Bicep is Azure Resource Manager (ARM) with a concise syntax: one template can create the workspace plus Azure Storage, Key Vault, Application Insights, Azure Container Registry, virtual networks, and private endpoints. ARM JSON is what Bicep compiles to. Terraform is common in the MLOps v2 accelerator. az ml CLI v2 manages workspace YAML and ML assets.

Create a workspace from YAML with az ml workspace create -f workspace.yml (or az ml workspace create -n -g to auto-create dependents). Create compute with az ml compute create. Pin a default workspace with az configure --defaults.

The default storage account cannot be Premium_LRS or Premium_GRS and cannot enable hierarchical namespace (Azure Data Lake Storage Gen2). After Azure Container Registry is attached, do not delete it — the workspace becomes inoperative.

IaC is idempotent: redeploying the same Bicep parameters converges on the same resources. Parameterize environment (dev/test/prod) for names, SKUs, publicNetworkAccess, and managed-network isolation. Do not hard-code a single workspaceName in source.

Register Microsoft.MachineLearningServices in any subscription that holds dependent resources. For managed virtual networks also register Microsoft.Network. ACR behind a virtual network requires the Premium SKU. Application Insights is not deployed inside a virtual network.

Last updated: August 2026

Deploy Workspaces and Resources with Bicep and Azure CLI

Quick Answer: Bicep (compiled Azure Resource Manager (ARM) JSON) declares the workspace and Azure dependents — storage, Key Vault , Application Insights , Azure Container Registry (ACR) , virtual networks, private endpoints. az ml workspace create -f workspace.yml and az ml compute create are CLI v2 for workspace settings and ML compute. Parameterize dev / test / prod . Do not use Premium or hierarchical-namespace storage as the default account.

Exam AI-300 Domain 1 asks you to deploy Machine Learning workspaces and resources by using Bicep and Azure CLI . Clicking Create in the portal is how you learn the resource graph once. Production repeats that graph with infrastructure as code (IaC) so a reviewer can see that prod has publicNetworkAccess: Disabled and that dev does not share the prod Key Vault.

Four tools — pick by layer

Tool What it is What you use it for in AI-300

Bicep Microsoft DSL that compiles to ARM. Native modules, parameters, existing resource references Workspace + storage + Key Vault + App Insights + ACR + VNet + private endpoints. az deployment group create --template-file main.bicep

ARM template JSON. Bicep’s compilation target. Quickstart azuredeploy.json in microsoft.machinelearningservices/machine-learning-workspace-vnet Same resources when a pipeline already speaks ARM; keep API versions current ( Microsoft.MachineLearningServices/workspaces )

Terraform Multi-cloud. The MLOps v2 GitHub demo ships tf-gha-deploy-infra.yml Same Azure graph if the org standard is Terraform; still in scope as IaC, not a replacement for az ml job YAML

Azure CLI ml extension v2 az ml after az extension add -n ml (Azure CLI ≥ 2.38.0). Remove legacy azure-cli-ml first az ml workspace create -f workspace.yml , az ml workspace update , az ml compute create , then jobs, environments, endpoints

Bicep/ARM/Terraform own Azure control-plane resources . az ml owns workspace-shaped objects: the workspace record, compute, datastores, and every asset from Chapter 3. You typically check both into infra/ and jobs/ of the same Git repo (section 4.1). Do not try to express a training component in Bicep; do not try to express a hub virtual network only with az ml job .

az ml commands talk to Azure Resource Manager over HTTPS/TLS 1.2. That is expected for v2. If the workspace has a private endpoint and you refuse public ARM, you need an ARM private link (subscription Owner plus root management group Owner/Contributor) — a later networking concern, not a reason to stay on CLI v1.

Dependent resources the workspace always has

A workspace is not a single resource. Create in a resource group ( az group create -n rg -l eastus ) in a region where Azure Machine Learning exists.

Azure Storage — default datastore ( workspaceblobstore , workspacefilestore ). Default account rules: not Premium_LRS or Premium_GRS ; hierarchical namespace must be off (no Azure Data Lake Storage Gen2 on the default account). Blob and Azure Files must be available. Premium or HNS storage can still be non-default datastores (Chapter 2).

Azure Key Vault — secrets, compute SSH creds, some connection strings.

Application Insights — endpoint and workspace telemetry. Created with the workspace. If you delete it, the documented recovery is delete and recreate the workspace . App Insights is not deployed behind a virtual network.

Azure Container Registry — Docker images for environments. The workspace can lazy-create ACR on first image build. After ACR exists, do not delete it. Behind a virtual network, ACR must be Premium SKU. You may bring an existing registry; enable the admin account or (preferred) managed identity access.

If dependents live in another subscription , register Microsoft.MachineLearningServices in that subscription before the workspace can use them.

  • Minimal CLI create that auto-provisions dependents: az extension add -n ml
  • az ml workspace create -n mlw-claims-dev -g rg-claims-dev -l eastus
  • az configure --defaults group=rg-claims-dev workspace=mlw-claims-dev location=eastus

Bring-your-own dependents with workspace YAML : $schema: https://azuremlschemas.azureedge.net/latest/workspace.schema.json

  • name: mlw-claims-prod
  • location: eastus
  • storage_account: /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<sa>
  • key_vault: /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<kv>

container_registry: /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.ContainerRegistry/registries/<acr>

  • application_insights: /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.insights/components/<ai>
  • public_network_access: Disabled
  • image_build_compute: cpu-build

Deploy with az ml workspace create -g rg-claims-prod -f workspace.yml . You may specify only some ARM IDs and let the CLI create the rest. Get IDs with az storage account show --query id , az keyvault show --query id , az acr show --query id , az monitor app-insights component show --query id .

Bicep for the Azure graph

Bicep declares Microsoft.Storage/storageAccounts , Microsoft.KeyVault/vaults , Microsoft.Insights/components , Microsoft.ContainerRegistry/registries , then: resource workspace 'Microsoft.MachineLearningServices/workspaces@2024-10-01' = {

  • name: workspaceName
  • location: location
  • identity: { type: 'SystemAssigned' }
  • properties: {
  • friendlyName: workspaceName
  • storageAccount: storageAccount.id
  • keyVault: keyVault.id
  • applicationInsights: appInsights.id
  • containerRegistry: acr.id
  • publicNetworkAccess: 'Disabled'
  • }
  • }

Use a current API version from the REST docs; Quickstart samples lag. Deploy: az deployment group create -g rg-claims-prod --template-file main.bicep --parameters env=prod workspaceName=mlw-claims-prod

The Azure Quickstart machine-learning-workspace-vnet template also wires private endpoints , vnetOption new or existing , storageAccountBehindVNet , keyVaultBehindVNet , containerRegistryBehindVNet , and privateEndpointType AutoApproval or ManualApproval . It does not support multiple workspaces in the same VNet in one naive run because it creates DNS zones; export a portal deployment if you must share a VNet.

Customer-managed keys and high business impact ( hbi_workspace ) are create-time only in YAML ( customer_managed_key.key_vault + key_uri ; hbi_workspace: true ). You cannot flip them later — you create a new workspace.

  • Compute and other workspace resources as code
  • After the workspace exists: az ml compute create -f compute-cluster.yml
  • az ml compute create -f compute-instance.yml

YAML names the cluster, SKU, min/max nodes, and identity. Bicep can also emit compute child resources, but teams usually keep cluster size next to job YAML so data scientists can review it in the same pull request. Idempotence: az deployment group create with the same Bicep is safe to rerun. az ml workspace create on an existing name fails; use az ml workspace update -f workspace.yml for mutable settings ( --public-network-access , --image-build-compute , --managed-network ). az ml compute create is the create path; updates have their own commands.

Parameter files keep environments honest:

dev.bicepparam — public access enabled, small Standard_DS2_v2 cluster, no private endpoints.

prod.bicepparam — publicNetworkAccess: Disabled , managed network allow_only_approved_outbound (section 4.4), Premium ACR, private endpoints.

Never copy-paste a prod workspace name into a dev template. Names, locations, and SKUs are parameters .

Traps that break “idempotent” templates

ARM/Bicep redeploys of Key Vault can clear access policies if the template specifies an empty accessPolicies array. Notebook VMs and other workspace features then fail against that vault. Microsoft’s template article says: do not redeploy the same Key Vault blindly; pass existing accessPolicies , or reuse the vault by resource ID and do not recreate it. That is why many production templates take keyVaultId as a parameter after the first create.

Soft-delete on the workspace means az ml workspace delete is recoverable unless you purge. Deleting the resource group deletes dependents too — storage, vault, ACR — which is usually not what you want if other services share them.

Exam scenario

Contoso needs identical dev and prod Azure Machine Learning landing zones. An engineer clicks through the portal for prod, then runs az ml workspace create -n mlw-dev with auto dependents. Prod uses a Premium_LRS storage account “for speed.” Training fails on the default datastore. The MLOps fix is a Bicep module with parameters env , workspaceName , and publicNetworkAccess ; Standard_LRS (or Standard_GRS) without HNS for default storage; az ml workspace create -f workspace.yml only to attach those ARM IDs; az ml compute create for a named cpu-build cluster used as image_build_compute when ACR is private.

Common trap

Do not answer “Premium storage for the workspace default account” or “turn on Data Lake hierarchical namespace on the default store.” Those SKUs are unsupported for the default account. Do not delete ACR “to save money.” Do not put environment-specific workspace names in Bicep without parameters. Do not confuse az ml workspace create (workspace + optional dependents) with az deployment group create (full Azure graph including VNets).