13.1 ALM for Microsoft Foundry Agents Service & Model Registries

Microsoft Certified: Agentic AI Business Solutions Architect Expert AB-100

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Requirements Analysis & Grounding Data

1.1 Assessing Agents for Task Automation, Analytics & Decision-Making 1.2 Grounding Data Evaluation: Accuracy, Relevance, Timeliness, Cleanliness & Availability 1.3 Structuring Enterprise Business Data for AI System Interoperability

2 Chapter 2: AI Strategy, Cloud Adoption Framework & CoE

2.1 Cloud Adoption Framework (CAF) for Azure AI Strategy & Roadmap 2.2 Multi-Agent Architecture: Microsoft 365 Copilot, Copilot Studio & Foundry 2.3 Microsoft AI Center of Excellence (CoE) & Solution Governance 2.4 Developing Use Cases for Prebuilt Agents & the Microsoft Agent Catalog 2.5 Solution Rules & Constraints for Copilot Studio, Microsoft Foundry & Foundry Tools

3 Chapter 3: Model Selection, Prompt Engineering & Dynamics AI

3.1 Model Selection Strategy, Custom Models & Small Language Models (SLMs) 3.2 Enterprise Prompt Engineering Guidelines & Prompt Libraries 3.3 Cross-App AI Strategy for Multi-App Dynamics 365 Solutions

4 Chapter 4: ROI, TCO, Build vs Buy & Model Routing

4.1 ROI Criteria & Total Cost of Ownership (TCO) for AI Solutions 4.2 Comprehensive Financial ROI Analysis for Business Processes 4.3 Build vs Buy vs Extend Architectural Decision Framework 4.4 Dynamic Model Router Architecture & Cost-Performance Optimization

5 Chapter 5: Dynamics 365 AI & Contact Center Design

5.1 Business Terms & Copilot Customization in Customer Experience and Service 5.2 Connectors & Data Flow Design for Copilot in Dynamics 365 Sales 5.3 Agent Integration with Dynamics 365 Contact Center Channels

6 Chapter 6: Agent Archetypes & Copilot Studio Core

6.1 Designing Task Agents, Autonomous Agents & Prompt-and-Response Agents 6.2 Copilot Studio Topic Design, Trigger Phrases & Graceful Fallbacks 6.3 Orchestration Selection: Standard NLP vs CLU vs Generative AI Orchestration

7 Chapter 7: Copilot Studio Advanced Actions & Power Platform

7.1 Designing Agent Flows & Prompt Actions in Copilot Studio 7.2 Power Apps Canvas App Integration, Generative Pages & Agent Feeds 7.3 Power Platform Well-Architected Framework for AI Workloads 7.4 Proposing Microsoft Power Platform AI Features & the AI Hub

8 Chapter 8: Agent Extensibility, MCP & Computer Use

8.1 Microsoft Foundry Custom Models & Foundry Tools Selection 8.2 Agent Extensibility via Model Context Protocol (MCP) in Copilot Studio 8.3 Computer Use Automation & Web UI Interactions in Copilot Studio

9 Chapter 9: Advanced Behaviors & Prebuilt App Orchestration

9.1 Agent Behaviors: Multi-Step Reasoning, Voice Mode & M365 Agent Optimization 9.2 Orchestrating Prebuilt AI in Dynamics 365 F&O and M365 Copilot for Sales/Service 9.3 Orchestrating Prebuilt Copilot AI Features in Dynamics 365 Customer Experience & Service 9.4 Proposing Microsoft 365 Agents for Business Scenarios 9.5 Adding Knowledge Sources to In-App Help & Guidance in Dynamics 365 Finance & Supply Chain

10 Chapter 10: Telemetry, Monitoring & Agent Tuning

10.1 Monitoring Architectures: Azure Monitor, Application Insights & Studio Analytics 10.2 Telemetry Data Interpretation, Performance Metrics & Latency Tuning 10.3 User Feedback Analysis, Backlog Prioritization & Continuous Improvement

11 Chapter 11: Testing Strategy & Model Validation

11.1 Agent Testing Frameworks, Quality Metrics & Groundedness Benchmarks 11.2 Custom AI Model Validation, Safety Criteria & Regression Testing 11.3 Copilot-Assisted Test Case Generation & Cross-Dynamics End-to-End Testing 11.4 Validating Effective Copilot Prompt Practices

12 Chapter 12: ALM for Grounding Data & Copilot Studio Agents

