🔒 Guided

Pre-launch preview. Authorised access only.

Incorrect code

Guided by A Guide to Cloud
Explore AB-900 AI-901
Guided AI-300 Domain 3
Domain 3 — Module 2 of 5 40%
15 of 25 overall

AI-300 Study Guide

Domain 1: Design and Implement an MLOps Infrastructure

  • ML Workspace: Your AI Control Room Free
  • Data, Environments & Components
  • Compute Targets: Choosing the Right Engine
  • Infrastructure as Code: Provisioning at Scale
  • Git & CI/CD for ML Projects

Domain 2: Implement Machine Learning Model Lifecycle and Operations

  • MLflow: Track Every Experiment Free
  • AutoML & Hyperparameter Tuning
  • Training Pipelines: Automate Everything
  • Distributed Training: Scale to Big Data
  • Model Registration & Versioning
  • Model Approval & Responsible AI Gates
  • Deploying Models: Endpoints in Production
  • Drift, Monitoring & Retraining

Domain 3: Design and Implement a GenAIOps Infrastructure

  • Foundry: Hubs, Projects & Platform Setup Free
  • Network Security & IaC for Foundry
  • Deploying Foundation Models
  • Model Versioning & Production Strategies
  • PromptOps: Design, Compare, Version & Ship

Domain 4: Implement Generative AI Quality Assurance and Observability

  • Evaluation: Datasets, Metrics & Quality Gates Free
  • Safety Evaluations & Custom Metrics
  • Monitoring GenAI in Production
  • Cost Tracking, Logging & Debugging

Domain 5: Optimize Generative AI Systems and Model Performance

  • RAG Optimization: Better Retrieval, Better Answers Free
  • Embeddings & Hybrid Search
  • Fine-Tuning: Methods, Data & Production

AI-300 Study Guide

Domain 1: Design and Implement an MLOps Infrastructure

  • ML Workspace: Your AI Control Room Free
  • Data, Environments & Components
  • Compute Targets: Choosing the Right Engine
  • Infrastructure as Code: Provisioning at Scale
  • Git & CI/CD for ML Projects

Domain 2: Implement Machine Learning Model Lifecycle and Operations

  • MLflow: Track Every Experiment Free
  • AutoML & Hyperparameter Tuning
  • Training Pipelines: Automate Everything
  • Distributed Training: Scale to Big Data
  • Model Registration & Versioning
  • Model Approval & Responsible AI Gates
  • Deploying Models: Endpoints in Production
  • Drift, Monitoring & Retraining

Domain 3: Design and Implement a GenAIOps Infrastructure

  • Foundry: Hubs, Projects & Platform Setup Free
  • Network Security & IaC for Foundry
  • Deploying Foundation Models
  • Model Versioning & Production Strategies
  • PromptOps: Design, Compare, Version & Ship

Domain 4: Implement Generative AI Quality Assurance and Observability

  • Evaluation: Datasets, Metrics & Quality Gates Free
  • Safety Evaluations & Custom Metrics
  • Monitoring GenAI in Production
  • Cost Tracking, Logging & Debugging

Domain 5: Optimize Generative AI Systems and Model Performance

  • RAG Optimization: Better Retrieval, Better Answers Free
  • Embeddings & Hybrid Search
  • Fine-Tuning: Methods, Data & Production
Domain 3: Design and Implement a GenAIOps Infrastructure Premium ⏱ ~14 min read

Network Security & IaC for Foundry

Enterprise GenAI needs enterprise security. Configure private endpoints, managed VNets, and deploy Foundry infrastructure with Bicep templates — repeatable and auditable.

Why network security matters for GenAI

☕ Simple explanation

Private endpoints are like a secret tunnel to your office.

Normally, when you visit a website, your request travels across the public internet — anyone could see where you’re going. A private endpoint builds a private tunnel between your office and the service. No public road. No one outside can see the traffic or even find the door.

For GenAI, this means your prompts, responses, and data never touch the public internet. They travel through Microsoft’s private backbone network — invisible to the outside world.

By default, Azure AI Foundry resources are accessible over the public internet. For enterprise workloads, this is unacceptable — particularly in regulated industries (finance, healthcare, government).

Azure provides three layers of network isolation:

  • Private endpoints — expose Azure services on a private IP inside your VNet. Traffic stays on the Azure backbone.
  • Managed virtual network — Azure creates and manages a VNet for the hub. All outbound traffic goes through managed private endpoints.
  • Bring-your-own VNet — you control the VNet, subnets, NSGs, and routing. Maximum control, maximum complexity.

Note: This module covers hub-based networking (Foundry classic). The same security concepts — private endpoints, managed VNets, and IaC — apply to both classic and new Foundry resources.

