4.1. Working with Models in the Foundry Portal
💡 First Principle: Foundry separates two jobs cleanly: a project client handles setup and configuration (which resource, which project, authentication), and an OpenAI-compatible client handles the actual work (sending prompts, getting completions). Almost every Foundry app follows this two-step shape, so once you recognize it, the code stops looking foreign.
Why care? The exam shows Python snippets and asks what they do or what's missing. If you know that AIProjectClient is the setup client and get_openai_client() hands you the thing that actually calls the model, you can read almost any Foundry snippet. You'll also be asked about the portal workflow — deploying a model from the catalog and testing it in the playground before writing any code at all.
⚠️ Common Misconception: "Azure AI Foundry and Microsoft Foundry are two different products." They're the same platform — it was rebranded to Microsoft Foundry. What is a real distinction is Foundry (new generation) vs. Foundry Classic, the older hub-based experience. A telltale sign: Classic hub-based projects used a connection string, while current Foundry projects use an endpoint URL. The exam may test this transition.