12.1 ALM for Grounding Data, Vector Indexes & Knowledge Synchronization 12.2 ALM for Copilot Studio Agents, Connectors & Solution Packaging 12.3 Environment Strategy & Automated Deployment Pipelines for Studio Agents

13 Chapter 13: ALM for Foundry Agents & Dynamics 365 AI

13.1 ALM for Microsoft Foundry Agents Service & Model Registries 13.2 ALM for Custom AI Models, Fine-Tuning Artifacts & Deployment Slots 13.3 ALM for Dynamics 365 AI in Finance, Supply Chain & Customer Engagement

14 Chapter 14: Agent Identity, Security & Access Controls

14.1 Agent Identity Architecture, Microsoft Entra ID & Authentication Flows 14.2 Access Controls, Role-Based Security & Permissions on Grounding Data 14.3 Secure Data Processing & Grounding Data Isolation

15 Chapter 15: Model Security & Threat Mitigation

15.1 Model Security Architecture & Defense Against Vulnerabilities 15.2 Mitigating Prompt Manipulation, Jailbreaks & Indirect Prompt Injections 15.3 Azure AI Content Safety, Prompt Shields & Guardrails

16 Chapter 16: Responsible AI, Governance, Residency & Audit

16.1 Microsoft Responsible AI Standard: Principles, Assessment & Implementation 16.2 Data Residency, Sovereign Boundaries & Cross-Border Compliance 16.3 Comprehensive Audit Trails, Model Decision Logging & Microsoft Purview 16.4 Designing Governance for Agents: Environment Strategy, Data Policies & Agent Inventory

13.1 ALM for Microsoft Foundry Agents Service & Model Registries

Key Takeaways Explain This Topic AI

Azure AI Foundry Agents Service models autonomous agents as declarative code assets (manifests, system instructions, tool bindings, and model configurations) that must be version-controlled in Git to prevent configuration drift and guarantee auditability.

The Azure AI Foundry Model Catalog and Model Registry provide centralized governance, lineage tracking, and environment bindings for foundation models, custom fine-tuned models, and serverless APIs across enterprise lifecycle stages.

Enterprise CI/CD pipelines leverage the Azure Developer CLI (azd), Azure CLI, and Infrastructure as Code (Bicep/Terraform) to deploy agent definitions deterministically across isolated Development, Testing, and Production Azure subscriptions.

Cross-subscription promotion requires parameterizing model deployment names, Azure AI Search endpoint URIs, and User-Assigned Managed Identities (UAMI) while securing external credentials strictly through Azure Key Vault references.

Enterprise ALM mandates explicit model version pinning rather than targeting the dynamic 'latest' tag, preventing unannounced upstream model updates from causing silent inference regressions in production.

Last updated: October 2026

ALM for Microsoft Foundry Agents Service & Model Registries

Quick Answer: Application Lifecycle Management (ALM) for Microsoft Azure AI Foundry Agents Service treats agents as declarative software assets— Agent-as-Code —stored in version-controlled Git repositories. Enterprise architects must decouple agent definitions (instructions, tool bindings, and model references) from target environments by parameterizing endpoints, utilizing Infrastructure as Code (Bicep or Terraform), pinning immutable model versions in the Azure AI Foundry Model Registry, and promoting configurations across isolated subscriptions using Azure DevOps or GitHub Actions driven by User-Assigned Managed Identities (UAMI) and Azure Key Vault references.

As organizations transition from conversational chatbots to autonomous, pro-code agentic systems, enterprise architecture teams require industrialized engineering disciplines. In Azure AI Foundry (formerly Azure AI Studio), the Azure AI Foundry Agents Service empowers developers to build sophisticated multi-tool agents that execute code, search enterprise vector stores, and invoke arbitrary enterprise APIs. However, configuring agents interactively through the Azure AI Foundry web portal creates severe operational liabilities: unversioned prompts, undocumented tool mutations, configuration drift, and catastrophic deployment failures when moving between development sandboxes and production environments.

1. Declarative Agent Architecture & Agent-as-Code Patterns

To achieve deterministic, repeatable deployments, every component of an Azure AI Foundry agent must be authored and maintained as declarative code within a Git repository. +-----------------------------------------------------------------------------+

