1.1.1. The Shift from Service Silos to a Unified Platform
💡 First Principle: Silos optimize for a single capability; platforms optimize for composition. A production AI feature almost never uses one capability in isolation — it grounds a generative model on retrieved data, validates output for safety, and emits traces. A platform exists because stitching separate services together by hand is where real systems break.
In the silo world, a developer building a document-Q&A feature would provision a search resource, an OpenAI resource, and a content-safety resource separately, wire up three sets of credentials, and glue them in application code. Each piece worked; the integration was fragile and undocumented. Foundry collapses this: one project holds connections to the search index, the deployed model, the safety policy, and the evaluation runs, sharing identity and observability. The exam's recurring "Foundry boundary" question — does this belong in project setup, model deployment, agent config, evaluation, or app integration? — only makes sense once you see the platform as a set of cooperating layers rather than a bag of endpoints.
⚠️ Exam Trap: When a scenario lists several Azure AI capabilities working together (search + generation + safety), the expected answer is usually to organize them inside a Foundry project, not to provision and integrate each service independently. Picking the independent-services answer is the AI-102 reflex the exam is probing for.
Reflection Question: A teammate says "let's just spin up an Azure OpenAI resource and an AI Search resource and connect them in code." What capability of a Foundry project are they giving up, and why might that matter at production scale?
