Deploy Your First Model on Microsoft Foundry

Welcome to the first chapter of Build Your First AI App on Azure — a hands-on path through Microsoft Foundry where we go from an empty subscription to a shipped AI application. No slideware, no "left as an exercise for the reader." By the end of this series you'll have deployed a model, grounded it in your own data with AI Search, given it tools it can actually call, measured whether its answers are any good, and shipped the whole thing to production.

This chapter is the foundation: get a model running in the cloud and call it from code — the right way, without a single API key.

What you need

Three things: an Azure subscription (the free account works), the Azure CLI installed and logged in (az login), and Python 3.10+. That's it. Everything we build in this series stays comfortably in hobby-budget territory, and I'll flag the cost of each piece as we go.

Foundry in one paragraph

Microsoft Foundry (you may remember it as Azure AI Foundry) is Azure's home for building AI applications: a model catalog, an agent service, evaluation tooling, and observability, all hanging off a thing called a project. A project gives you one endpoint and one RBAC boundary for everything your app needs. If you've worked with Azure OpenAI resources before, think of a Foundry project as the bigger house that the models now live in — alongside a lot of new machinery we'll use in later chapters.

Step 1 — Create a project

Portal is the fastest first time:

1. Go to the Foundry portal at ai.azure.com and sign in.
2. Select Create new → Foundry project. Give it a name like my-first-ai-app.
3. Pick a region — I use East US 2 (good model availability, competitive pricing) — and a new resource group.
4. When it lands, copy the project endpoint from the Overview page. It looks like:

https://my-first-ai-app.services.ai.azure.com/api/projects/my-first-ai-app

Save that — it's the only "connection string" this entire series needs, and it's not a secret.

Step 2 — Deploy a model

In the portal, open your project and head to the model catalog. You'll find OpenAI models next to Llama, DeepSeek, Phi, Mistral and friends. For a first app I recommend a small, cheap, fast model — you can swap it later without changing a line of code, which is precisely the point of deployments.

Pick a small chat model from the catalog (the -mini variants of the current OpenAI generation are the usual suspects), select Deploy, and accept the defaults. The deployment name is what your code references — name it something stable like chat-small. Deploying costs nothing; you pay per token when you actually call it.

Cost note: small models currently run at fractions of a cent per thousand tokens. Don't take my word for numbers — check the pricing page for the model you pick. The series total, run end-to-end, should cost you less than a coffee.

Step 3 — Call it, keylessly

Here's the part most tutorials get wrong: they have you copy an API key into your code. We're not doing that — not now, not ever in this series. Azure lets your identity be the credential: locally that's your az login session, in production it's a managed identity. Nothing to leak, nothing to rotate.

Install the SDK (2.x, which speaks the current Foundry API):

pip install "azure-ai-projects>=2.0.0" azure-identity

Then the smallest possible AI app:

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
 
PROJECT_ENDPOINT = "https://my-first-ai-app.services.ai.azure.com/api/projects/my-first-ai-app"
 
project = AIProjectClient(
    endpoint=PROJECT_ENDPOINT,
    credential=DefaultAzureCredential(),  # az login locally, managed identity in prod
)
openai = project.get_openai_client()
 
response = openai.responses.create(
    model="chat-small",  # your DEPLOYMENT name, not the model name
    input="Explain what a managed identity is, in two sentences, like I'm a developer in a hurry.",
)
print(response.output_text)

Run it. If you get two crisp sentences back, congratulations — you have a working AI app and your repo contains zero secrets.

Two things worth noticing in that snippet. First, model takes your deployment name: swap the underlying model in the portal tomorrow and this code doesn't change. Second, we're using the Responses API — the single entry point Foundry uses for everything from plain model calls to full agents with tools. Learning it now pays off in every remaining chapter.

What just happened, permission-wise

Your az login identity created the project, so you already hold the right role. When teammates (or a production app) need access, grant their identity the Azure AI User role on the Foundry resource — that's the minimum needed to call deployed models at inference time. Least privilege from day one; future-you will be grateful.

A quick mental model for the series

What we have now is a raw model: brilliant at language, ignorant of your world. It doesn't know your documents (chapter 2 fixes that with RAG and AI Search), it can't do anything (chapter 3 gives it tools), you have no idea how often it's wrong (chapter 4 makes quality measurable), and it lives in a Python script on your laptop (chapter 5 ships it properly).

That's the whole journey. Each chapter stacks on this endpoint and this deployment — nothing gets thrown away.

Wrapping up

You created a Foundry project, deployed a model behind a stable deployment name, and called it with the Responses API using identity-based auth instead of API keys. Small chapter, load-bearing habits.

Next up — Chapter 2: the model meets your data. We'll wire up Azure AI Search and build retrieval-augmented generation, so answers come grounded in your documents instead of the model's imagination.