Study guide
4.4 Restrict Network Access to Machine Learning Workspaces
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.4 Restrict Network Access to Machine Learning Workspaces
Key Takeaways Explain This Topic AI
Managed virtual network isolation secures outbound traffic from workspace-managed computes (instances, clusters, serverless, managed online endpoints). Inbound access is secured with a private endpoint you place on an Azure Virtual Network you own. Isolation modes are allow_internet_outbound, allow_only_approved_outbound, and disabled.
After allow internet outbound you cannot go back to disabled, and SDK v2 documents that you cannot later change that workspace to allow only approved outbound. After allow only approved outbound you cannot switch to allow internet outbound. Once either managed-network mode is on, you cannot turn managed VNet isolation off. Use managedNetworkKind v1; v2 is preview.
Disable public network access on the workspace (and typically on default storage, Key Vault, and ACR) and connect with private endpoints. Studio notebooks need a client-side private or service endpoint to default storage. ACR in a VNet cannot build images itself — set image_build_compute to a cluster or instance.
Managed VNet provisioning is deferred until the first compute (about 30 minutes) unless you pass --provision-network-now or az ml workspace provision-network. Serverless Spark requires spark_enabled on the storage private-endpoint rule and provision-network --include-spark. FQDN outbound rules use Azure Firewall and add cost.
Register Microsoft.Network. After 30 April 2025, grant the workspace managed identity Azure AI Enterprise Network Connection Approver (or a custom equivalent) so it can approve private endpoint connections. Updating an existing workspace to a managed VNet requires deleting compute instances, clusters, and managed online endpoints first.
Last updated: August 2026
Restrict Network Access to Machine Learning Workspaces
Quick Answer: Inbound = a private endpoint on your Azure Virtual Network plus public_network_access: Disabled . Outbound from managed compute = the workspace managed virtual network in mode allow_internet_outbound , allow_only_approved_outbound , or disabled . Set image_build_compute when ACR is private. Spark needs spark_enabled and az ml workspace provision-network --include-spark . Isolation mode changes are one-way .
The last Domain 1 IaC bullet is restrict network access to Machine Learning workspaces . Chapter 2 introduced workspaces; this section is the network envelope around them. Microsoft’s 2026 managed-network article is the source of truth for SDK/CLI v2 .
Two directions, two networks
People fail exam items by mixing inbound and outbound.
Inbound (who can call the workspace, Studio, and scoring URLs): an Azure Virtual Network you create . You add a private endpoint ( group-id amlworkspace ) and private DNS ( privatelink.api.azureml.ms , privatelink.notebooks.azure.net ). Set workspace public_network_access to Disabled so the public IP is not a back door. Microsoft also documents Enabled from selected IPs as a middle setting — still not a substitute for a private endpoint in a regulated landing zone.
Outbound (where compute instances, clusters, serverless compute, and managed online endpoints may send packets): the managed virtual network Azure Machine Learning creates for the workspace . You do not peer it like a customer VNet you fully own; you pick an isolation mode and outbound rules .
You can still use only a customer VNet (legacy “secure the workspace with your own VNet” article). Microsoft now recommends managed network isolation for outbound because it auto-secures managed computes.
Use managedNetworkKind v1 . Microsoft says do not use v2 , which is preview .
Isolation modes
Mode (YAML / CLI) Portal wording Outbound behavior Typical scenario
allow_internet_outbound Private with Internet Outbound All internet outbound allowed; you can still add private endpoint rules so Azure PaaS is private Need pypi.org , public model hubs, unrestricted package install
allow_only_approved_outbound Private with Approved Outbound Only service tags , FQDNs , and private endpoints you (and the platform default rules) allow Reduce data exfiltration; you prepared packages privately
disabled Use my own VNet / public Managed VNet not restricting; public in/out or you handle isolation yourself Sandbox, or classic customer VNet
- CLI: az ml workspace create -n ws -g rg --managed-network allow_internet_outbound --provision-network-now
- # or
- az ml workspace create -f workspace.yml -g rg
YAML: managed_network:
isolation_mode: allow_only_approved_outbound
outbound_rules:
- name: storage-pe
- type: private_endpoint
destination:
- service_resource_id: /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<sa>
- subresource_target: blob
- spark_enabled: true
- name: pypi
- type: fqdn
- destination: pypi.org
Service tag and FQDN rules are valid only in allow_only_approved_outbound . FQDN rules are implemented with Azure Firewall (Standard pricing) . The first FQDN rule adds about 10 minutes to provisioning. Extra FQDN rules can increase exfiltration risk; Microsoft does not guarantee exfiltration protection once you add them.
Default private endpoint rules are created automatically:
In allow internet outbound , for workspace, storage, Key Vault, and ACR when those resources have public network access disabled .
In allow only approved outbound , for those resources regardless of their public network access setting.
Register Microsoft.Network . The deploying identity needs Microsoft.MachineLearningServices/workspaces/privateEndpointConnections/read and write .
Irreversible choices (memorize):
allow_internet_outbound → cannot go to disabled . The Python SDK v2 Spark notes also state you cannot later update that workspace to allow_only_approved_outbound .
allow_only_approved_outbound → cannot go to allow_internet_outbound .
Either managed mode → cannot disable managed virtual network isolation later.
Before updating an existing workspace onto a managed VNet, delete compute instances, compute clusters, and managed online endpoints .
Private endpoints on dependents, Studio, and image build
When storage, Key Vault, or ACR disable public access, also allow trusted Microsoft services (or resource-instance exceptions) as documented for each service, or the control plane cannot reach them.
Azure Machine Learning studio runs part of the dataset/notebook experience in the browser , talking directly to default storage . Clients therefore need a private endpoint or service endpoint to that storage in the client VNet . If storage public access is disabled, grant the Reader role on the client storage private endpoint to the workspace managed identity (blob and file). That is separate from the managed-VNet’s own private endpoints.
You cannot use a private endpoint and a service endpoint at the same time on the same storage account. Microsoft recommends private endpoints .
Image builds: if ACR is behind a virtual network, ACR Tasks cannot build . Set image_build_compute to a compute cluster or compute instance that can reach your package repositories: az ml workspace update -n ws -g rg --image-build-compute cpu-build
In approved-outbound mode you may need extra FQDN or private-package rules so the build compute can pip / conda . Do not invent GPU SKU names for that cluster; pick a documented Standard_* size that exists in the region (Chapter 2).
CLI v2 from a locked-down laptop still sends YAML metadata to public ARM unless you build an ARM private link. Data in a VNet datastore is not copied onto the public internet by that control-plane call.
Provisioning time, Spark, and identity to approve connections
Managed VNet creation is deferred until the first compute or until you provision explicitly. The first compute can take about 30 minutes because it is also creating the network; a large outbound-rule set can time out. Prefer: az ml workspace provision-network -g rg -n ws
# Spark:
az ml workspace provision-network -g rg -n ws --include-spark
or --provision-network-now / provision_network_now: true at create. Managed online endpoint deploys require the managed network to exist first (provision or create a compute instance).
If public network access is still enabled when you provision, workspace private endpoints inside the managed VNet may not auto-create — disable public access first.
Serverless Spark jobs need all of: managed VNet configured, a storage private endpoint outbound rule with spark_enabled: true , and provision-network --include-spark . Portal can tick Spark on a rule at create; existing workspaces use CLI/SDK. Under allow only approved outbound , conda packages in the Spark session fail to install ; Microsoft’s workaround is a self-contained wheel on storage via private endpoint ( py_files ), not an FQDN rule (Spark does not propagate FQDN rules).
After 30 April 2025 , the workspace managed identity is not auto-granted rights to approve private endpoint connections. Assign Azure AI Enterprise Network Connection Approver (covers storage, Key Vault, ACR, Azure Machine Learning, Foundry, and the other listed PaaS types) or a custom role. Creating PEs to types not on that list (Data Factory, Databricks, Function Apps) needs extra actions.
Associated resources in a VNet: Key Vault, Storage, ACR as in the managed-network table; Application Insights still does not sit in the VNet (section 4.2).
Exam scenario
A bank requires no public workspace endpoint and no uncontrolled internet from training nodes. An engineer sets --managed-network allow_internet_outbound , leaves public_network_access enabled, and wonders why Studio cannot list blobs. They then try to “tighten” the same workspace to allow_only_approved_outbound without deleting computes. The MLOps design is: create with allow_only_approved_outbound , public_network_access: Disabled , private endpoints on workspace/storage/KV/Premium ACR, client PE to storage for Studio, image_build_compute: cpu-build , --provision-network-now , and Azure AI Enterprise Network Connection Approver on the workspace identity. Spark gets a spark_enabled blob PE and --include-spark before the first Spark job.
Common trap
Do not say you will “switch prod from allow only approved outbound back to allow internet outbound for the weekend.” You cannot. Do not skip image_build_compute when ACR is private — environment builds fail. Do not assume Spark works because the managed VNet exists; without spark_enabled and --include-spark it does not. Do not invent unpublished SKU names for firewall or compute. Do not use managedNetworkKind v2 as the GA answer.