Foundry project - Azure Glossary

Understand the concept

In plain English

Foundry project is a project space in Microsoft Foundry that groups the AI assets a team uses to build, evaluate, and operate a specific application or use case. Teams use it to separate team work, access, agents, evaluations, files, model deployments, and operational evidence so AI work does not become an unmanaged shared sandbox. In Azure reviews, it matters when someone must approve access, troubleshoot behavior, estimate cost, or explain why the configuration exists. Treat it as a design choice tied to owners, users, evidence, and rollback.

Why it matters

Foundry project matters because it changes how teams design, approve, troubleshoot, and explain an Azure workload. If the concept is misunderstood, teams may grant the wrong access, hide an unhealthy dependency, overbuild capacity, miss audit evidence, or create a user-facing failure that looks like an application bug. It affects security, reliability, operations, cost, and performance because one setting can influence who reaches the workload, how traffic behaves, what gets logged, how much capacity is consumed, and how quickly support can recover. A strong definition helps architects and operators ask the practical questions before the change reaches production. Always tie the review to one subscription, environment, owner, and measurable business outcome.

Technical context

Technically, Foundry project is understood through Foundry resource project APIs, project resource IDs, Azure RBAC, model deployments, agents, files, evaluations, connections, managed identities, and portal or SDK workflows. Important settings include project name, parent Foundry resource, location, team role assignments, model deployments, connections, diagnostic settings, tags, and environment boundaries. Operators inspect it with project show output, portal project settings, resource ID, team role assignments, deployment inventory, evaluation results, activity logs, and application traces. Validate it against the live subscription and environment.

Exam context

AI-901 Microsoft Azure AI Fundamentals

Compare with

Foundry resource Foundry hub Azure AI Foundry

Where it is used

Where you see it

The Foundry portal displays a project with agents, files, evaluations, model deployments, connections, team access, and resource details under one use case during review for production evidence.
CLI or SDK output shows the project name, resource ID, parent Foundry resource, location, provisioning state, and access assignments for operators during review for production evidence.
Change records refer to a Foundry project when approving model deployments, adding team members, connecting data sources, or promoting an agent workflow during review for production evidence.

Common situations

Design and review Foundry project for a production Azure workload before traffic, data, or model behavior depends on it.
Troubleshoot Foundry project by comparing live configuration, logs, metrics, ownership, and downstream service health.
Document Foundry project in architecture, security, cost, and support runbooks so teams share the same operating language.
Use Foundry project during release planning to confirm prerequisites, access, rollback, monitoring, and customer-impact assumptions.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Foundry project in action for insurance Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Summit Mutual, a insurance organization, needed to solve a concrete production challenge: separate AI prototypes for claims, underwriting, and customer support were mixed in one workspace, making ownership and access reviews painful. Leaders wanted a practical Azure design that support, security, and business owners could understand.

Goals

Separate use cases
Clarify project ownership
Control team access
Keep evaluation evidence

Approach using Foundry project

The team used Foundry project as the control point for the change. The cloud team created a distinct Foundry project for the claims assistant under the approved Foundry resource. The project contained its model deployments, files, evaluations, agent configuration, and team role assignments. Engineers used CLI project show output and role assignment evidence in the change record. Access reviews mapped each user to a claims business owner, and release gates required evaluation results before agent updates could reach production. Before release, engineers captured read-only evidence, confirmed owners and access, checked diagnostics or local logs, and documented rollback steps. Operations monitored the first production window with metrics that matched the stated objectives, not just generic resource health. The change record linked configuration evidence to measurable outcomes so later audits and incident reviews could reconstruct the decision quickly.

Potential outcomes

Access review time fell 41 percent
Claims assets stopped mixing with other prototypes
Evaluation evidence was retained per release
Incident owners were clear

What to learn

A Foundry project gives AI teams a practical boundary for ownership, access, and operational evidence.

Scenario 02 Foundry project in action for higher education Scenario, objectives, solution, measured impact, and takeaway.

Scenario

WestRiver University, a higher education organization, needed to solve a concrete production challenge: faculty teams wanted student-facing AI labs but needed a controlled project boundary for experiments, files, and model deployments. Leaders wanted a practical Azure design that support, security, and business owners could understand.

