Foundry Foundations

What Microsoft Foundry is

Microsoft Foundry is the unified platform for building, deploying and governing AI applications and agents on Azure. Its pitch is consolidation: agents, models and tools live under one Azure resource provider namespace, with one set of role assignments, one networking configuration, one policy surface, and one observability plane.

Concretely, Foundry gives you four things:

The vocabulary shift you must memorise

Foundry consolidated several previous products, and with them came a full rename. The exam, the portal and the current documentation use the new names. Most third-party material, older Learn modules and many practice tests still use the old ones. Knowing both directions is worth several marks.

The resource model

flowchart TB
  SUB["Azure subscription"] --> RG["Resource group"]
  RG --> FR["Foundry resource<br/>Microsoft.CognitiveServices/accounts<br/>kind = AIServices"]
  FR --> P1["Project: dev"]
  FR --> P2["Project: prod"]
  FR --> DEP["Model deployments<br/>(resource scope)"]
  FR --> CONN["Connections<br/>Search · Storage · App Insights"]
  P1 --> AG1["Agents, files,<br/>vector stores, evals"]
  P2 --> AG2["Agents, files,<br/>vector stores, evals"]

  RG -.legacy.-> HUB["Azure AI hub<br/>+ Storage + Key Vault<br/>(only for open-source models,<br/>managed compute, prompt flow)"]

The Foundry resource

The Foundry resource is a single Azure resource that scopes design, deployment, governance and runtime access for generative AI applications and agents. It is the default resource type for anything you create in the Foundry portal, and it supersedes the old combination of hub + Azure OpenAI + Azure AI Services. It carries:

• Model deployments — created at resource scope and usable by the projects underneath.
• Connections — to Azure AI Search, Storage, Application Insights, MCP servers and more.
• Security settings — managed identity, private endpoints, customer-managed keys, Azure Policy.
• Azure OpenAI backward compatibility — the same endpoint shapes and API surface.

The Foundry project

A project is a child resource of the Foundry resource: a folder that organises one team's or one application's work. Agents, files, vector stores, evaluation runs, datasets and traces live in a project. By default a project inherits the parent's settings; it can also carry its own RBAC assignments so a developer can self-serve without an admin in the loop.

The hub — legacy, but still examinable

The Azure AI hub is the older resource type, built on Azure Machine Learning, that required a dependent Storage account and Key Vault. New features land on the Foundry resource, but a hub is still required for a small set of scenarios:

Other resource types you will meet

Azure OpenAI resource

A narrower resource that exposes OpenAI models and APIs only. Still valid where a security team refuses to enable the full Foundry surface, but the model catalogue shows only Azure OpenAI models. There is an in-place upgrade to a Foundry resource that preserves the endpoint, API keys and existing state.

Azure AI Search

A separate resource for indexing and retrieval. You connect it to Foundry; it is never inside the Foundry resource. It powers RAG, the Azure AI Search tool and Foundry IQ knowledge bases.

Azure Cosmos DB / Azure Storage / Application Insights

Optional "bring your own resources" for conversation state, file storage and telemetry, connected when compliance or operations demand you own the data store.

Foundry Models

The catalogue splits along a line that matters for billing, SLA and support — and that the exam likes to test.

Choosing a model for the task

The very first objective in Skill 1 is "choose an appropriate model for each task, including LLMs, small language models, multimodal models, and Foundry Tools". That is a shopping list of trade-offs:

Comparing models before you commit

Foundry has a model leaderboard and benchmarks surface that compares models on quality, cost, throughput and safety across public datasets or your own data, and an evaluation SDK for testing a specific endpoint. Model selection is the first stage of the evaluation lifecycle (base model selection → pre-production evaluation → post-production monitoring); see Skill 2 for the evaluators themselves.

Deployment options and deployment types

Two levels of choice, and the exam expects you to keep them apart. First the deployment option (how the model is hosted), then, for serverless, the deployment type (where data is processed and how you pay).

flowchart TD
  A["Need to run a model"] --> B{"Open-source / custom /<br/>Hugging Face / NIM?"}
  B -- Yes --> MC["Managed compute<br/>(dedicated VMs, billed by uptime,<br/>needs a hub + compute quota)"]
  B -- No --> C["Serverless API<br/>on the Foundry resource"]
  C --> D{"Data residency<br/>requirement?"}
  D -- "None" --> E["Global"]
  D -- "US / EU / APAC" --> F["Data Zone"]
  D -- "Specific geography" --> G["Standard or<br/>Regional Provisioned"]
  E --> H{"Traffic pattern?"}
  F --> H
  H -- "Bursty / variable" --> I["Standard<br/>(pay per token)"]
  H -- "High and steady, low<br/>latency variance" --> J["Provisioned<br/>(PTUs)"]
  H -- "Large async jobs" --> K["Batch<br/>(~50% cheaper)"]