| DECLARATIVE AGENT-AS-CODE REPOSITORY |
+-----------------------------------------------------------------------------+
| |
| +---------------------------+ +-----------------------------------+ |
| | Agent Manifest (YAML) | | Tool Definitions & APIs | |
| | - agent.manifest.yaml | <---> | - tools/code_interpreter.json | |
| | - Instructions / Prompt | | - tools/file_search_config.json | |
| | - Model & Temperature | | - tools/openapi_erp_tool.json | |
| +---------------------------+ +-----------------------------------+ |
| | | |
| v v |
| +---------------------------+ +-----------------------------------+ |
| | Infrastructure as Code | | Environment Parameters | |
| | - infra/main.bicep | <---> | - config/dev.parameters.json | |
| | - Foundry Hub & Project | | - config/uat.parameters.json | |
| | - Role Assignments | | - config/prod.parameters.json | |
| +---------------------------+ +-----------------------------------+ |
+-----------------------------------------------------------------------------+
The Anatomy of an Agent Manifest

Rather than relying on manual portal configuration, the agent's core specification is formalized in an immutable declarative manifest. Below is an enterprise agent definition schema representing an autonomous financial auditing agent: # agent.manifest.yaml

schema_version: "2.0"

agent:

name: "enterprise-financial-auditor"
description: "Autonomous agent for quarterly balance sheet reconciliation and anomaly detection"
instructions: "./prompts/auditor_system_instructions.md"

model:

catalog_source: "azure-openai"
name: "gpt-4o"
version_tag: "2024-11-20"
deployment_parameter: "${AZURE_OPENAI_DEPLOYMENT_NAME}"
temperature: 0.1
top_p: 0.95
response_format: "json_object"

tools:

- type: "code_interpreter"

configuration:

memory_limit_mb: 2048
timeout_seconds: 120
type: "file_search"

configuration:

vector_store_id: "${FOUNDRY_VECTOR_STORE_ID}"
max_num_results: 10
type: "function"
specification: "./tools/erp_reconciliation_openapi.json"

authentication:

type: "user_assigned_managed_identity"
client_id_parameter: "${UAMI_CLIENT_ID}"

monitoring:

application_insights_parameter: "${APPINSIGHTS_CONNECTION_STRING}"
diagnostic_log_categories: ["AgentExecutionEvents", "ToolCallEvents", "TokenConsumption"]
Core Tool Bindings in Azure AI Foundry Agents Service

Code Interpreter: Enables the agent to generate and execute sandboxed Python code in a secure container environment to process tabular financial models, compute statistical variance, or generate visualizations. The ALM pipeline governs execution timeouts, allowed libraries, and container memory limits.

File Search (Vector Store Integration): Connects the agent to Azure AI Search vector indexes or managed vector stores within Azure AI Foundry. In code ALM, the agent definition stores the logical reference to the vector store, while the physical store ID is injected per environment during pipeline execution.

Custom Function / OpenAPI Tools: Exposes RESTful enterprise APIs (such as SAP, Dynamics 365, or internal microservices) via standard OpenAPI 3.0 specifications. Versioning OpenAPI contracts alongside the agent ensures that payload schema modifications immediately trigger pull request validation and interface integration tests.

Important

Portal Anti-Pattern: Modifying agent system instructions or tool bindings directly in the Azure AI Foundry portal breaks the chain of custody, bypasses peer review, and renders automated rollback impossible. Any changes made in the portal will be obliterated during the next CI/CD pipeline execution.

2. Model Catalog vs. Model Registry in Azure AI Foundry

Architects must distinguish between the two foundational model management services in Azure AI Foundry: +-----------------------------------------------------------------------------+

| AZURE AI FOUNDRY MODEL SERVICES |
+-----------------------------------------------------------------------------+
| |
| +-------------------------------------+ +-----------------------------+ |
| | MODEL CATALOG | | MODEL REGISTRY | |
| +-------------------------------------+ +-----------------------------+ |
| | - Public & Partner Model Discovery | | - Enterprise Custom Models | |
| | - Azure OpenAI, Meta, Mistral, Phi | | - Fine-Tuned Weights & LoRA | |
| | - Models-as-a-Service (MaaS) Server | | - MLflow Artifact Packaging | |
| | - Provisioned Throughput (PTU) | | - Stage Tags: Staging, Prod | |
| | - Baseline Benchmarks & Evaluation | | - Strict Cryptographic Hash | |
| +-------------------------------------+ +-----------------------------+ |
| | | |
| +-------------------+-------------------+ |
| | |
| v |
| +-------------------------------------+ |
| | TARGET PROJECT MODEL DEPLOYMENT | |
| +-------------------------------------+ |
+-----------------------------------------------------------------------------+
The Azure AI Foundry Model Catalog

