Set Up Foundry Solutions: Infrastructure, Deployments and CI/CD (AI-103)

Before you write any app code, you need the right Azure infrastructure, the right deployment type for each model, and a repeatable way to promote changes from dev to production. This lesson covers the Set up AI solutions in Foundry skill group.

The Foundry building blocks

• Foundry resource: the top-level Azure resource (kind AIServices). It holds model deployments, Foundry Tools endpoints, networking, keys and identity settings.
• Project: a workspace inside the resource for one app or team. It has its own endpoint (https://<resource>.services.ai.azure.com/api/projects/<project>), agents, evaluations, traces and connections.
• Connections: links from a project to other resources, such as Azure AI Search, Storage, Application Insights, Key Vault or Bing grounding.

A typical production design for an AI app or agent:

Use separate projects or resources per environment (dev, test, prod), so experiments can't affect production quotas or data.

Deployment types

A deployment makes a model callable under a name you choose. The deployment type decides where data is processed, how you pay and how capacity works:

Exam patterns:

• "Predictable latency, high steady volume" → Provisioned
• "Data must stay in the EU" → Data Zone (or regional)
• "Cheapest for millions of offline requests" → Batch
• "Just start building" → Global Standard

Configuring deployments

When you create a model deployment you set:

• Deployment name: what your code passes as model. Keep names stable (for example chat-main) so you can upgrade the model behind them without code changes.
• Model version and upgrade policy: auto-upgrade to the default version, or pin a version
• Capacity: tokens-per-minute quota (Standard) or number of PTUs (Provisioned)
• Guardrails: the content filter or guardrail policy that applies
• Dynamic quota / spillover: optional overflow from provisioned to standard capacity

Agents are deployed too: each agent has a name and versions. Updating instructions or tools creates a new version, so you can test a version before pointing users at it.

Infrastructure as code

Recreating environments by clicking around the portal doesn't scale. Define everything in Bicep or Terraform:

resource account 'Microsoft.CognitiveServices/accounts@2025-06-01' = {
  name: aiName
  location: location
  kind: 'AIServices'
  sku: { name: 'S0' }
  identity: { type: 'SystemAssigned' }
  properties: {
    customSubDomainName: aiName
    allowProjectManagement: true
    disableLocalAuth: true        // keyless: Entra ID only
    publicNetworkAccess: 'Disabled'
  }
}

resource chat 'Microsoft.CognitiveServices/accounts/deployments@2025-06-01' = {
  parent: account
  name: 'chat-main'
  sku: { name: 'GlobalStandard', capacity: 100 }
  properties: { model: { format: 'OpenAI', name: 'gpt-5-mini', version: '2025-08-07' } }
}

Note disableLocalAuth: true (no API keys) and the deployment's sku (deployment type + capacity). API versions and model versions change, so check the current reference when you write your own templates.

The Azure Developer CLI (azd) wraps this: azd up provisions infrastructure and deploys the app. Foundry starter templates use azd.

CI/CD for Foundry projects

A good pipeline (GitHub Actions or Azure Pipelines) for an AI app:

1. Build and unit test the app code
2. Provision or update infrastructure with Bicep/Terraform (or azd provision)
3. Deploy agents and prompts as code: agent definitions, instructions and tool configuration live in the repo and are created as new versions by a script
4. Run evaluations on a test dataset: quality (groundedness, relevance) and safety. Fail the pipeline if scores drop below thresholds.
5. Promote to production after approval

Authenticate the pipeline with workload identity federation (OIDC) to Entra ID instead of storing secrets, and give it least-privilege roles.

Key takeaways

• A Foundry resource holds deployments; a project holds agents, evaluations, traces and connections.
• Choose the deployment type by data location, billing and capacity: Global Standard, Data Zone, Provisioned, Batch.
• Use stable deployment names, versioned agents and configuration rather than hard-coded values.
• Automate with Bicep/Terraform + azd + CI/CD, including evaluation gates before release.

Next lesson: manage quotas, monitoring and security.