Deployment options

Deployment types (serverless)

Three categories — standard (pay per token), provisioned (reserved capacity, priced in PTUs) and batch (discounted asynchronous) — crossed with three data-processing scopes. A Developer type also exists for evaluating fine-tuned models, with no SLA.

Foundry Tools

Foundry Tools is the new name for what were Azure AI Services (and before that, Cognitive Services). They are available through the Foundry resource and, in most cases, directly in the Foundry portal as playgrounds, as agent tools, and as MCP servers.

Connections

A connection is how a Foundry resource or project reaches something outside itself: an Azure AI Search service, a Storage account, an Application Insights workspace, an MCP server, a Language resource, a Bing grounding resource. Connections can be created at resource scope (shared by every project) or project scope (private to one project).

Each connection carries an authentication method, and the choice matters:

One endpoint, one API

The old world had you juggling five or more endpoints and SDK packages. Foundry gives you a single project endpoint:

https://<resource-name>.services.ai.azure.com/api/projects/<project-name>

Everything hangs off it: model inference, agents, conversations, files, vector stores, evaluations and traces. The OpenAI-compatible surface lives at /openai/v1/ with stable v1 routes instead of monthly api-version strings.

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

# Every Foundry project exposes exactly one endpoint:
# https://<resource-name>.services.ai.azure.com/api/projects/<project-name>
project = AIProjectClient(
    endpoint="https://my-foundry.services.ai.azure.com/api/projects/my-project",
    credential=DefaultAzureCredential(),   # keyless: Entra ID token, no API key
)

# The project client hands you an OpenAI-compatible client bound to the project.
openai = project.get_openai_client()

response = openai.responses.create(
    model="gpt-5-mini",                    # the deployment name in your project
    input="Summarise the AI-103 exam in one sentence.",
)
print(response.output_text)

Three ways to build, in one table

Detail lives in Skill 2, but the shape of the choice belongs here because it frames everything else.

Identity, RBAC and keyless authentication

sequenceDiagram
  autonumber
  participant App as Your app
  participant Entra as Microsoft Entra ID
  participant Proj as Foundry project endpoint
  participant Model as Model deployment

  App->>Entra: DefaultAzureCredential requests a token<br/>(scope: ai.azure.com)
  Entra-->>App: Access token (no key stored anywhere)
  App->>Proj: POST /openai/v1/responses<br/>Authorization: Bearer token
  Proj->>Proj: Check Azure RBAC (Foundry User / Agent Consumer)
  Proj->>Model: Route to deployment, apply guardrails
  Model-->>Proj: Completion + content filter annotations
  Proj-->>App: Response object

The five Foundry roles

Azure separates management actions (control plane: create resources, deploy models) from development actions (data plane: build agents, call models). This is the single most common source of "why can't I do anything?" in Foundry — and a favourite exam target.

Keyless, managed identity and network isolation

• Keyless credentials mean Entra ID tokens instead of API keys. In code that is DefaultAzureCredential (or AzureCliCredential locally, a managed identity in Azure). No secret is stored, nothing to rotate, and access is revoked by removing a role assignment.
• Agent identity: each agent can have its own dedicated Entra identity, so it authenticates to external MCP servers and APIs with scoped permissions rather than sharing the project's credentials. Hosted agents get a dedicated identity automatically.
• Private networking: private endpoints and VNet integration. Prompt agents support private networking; hosted agents support bring-your-own VNet, where each session runs in a VM-isolated sandbox attached to your network.
• Network egress controls preview restrict which outbound destinations a hosted agent may reach, configured in the same guardrail (RAI policy).

Developer surfaces

Foundations glossary

Foundry resource

The single Azure resource that scopes models, agents, tools, RBAC, networking and policy.

Foundry project

A child resource of the Foundry resource; the workspace where agents, files, vector stores and evaluations live.

Deployment

A named, callable instance of a model in your resource. The name you pass as model=.

Responses API

The current inference and agent API (Agents v2). Replaces the Assistants API.

Conversation

Server-side multi-turn state. Replaces "thread". Holds items (replacing "messages").

Agent version

An immutable snapshot of an agent definition. Replaces "assistant"; enables rollback and comparison.

Toolbox

A curated, versioned collection of tools exposed through one managed MCP-compatible endpoint, reusable across agents and frameworks.

Guardrail

A named collection of controls; each control pairs a risk, an intervention point and an action.

Foundry IQ

The managed knowledge layer built on Azure AI Search that turns enterprise content into reusable, permission-aware knowledge bases for agents.

PTU

Provisioned Throughput Unit — the unit of reserved model capacity for provisioned deployment types.

Foundry Tools

The renamed Azure AI Services: Content Understanding, Language, Speech, Translator, Vision, Content Safety.