Network isolation options

Network isolation levels for Foundry
FeatureHow It WorksWho Manages the VNetBest For
Public AccessResources accessible over the internet with authenticationN/A — no VNetDevelopment, prototyping, non-sensitive workloads
Managed VNetAzure creates a VNet for the hub. Outbound uses managed private endpointsAzure manages it — you configure allow/deny rulesMost enterprise workloads — secure with minimal effort
BYO VNet (Private Endpoints)You deploy private endpoints into your own VNet. Full control of routing and NSGsYou manage everything — subnets, NSGs, DNS, routingHighly regulated industries needing full network control
💡 Exam tip: Managed VNet vs BYO VNet

The exam often asks you to choose between managed VNet and BYO VNet:

  • Managed VNet — simpler, faster to set up, Azure handles DNS and routing. Choose this when the requirement says “private networking” without specifying custom routing or NSGs.
  • BYO VNet — choose when the requirement mentions custom DNS, hub-spoke topology, on-premises connectivity via ExpressRoute, or NSG rules.

Default to managed VNet unless the scenario explicitly needs custom network control.

Configuring managed VNet for a hub

# Create a hub with managed VNet (internet outbound allowed)
az ml workspace create \
  --kind hub \
  --name hub-genai-prod \
  --resource-group rg-genai-prod \
  --location australiaeast \
  --managed-network allow_internet_outbound

# Create a hub with managed VNet (only approved outbound)
az ml workspace create \
  --kind hub \
  --name hub-genai-restricted \
  --resource-group rg-genai-prod \
  --location australiaeast \
  --managed-network allow_only_approved_outbound

What’s happening:

  • Lines 2-7: Creates a hub with managed VNet. allow_internet_outbound means the hub can reach the internet but all Azure services are accessed through managed private endpoints
  • Lines 10-15: Stricter option — allow_only_approved_outbound blocks all outbound traffic except explicitly approved destinations. Use this for maximum lockdown

Private endpoint Bicep template

For production deployments, define everything in Bicep:

// Foundry hub with private endpoint
param location string = resourceGroup().location
param hubName string = 'hub-genai-prod'
param vnetName string = 'vnet-genai-prod'
param subnetName string = 'snet-ai-endpoints'

resource vnet 'Microsoft.Network/virtualNetworks@2024-01-01' = {
  name: vnetName
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.0.0.0/16']
    }
    subnets: [
      {
        name: subnetName
        properties: {
          addressPrefix: '10.0.1.0/24'
          privateEndpointNetworkPolicies: 'Disabled'
        }
      }
    ]
  }
}

resource hub 'Microsoft.MachineLearningServices/workspaces@2024-10-01' = {
  name: hubName
  location: location
  kind: 'Hub'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    friendlyName: 'GenAI Production Hub'
    publicNetworkAccess: 'Disabled'
    managedNetwork: {
      isolationMode: 'AllowOnlyApprovedOutbound'
    }
  }
}

resource privateEndpoint 'Microsoft.Network/privateEndpoints@2024-01-01' = {
  name: 'pe-${hubName}'
  location: location
  properties: {
    subnet: {
      id: vnet.properties.subnets[0].id
    }
    privateLinkServiceConnections: [
      {
        name: 'plsc-${hubName}'
        properties: {
          privateLinkServiceId: hub.id
          groupIds: ['amlworkspace']
        }
      }
    ]
  }
}

resource dnsZoneGroup 'Microsoft.Network/privateEndpoints/privateDnsZoneGroups@2023-11-01' = {
  parent: privateEndpoint
  name: 'default'
  properties: {
    privateDnsZoneConfigs: [
      {
        name: 'config1'
        properties: {
          privateDnsZoneId: privateDnsZone.id
        }
      }
    ]
  }
}

resource privateDnsZone 'Microsoft.Network/privateDnsZones@2020-06-01' = {
  name: 'privatelink.api.azureml.ms'
  location: 'global'
}

resource dnsZoneLink 'Microsoft.Network/privateDnsZones/virtualNetworkLinks@2020-06-01' = {
  parent: privateDnsZone
  name: 'link-${vnetName}'
  location: 'global'
  properties: {
    virtualNetwork: {
      id: vnet.id
    }
    registrationEnabled: false
  }
}