Goals

Isolate course experiments
Limit student access
Track model deployments
Simplify semester cleanup

Approach using Foundry project

The team used Foundry project as the control point for the change. Administrators created one Foundry project per course cohort under a shared Foundry resource. Each project held approved files, lab agents, model deployments, and evaluation notes. Instructors received project-level access, while students used an application front end rather than direct portal permissions. Operations exported project IDs, role assignments, and deployment lists at semester close, then removed stale assets using a documented cleanup runbook. Before release, engineers captured read-only evidence, confirmed owners and access, checked diagnostics or local logs, and documented rollback steps. Operations monitored the first production window with metrics that matched the stated objectives, not just generic resource health. The change record linked configuration evidence to measurable outcomes so later audits and incident reviews could reconstruct the decision quickly.

Potential outcomes

Semester cleanup took hours not days
Student access stayed constrained
Deployment inventory was visible
Lab outages were easier to triage

What to learn

Foundry projects make experimentation safer when every course, team, or use case has a defined operating boundary.

Scenario 03 Foundry project in action for government technology Scenario, objectives, solution, measured impact, and takeaway.

Scenario

CivicAssist Digital, a government technology organization, needed to solve a concrete production challenge: a citizen-service chatbot needed agents, evaluations, and files grouped separately from unrelated innovation pilots. Leaders wanted a practical Azure design that support, security, and business owners could understand.

Goals

Group production assets
Enable controlled team access
Retain evaluation history
Support incident response

Approach using Foundry project

The team used Foundry project as the control point for the change. The delivery team created a Foundry project dedicated to the citizen-service assistant. It linked approved model deployments, uploaded policy files, evaluation runs, and the agent used by the public web app. Change records referenced the project resource ID, owner, diagnostic settings, and rollback path. During incidents, operators could compare project configuration, model deployment state, and application traces without searching unrelated AI experiments. Before release, engineers captured read-only evidence, confirmed owners and access, checked diagnostics or local logs, and documented rollback steps. Operations monitored the first production window with metrics that matched the stated objectives, not just generic resource health. The change record linked configuration evidence to measurable outcomes so later audits and incident reviews could reconstruct the decision quickly.

Potential outcomes

Incident triage time fell 33 percent
Evaluation history matched release versions
Access reviews had a single scope
Unrelated pilots no longer created noise

What to learn

A Foundry project helps production AI applications stay organized enough for support, audit, and safe change control.

Azure CLI

CLI checks make Foundry project review repeatable because they capture scoped evidence for configuration, ownership, dependencies, health, and change impact before operators modify production.

Useful for

List or show the Azure or local resources related to Foundry project before selecting a target for deeper review.
Capture read-only evidence for Foundry project during release approval, incident response, access review, or cost investigation.
Compare configuration, metrics, logs, and dependent resources for Foundry project across environments before approving a mutating command.

Before you run a command

Confirm tenant, subscription, resource group, profile, endpoint, project, device, or local model scope before trusting command output.
Run list and show commands first, then save evidence before create, update, purge, restart, delete, scale, or access changes.
Check whether the command affects customer traffic, local user devices, cached content, model behavior, cost, or compliance evidence.

What the output tells you

Names, resource IDs, locations, SKUs, enabled states, and parent relationships show whether you are inspecting the intended target.
Settings, identities, routes, deployments, endpoints, origins, cache paths, or model metadata explain how requests or workloads behave today.
Timestamps, metrics, usage, health state, and logs help separate Azure configuration issues from application, device, or downstream failures.

Mapped commands

Foundry project operational checks

direct

az cognitiveservices account project list --name <foundry-resource> --resource-group <resource-group>

az cognitiveservices account projectdiscoverAI and Machine Learning

az cognitiveservices account project show --name <foundry-resource> --resource-group <resource-group> --project-name <project-name>

az cognitiveservices account projectdiscoverAI and Machine Learning

az cognitiveservices account project create --name <foundry-resource> --resource-group <resource-group> --project-name <project-name> --location <location>

az cognitiveservices account projectprovisionAI and Machine Learning