The Model Catalog serves as the central hub for discovering, evaluating, and deploying pre-trained foundation models across Microsoft, OpenAI, Meta, Mistral AI, Cohere, and Hugging Face. When consuming foundation models from the catalog, ALM governance focuses on deployment modality and version pinning .

The Azure AI Foundry Model Registry

The Model Registry is an enterprise-dedicated, MLflow-compliant repository for storing, tracking, and promoting custom-trained or fine-tuned model artifacts. It captures:

Model Artifact Hash: Cryptographic SHA-256 fingerprint of weights, tokenizers, and configuration files.

Training Run Provenance: Direct lineage linking the model to the exact Azure AI Foundry fine-tuning job, input dataset snapshot, and hyperparameter configuration.

Semantic Versioning & Stage Tags: Immutable version increments ( v1.0.0 , v1.0.1 , v2.0.0 ) accompanied by mutable lifecycle stage pointers ( Candidate , Staging , Production , Archived ).

Model Deployment Modalities: Architectural Comparison

Deployment Modality Infrastructure Model ALM & Promotion Strategy Cost Structure Latency & SLA Guarantees

Models-as-a-Service (MaaS) Serverless API endpoints hosted by Microsoft; no dedicated compute instances to manage Deployed instantly via API; parameterized model ID; zero infrastructure provisioning Pay-per-token (consumption-based) Multi-tenant shared infrastructure; subject to regional rate limits (TPM/RPM)

Provisioned Throughput Units (PTU) Dedicated reserved capacity allocated to specific Azure OpenAI model deployments Bicep-managed deployment units; requires pre-allocation and quota reservation across regions Fixed hourly commitment per PTU (monthly/annual term) Deterministic latency; guaranteed throughput; zero throttling within reserved PTU envelope

Managed Online Endpoints Dedicated GPU virtual machine clusters (e.g., Standard_NC24ads_A100_v4) running model containers Deployed via Azure CLI / Bicep; supports native blue/green deployment slots and autoscaling rules Hourly compute cluster charge plus storage Dedicated single-tenant compute; full control over concurrency, kernel optimization, and scaling

The Version Pinning Imperative

A critical exam topic for AB-100 is model lifecycle versioning. When configuring an agent's model binding, developers often mistakenly bind to a floating alias like latest or omit the version tag. If the upstream foundation model provider releases an unannounced sub-version update (e.g., updating prompt adherence weights or safety classifiers), the production agent's reasoning pattern may shift drastically, breaking JSON output parsers and degrading task completion rates.

Architectural Mandate: Production agent pipelines must always pin an exact, immutable model version tag (such as gpt-4o (2024-11-20) or Mistral-Large-2411 ). Model version upgrades must be treated as formal pull request events that pass automated regression evaluation suites before merging.

3. Automated Agent Deployment Pipelines with azd, Azure CLI & Bicep

Deploying an Azure AI Foundry agent involves orchestrating both control-plane infrastructure (Hubs, Projects, AI Services, AI Search, Key Vault) and data-plane agent configurations (assistants, tools, prompt templates, vector stores). +-----------------------------------------------------------------------------+

| END-TO-END AGENT PROMOTION PIPELINE |
+-----------------------------------------------------------------------------+
|
v
[ Step 1: Git Pull Request Trigger ]
|
v
[ Step 2: Static Validation & Linting ] -------> Lint YAML manifest, validate
| OpenAPI specs, scan secrets
v
[ Step 3: azd / Bicep Provisioning ] ----------> Deploy/Update Foundry Hub,
| (Control Plane Infrastructure) Project, Search, & Key Vault
v
[ Step 4: Python SDK Agent Sync ] -------------> Create/Update Agent via
| (Data Plane Assets) 'azure-ai-projects' SDK
v
[ Step 5: Synthetic Integration Smoke Test ] --> Execute automated turns,
| assert tool execution
v
[ Step 6: Promotion to Next Stage Gate ] ------> UAT Sign-Off -> Prod Deploy
Infrastructure as Code (Bicep) for Azure AI Foundry

In modern Azure architectures, an Azure AI Foundry environment consists of an AI Foundry Hub (the parent governance and security container) and one or more child AI Foundry Projects (the team-level workspaces where agents reside). // main.bicep: Provisioning Azure AI Foundry Hub and Project

@description('Deployment environment tier')
param environmentName string

@description('Primary Azure region')
param location string = resourceGroup().location

// 1. User-Assigned Managed Identity for the Agent Service
resource agentIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
name: 'id-foundry-agent-${environmentName}'
location: location
}