What’s happening:

  • Lines 7-24: Creates a VNet with a dedicated subnet for private endpoints. privateEndpointNetworkPolicies: 'Disabled' is required for private endpoints to work in the subnet
  • Lines 26-41: Creates the Foundry hub with publicNetworkAccess: 'Disabled' — no public internet access at all
  • Lines 37-39: Sets isolation mode to only allow approved outbound connections
  • Lines 43-57: Creates a private endpoint in your subnet that connects to the hub via Azure Private Link
  • Lines 53-54: groupIds: ['amlworkspace'] specifies the sub-resource type for the private link connection
  • Lines 59-61: Private DNS zone ensures your VNet resolves the hub’s hostname to the private IP
  • Lines 63-73: Links the DNS zone to your VNet so DNS resolution works automatically
Scenario: Dr. Fatima implements private networking for Meridian

Dr. Fatima needs to satisfy CISO James Chen’s requirements at Meridian Financial:

  1. No public internet access to any GenAI resource
  2. All traffic must stay on the Azure backbone — prompts and responses never leave the private network
  3. Audit trail for all network configuration changes
  4. Repeatable deployment — every environment (dev, staging, prod) must be identical

Fatima’s implementation:

  • Bicep template defines the hub, VNet, private endpoints, and DNS zones as code. Stored in Git, deployed through CI/CD
  • Hub isolation: publicNetworkAccess: 'Disabled' + isolationMode: 'AllowOnlyApprovedOutbound'
  • Private endpoints for all services: Hub, Azure OpenAI, Storage, Key Vault, Azure AI Search all get private endpoints in the same VNet
  • DNS: Private DNS zones for each service, linked to the hub-spoke VNet topology
  • Azure Policy: Denies creation of any AI resource without private endpoints (Deny effect)

James Chen approves: every prompt, every response, every piece of data stays within Meridian’s private network perimeter.

Deploying Foundry infrastructure through CI/CD

# .github/workflows/deploy-foundry.yml
name: Deploy Foundry Infrastructure
on:
  push:
    branches: [main]
    paths: ['infra/**']

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4

      - name: Azure Login (OIDC)
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Deploy Hub and Networking
        uses: azure/arm-deploy@v2
        with:
          resourceGroupName: rg-genai-prod
          template: infra/main.bicep
          parameters: infra/params.prod.json
          failOnStdErr: false

      - name: Deploy Projects
        uses: azure/arm-deploy@v2
        with:
          resourceGroupName: rg-genai-prod
          template: infra/projects.bicep
          parameters: infra/project-params.prod.json
          failOnStdErr: false

What’s happening:

  • Lines 5-6: Only triggers when files in the infra/ folder change on the main branch
  • Lines 11-13: Uses OIDC (OpenID Connect) for passwordless authentication — no stored secrets
  • Lines 17-22: Logs in with federated credentials (workload identity federation)
  • Lines 24-30: Deploys the hub, VNet, and private endpoints first
  • Lines 32-38: Deploys projects after the hub is ready — projects depend on the hub existing

Key terms flashcards

Question

What is a private endpoint in Azure?

Click or press Enter to reveal answer

Answer

A private endpoint gives an Azure service a private IP address inside your VNet. Traffic between your VNet and the service stays on the Microsoft backbone network — never crosses the public internet. For Foundry, this means prompts and model responses are completely private.

Click to flip back

Question

Managed VNet vs BYO VNet for Foundry?

Click or press Enter to reveal answer

Answer

Managed VNet: Azure creates and manages the VNet, handles DNS and routing. Simpler. BYO VNet: you create the VNet, subnets, NSGs, DNS zones, and routing yourself. More control, more complexity. Choose managed unless you need custom routing, ExpressRoute, or hub-spoke topology.

Click to flip back

Question

What does publicNetworkAccess: Disabled do on a Foundry hub?

Click or press Enter to reveal answer

Answer

It blocks all access to the hub over the public internet. The hub can only be reached through private endpoints inside a VNet. This is the standard setting for enterprise production deployments.

Click to flip back

Knowledge check

Knowledge Check

Dr. Fatima needs to deploy a Foundry hub at Meridian Financial where all traffic stays on the Azure backbone and no public internet access is allowed. She also needs the deployment to be repeatable across dev, staging, and production. What should she do?

Knowledge Check

A Foundry hub needs private networking. The organization already has an ExpressRoute connection to Azure and a hub-spoke VNet topology with custom DNS servers. Which networking option should they choose?

🎬 Video coming soon


Next up: Deploying Foundation Models — choosing between serverless, managed compute, and provisioned throughput.

← Previous

Foundry: Hubs, Projects & Platform Setup

Next →

Deploying Foundation Models

Guided

I learn, I simplify, I share.

A Guide to Cloud YouTube Feedback

© 2026 Sutheesh. All rights reserved.

Guided is an independent study resource and is not affiliated with, endorsed by, or officially connected to Microsoft. Microsoft, Azure, and related trademarks are property of Microsoft Corporation. Always verify information against Microsoft Learn.