az role assignment list --scope <project-resource-id> --output table

az role assignmentdiscoverAI and Machine Learning

az monitor diagnostic-settings list --resource <project-resource-id>

az monitor diagnostic-settingsdiscoverAI and Machine Learning

Architecture context

Technically, Foundry project is understood through Foundry resource project APIs, project resource IDs, Azure RBAC, model deployments, agents, files, evaluations, connections, managed identities, and portal or SDK workflows. Important settings include project name, parent Foundry resource, location, team role assignments, model deployments, connections, diagnostic settings, tags, and environment boundaries. Operators inspect it with project show output, portal project settings, resource ID, team role assignments, deployment inventory, evaluation results, activity logs, and application traces. Validate it against the live subscription and environment.

Security: Security for Foundry project starts with team membership, project-scoped roles, managed identity permissions, model access, file uploads, connection secrets, and diagnostic visibility. Review who can create it, change it, delete it, read diagnostics, approve connected resources, and use any credentials or identities involved. Prefer managed identity and Microsoft Entra ID where supported, keep secrets out of code, and scope roles to the smallest useful boundary. Capture Activity Log entries, role assignments, network settings, policy exemptions, and owner approvals before production changes. The goal is to prove that access, exposure, and data handling were intentional rather than accidental side effects of a quick deployment.
Cost: Cost for Foundry project is driven by shared Foundry resource usage, model deployments, agent runs, evaluations, storage, diagnostics, duplicate projects, and inactive experiments that remain billable. The expensive mistake is not only Azure consumption; it can also be duplicate experiments, broad changes, support time, overprovisioned capacity, or emergency cleanup after weak design evidence. Review whether the workload truly needs the selected tier, retention, diagnostics, network path, cache behavior, or automation pattern. Use tags, budgets, alerts, and recurring cleanup reviews so teams can explain why the current design exists and remove stale resources without breaking dependencies. Always tie the review to one subscription, environment, owner, and measurable business outcome.
Reliability: Reliability for Foundry project depends on project ownership, deployment lifecycle, agent dependencies, evaluation gates, quota, region choice, connection health, and change isolation between use cases. A resource can appear healthy while the business workflow fails because a route, dependency, identity, cache, quota, or downstream service is wrong. Test common failure modes, disabled states, retries, rollback paths, and maintenance behavior before relying on the design. Keep runbooks for first-response checks, owner escalation, and safe rollback. During incidents, compare platform metrics, deployment history, configuration changes, and application traces from the same time window before changing production settings. Always tie the review to one subscription, environment, owner, and measurable business outcome.
Performance: Performance for Foundry project depends on model region, deployment selection, endpoint latency, project connection paths, evaluation workload, concurrent agent runs, and application-side retry behavior. Measure platform-side metrics and application-side completion metrics because a fast control-plane response does not always mean users received the right result. Test with realistic data sizes, regions, concurrency, authentication paths, route choices, cache state, and downstream limits. When performance regresses, compare configuration changes, resource limits, client logs, diagnostic data, and workload timing before adding capacity or blaming one service. The best tuning decisions come from evidence tied to the exact environment. Always tie the review to one subscription, environment, owner, and measurable business outcome.
Operations: Operations for Foundry project require project inventory, naming standards, access reviews, deployment approvals, evaluation records, incident owners, diagnostic settings, and cleanup of abandoned experiments. Before a change, capture read-only CLI output, portal evidence when useful, owner tags, expected behavior, and a rollback path. During incidents, avoid changing several settings at once; compare metrics, logs, deployment operations, identity evidence, network state, and downstream health first. Keep release notes clear enough for support teams to verify current behavior quickly. Good operational practice turns the term into something observable, reviewable, and recoverable instead of tribal knowledge. Always tie the review to one subscription, environment, owner, and measurable business outcome.

Common mistakes

Treating Foundry project as a simple label instead of checking the live scope, owner, dependencies, and current configuration.
Running a mutating command in the wrong subscription, profile, resource group, project, endpoint, origin group, or local device context.
Assuming a successful command means users saw the correct result without checking logs, metrics, application behavior, and rollback evidence.