// 2. Azure AI Foundry Hub Resource
resource aiHub 'Microsoft.MachineLearningServices/workspaces@2024-04-01-preview' = {
name: 'hub-enterprise-ai-${environmentName}'
location: location
kind: 'Hub'
identity: {
type: 'UserAssigned'
userAssignedIdentities: {
'${agentIdentity.id}': {}
}
}
properties: {
friendlyName: 'Enterprise AI Core Hub - ${environmentName}'
storageAccount: storageAccount.id
keyVault: keyVault.id
applicationInsights: appInsights.id
}
}

// 3. Azure AI Foundry Project Child Resource
resource aiProject 'Microsoft.MachineLearningServices/workspaces@2024-04-01-preview' = {
name: 'proj-auditor-agent-${environmentName}'
location: location
kind: 'Project'
properties: {
hubResourceId: aiHub.id
friendlyName: 'Financial Auditor Agent Project'
}
}
Data-Plane Agent Synchronization via the Azure AI SDK

Infrastructure as Code provisions the hosting resources, but the agent itself must be instantiated within the project using the Azure AI Projects SDK ( azure-ai-projects ). In the CI/CD pipeline, an automated deployment script executes to publish the desired state declared in agent.manifest.yaml as a new, immutable agent version in the target environment: # deploy_agent.py: Automated CI/CD Data-Plane Synchronization Script

import os
import yaml
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import CodeInterpreterTool, FileSearchTool, PromptAgentDefinition

def synchronize_agent():

endpoint = os.environ["AZURE_AI_PROJECT_ENDPOINT"]
manifest_path = os.environ.get("AGENT_MANIFEST_PATH", "./agent.manifest.yaml")

with open(manifest_path, "r") as f:

manifest = yaml.safe_load(f)

with open(manifest["agent"]["instructions"], "r") as f:

instructions_content = f.read()

project_client = AIProjectClient(
endpoint=endpoint, # https://<resource>.services.ai.azure.com/api/projects/<project>
credential=DefaultAzureCredential()
)

# Resolve tools
tools = [CodeInterpreterTool()]

if "FOUNDRY_VECTOR_STORE_ID" in os.environ:

tools.append(FileSearchTool(vector_store_ids=[os.environ["FOUNDRY_VECTOR_STORE_ID"]]))

# Each pipeline run publishes a new immutable agent version (name:1, name:2, ...)
agent = project_client.agents.create_version(
agent_name=manifest["agent"]["name"],
definition=PromptAgentDefinition(
model=os.environ["AZURE_OPENAI_DEPLOYMENT_NAME"],
instructions=instructions_content,
tools=tools,
),
)
print(f"Published {agent.name} version {agent.version}")

if __name__ == "__main__":

synchronize_agent()
4. Cross-Subscription Environment Promotion & Identity Isolation

Enterprise security architecture mandates that Development, User Acceptance Testing (UAT), and Production environments reside in physically isolated Azure subscriptions or management groups. This structure prevents development experimentation from impacting production compute quotas, limits the blast radius of security incidents, and guarantees strict compliance with SOC 2, HIPAA, and ISO 27001 controls. +-----------------------+ +-----------------------+ +-----------------------+

| SUBSCRIPTION: DEV | | SUBSCRIPTION: UAT | | SUBSCRIPTION: PROD |
+-----------------------+ +-----------------------+ +-----------------------+
| Hub: hub-ai-dev | | Hub: hub-ai-uat | | Hub: hub-ai-prod |
| Proj: proj-agent-dev | | Proj: proj-agent-uat | | Proj: proj-agent-prod |
| Model: gpt-4o (MaaS) | --> | Model: gpt-4o (MaaS) | --> | Model: gpt-4o (PTU) |
| Search: idx-dev-mock | | Search: idx-uat-clean | | Search: idx-prod-corp |
| UAMI: id-agent-dev | | UAMI: id-agent-uat | | UAMI: id-agent-prod |
| KeyVault: kv-ai-dev | | KeyVault: kv-ai-uat | | KeyVault: kv-ai-prod |
+-----------------------+ +-----------------------+ +-----------------------+
^ ^ ^
| | |
+-----------------------------------------------------------------------------------+
| CI/CD SERVICE PRINCIPAL (OIDC FEDERATED) |
| Injects Subscription-Specific Parameter Files |
+-----------------------------------------------------------------------------------+
Parameterization Matrix Across Subscription Tiers

To allow the same immutable agent code to deploy across tiers, all environment-dependent variables must be extracted into configuration files:

Configuration Parameter Development (Dev) Acceptance Testing (UAT) Production (Prod)
Azure Subscription ID sub-enterprise-dev-01 sub-enterprise-uat-01 sub-enterprise-prod-01

Foundry Project Endpoint https://ai-dev.cognitiveservices.azure.com https://ai-uat.cognitiveservices.azure.com https://ai-prod.cognitiveservices.azure.com

OpenAI Deployment Name gpt-4o-serverless-dev gpt-4o-serverless-uat gpt-4o-ptu-reserved-prod
Search Vector Store ID vs-dev-synthetic-corp vs-uat-anonymized-gold vs-prod-authoritative-v2
Managed Identity Client ID 00000000-0000-0000-dev 11111111-1111-1111-uat 22222222-2222-2222-prod

Key Vault Reference URI @Microsoft.KeyVault(SecretUri=https://kv-dev...) @Microsoft.KeyVault(SecretUri=https://kv-uat...) @Microsoft.KeyVault(SecretUri=https://kv-prod...)

Zero-Secret Security Architecture via Entra ID & UAMI

Enterprise architects must eliminate hardcoded API keys and connection strings from agent configurations. The agent authenticates to downstream resources using a User-Assigned Managed Identity (UAMI) configured with least-privilege Azure Role-Based Access Control (RBAC):

Cognitive Services OpenAI User: Granted to the agent's UAMI on the target Azure OpenAI resource to permit model completions and vector embeddings.

Search Index Data Reader: Granted on the Azure AI Search instance, allowing the File Search tool to query indexed chunks without needing the admin master key.

Key Vault Secrets User: Granted strictly on designated secret paths for legacy tools that require basic authentication tokens.

Storage Blob Data Reader: Assigned on the landing storage account to stream source files into containerized code interpreter sessions.

Tip

Exam Tip: When deploying across subscriptions, service connections in Azure DevOps or GitHub Actions should use Workload Identity Federation (OpenID Connect / OIDC) rather than storing long-lived client secrets. This eliminates secret rotation overhead and guarantees temporary, auditable token issuance during pipeline runs.

13.1 ALM for Microsoft Foundry Agents Service & Model Registries

Microsoft Certified: Agentic AI Business Solutions Architect Expert AB-100

Track your progress as you read

1 Chapter 1: Requirements Analysis & Grounding Data

2 Chapter 2: AI Strategy, Cloud Adoption Framework & CoE

3 Chapter 3: Model Selection, Prompt Engineering & Dynamics AI

4 Chapter 4: ROI, TCO, Build vs Buy & Model Routing

5 Chapter 5: Dynamics 365 AI & Contact Center Design

6 Chapter 6: Agent Archetypes & Copilot Studio Core

7 Chapter 7: Copilot Studio Advanced Actions & Power Platform

8 Chapter 8: Agent Extensibility, MCP & Computer Use

9 Chapter 9: Advanced Behaviors & Prebuilt App Orchestration

10 Chapter 10: Telemetry, Monitoring & Agent Tuning

11 Chapter 11: Testing Strategy & Model Validation

12 Chapter 12: ALM for Grounding Data & Copilot Studio Agents

13 Chapter 13: ALM for Foundry Agents & Dynamics 365 AI

14 Chapter 14: Agent Identity, Security & Access Controls

15 Chapter 15: Model Security & Threat Mitigation

16 Chapter 16: Responsible AI, Governance, Residency & Audit

13.1 ALM for Microsoft Foundry Agents Service & Model Registries

Key Takeaways Explain This Topic AI

Last updated: October 2026

ALM for Microsoft Foundry Agents Service & Model Registries

1. Declarative Agent Architecture & Agent-as-Code Patterns

schema_version: "2.0"

- type: "code_interpreter"

Important

2. Model Catalog vs. Model Registry in Azure AI Foundry

The Azure AI Foundry Model Registry

Model Deployment Modalities: Architectural Comparison

Deployment Modality Infrastructure Model ALM & Promotion Strategy Cost Structure Latency & SLA Guarantees

The Version Pinning Imperative

3. Automated Agent Deployment Pipelines with azd, Azure CLI & Bicep

manifest = yaml.safe_load(f)

instructions_content = f.read()

tools.append(FileSearchTool(vector_store_ids=[os.environ["FOUNDRY_VECTOR_STORE_ID"]]))

Zero-Secret Security Architecture via Entra ID & UAMI

Tip

Loading diagram... Azure AI Foundry Agent-as-Code Promotion & Multi-Subscription Lifecycle Architecture