Study guide
10.3 Foundry Network Security and Private Networking
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
10.3 Foundry Network Security and Private Networking
Key Takeaways Explain This Topic AI
Plan three isolation surfaces: inbound access to the Foundry resource, outbound from Foundry PaaS (Private Link to Storage, Search, Key Vault), and outbound from the Agent client via virtual-network injection.
Public network access can be Disabled, enabled from selected IP addresses, or All networks. A private endpoint on the account (portal label) is how clients on a virtual network reach a locked resource. Removing a private endpoint does not make the resource public.
Private DNS for Foundry uses privatelink.cognitiveservices.azure.com, privatelink.openai.azure.com, and privatelink.services.ai.azure.com. A Foundry resource can expose all three public suffixes; configure a zone for each endpoint the workload uses.
Agent Service and evaluations that need end-to-end isolation use VNet injection into a customer subnet delegated to Microsoft.App/environments, size /27 or larger, or a platform-managed virtual network. You cannot add or change outbound injection after deploy — redeploy. Connected-resource private endpoints are not auto-created.
Trusted Azure services you can except while keeping network rules are Foundry Tools (Microsoft.CognitiveServices), Azure AI Search (Microsoft.Search), and Azure Machine Learning (Microsoft.MachineLearningServices), each still authenticated with managed identity plus RBAC. Do not use 172.17.0.0/16 for the virtual network.
Last updated: August 2026
Foundry Network Security and Private Networking
Quick Answer: Disable public network access , attach a private endpoint to the Foundry account , and link private DNS zones ( privatelink.services.ai.azure.com , privatelink.openai.azure.com , privatelink.cognitiveservices.azure.com ). For agents, inject the Agent client into a BYO subnet delegated to Microsoft.App/environments ( /27 or larger) or use a managed virtual network . Private endpoints to Search, Storage, and Cosmos DB are not created for you. Removing a private endpoint does not enable public access.
Domain 3's third platform bullet is implement network security and private networking configurations . Chapter 4 covered Azure Machine Learning isolation (workspace private endpoint plus managed outbound). Foundry reuses Private Link ideas but adds Agent Service virtual-network injection and a different DNS suffix list.
Three isolation surfaces
Microsoft asks you to plan isolation in three places:
Inbound to the Foundry resource — data scientists, CI, and apps reaching the account and projects.
Outbound from Foundry PaaS — the account talking to Storage, Key Vault, container registry, monitoring, and Search over Private Link.
Outbound from the Agent client — the injected Agent runtime reaching private data sources and Azure PaaS without traversing the public internet.
Inbound is the public network access (PNA) flag plus optional private endpoints. PNA values:
Disabled — only private endpoints (and the trusted-services exception if you enable it).
Enabled from selected IP addresses — named IPs and virtual networks, a middle setting between public and private.
All networks — the public endpoint is back. Existing private endpoints keep working ; you have added a public path, not removed the private one.
Create the private endpoint while creating the resource (Networking tab → Disabled → Add private endpoint ) or later under Resource Management → Networking → Private endpoint connections . In the portal the target is labeled account — select the Foundry resource. The endpoint must sit in the same region as the virtual network. You need Network Contributor on the virtual network and Contributor or Owner on the Foundry resource to approve the connection. Without approval the connection stays Pending and carries no traffic. Only Approved private endpoints send traffic.
Trap: deleting the private endpoint to "open the firewall." Removal disconnects that virtual network; PNA stays Disabled . To allow the public internet you must set All networks (Firewalls and virtual networks tab) and Save.
DNS: same connection string, different IP
Clients inside and outside the virtual network use the same Foundry connection string. Azure updates the public CNAME to a privatelink alias. Inside the linked virtual network, that name resolves to the private IP . Outside, it still resolves to the public endpoint (which is blocked if PNA is Disabled).
A Foundry resource can expose three public suffixes. Configure a private DNS zone for each suffix you actually call:
- Public suffix Private DNS zone
- cognitiveservices.azure.com privatelink.cognitiveservices.azure.com
- openai.azure.com privatelink.openai.azure.com
- services.ai.azure.com privatelink.services.ai.azure.com
Link those zones to the virtual network. Custom DNS servers must forward the privatelink subdomains to Azure DNS ( 168.63.129.16 ) or host matching A records. Validate from a jump box: nslookup <foundry-hostname> must return the private IP, then Test-NetConnection <private-ip> -Port 443 .
If DNS still returns a public IP, the zone is missing or not linked — that is the usual "Private Link is Approved but the SDK times out or 403s" ticket.
On-premises clients reach the private endpoint through VPN Gateway (point-to-site or site-to-site), ExpressRoute , or an Azure Bastion jump VM on the virtual network. Do not use the 172.17.0.0/16 range; Docker bridge networking reserves it.
Trusted Azure services
When PNA is restricted, you can still allow a documented subset of Azure services to reach Foundry if their managed identity has RBAC. Microsoft lists:
- Foundry Tools — Microsoft.CognitiveServices
- Azure AI Search — Microsoft.Search
- Azure Machine Learning — Microsoft.MachineLearningServices
Create the exception with the REST API or Azure portal network rules. This is not "any Azure service." It is also not a substitute for a private endpoint when the caller is your virtual network.
Agent Service: managed VNet versus BYO VNet
PaaS Private Link is not enough once you run prompt agents , hosted agents , or evaluations and your security team wants outbound isolation. Foundry then injects the Agent client into a subnet.
Model How it works When to choose it
Customer-managed / BYO VNet You provide a virtual network and a subnet delegated to Microsoft.App/environments , size /27 or larger . The platform injects into that subnet. You already have a hub-and-spoke network, Azure Firewall, and private endpoints on Search/Storage/Cosmos DB.
Managed virtual network Foundry manages the virtual network. Faster onboarding; less customization.
Portal create path: Storage tab (Basic = Microsoft-managed agent data; Standard = BYO Storage, Azure AI Search, Cosmos DB so data stays in your tenant) → Network tab → PNA Disabled plus inbound private endpoint → Virtual network injection dropdown → pick the delegated subnet.
Hard limits from the 2026-08-14 networking article:
You cannot change the delegated subnet later, and you cannot add outbound injection to an existing Foundry resource. Redeploy.
Private endpoints to Search, Storage, and Cosmos DB are not auto-created. Create them on those resources yourselves.
Standard setup is what private-network Agent deployments expect; Basic keeps agent state in Microsoft-managed multi-tenant storage.
Some agent tools stay on the public internet even in a private Foundry (Bing Grounding, Websearch, SharePoint Grounding). Code Interpreter and Function Calling stay on the Microsoft backbone. MCP, Azure AI Search, OpenAPI, Azure Functions, and A2A can traverse your subnet. Logic Apps, Browser Automation, Computer Use, and Image Generation are not supported in network-isolated environments as of the current article. Do not over-claim tool support on the exam.
Workflow Agents: inbound isolation yes; outbound VNet injection not currently supported.
Hosted agents with a private Azure Container Registry (PNA disabled + private endpoint) are supported for Foundry projects created after 25 June 2026 ; older projects need a publicly reachable registry.
If you front the spoke with Azure Firewall, allowlist documented FQDNs such as *.identity.azure.net and login.microsoftonline.com (Agent Container Apps), *.blob.core.windows.net and settings.sdk.monitor.azure.com (evaluations and traces).
Classic hubs: one private endpoint, managed VNet only
A hub shares one managed virtual network with all hub-based projects. You create one private endpoint on the hub , not one per project. Hub workspaces do not support BYO virtual network ; Microsoft's hub matrix says use the managed virtual network instead. Encryption and network flags on the hub flow down. That is a different knob set from Foundry-resource Agent injection — do not mix the two diagrams on one answer.
Exam scenario
A bank disables public network access on a new Foundry resource, approves a private endpoint, and injects Agent Service into snet-foundry-agents ( /27 , delegated to Microsoft.App/environments ). Agents still cannot query Azure AI Search. Search PNA is also Disabled.
Create a Search private endpoint on the same virtual network, link privatelink.search.windows.net , grant the project managed identity a Search data-plane role, and use an Entra ID connection. If ingestion uses a Search indexer, set indexer executionEnvironment to Private or the indexer stays multitenant and silently fails. Do not "fix" this by enabling All networks on Foundry.
Common trap
Assuming the Foundry private endpoint also privatizes Search and Storage. Connected resources have separate governance. A second trap is changing injection after go-live — you cannot; you redeploy. A third is hub BYO VNet: hubs use managed VNets. A fourth is treating Bing Grounding as a private tool; it still uses a public endpoint, so Azure Policy may need to block it if the standard is "no public egress."