A retail analytics group is setting up Azure AI Foundry so that three separate app teams (recommendations, chat support, and content moderation) can each deploy and manage their own models, while all three share the same virtual network, private endpoints, and Azure OpenAI connections that the central platform team already configured once. Which construct should the platform team create a single time, with each app team then attaching its own workspace to it?
Select an answer to reveal the explanation.
Short Explanation
Think of it like an office building versus individual offices. You want one shared foundation with the network, private endpoints, and connections built once, while each team gets its own project underneath it. That gives centralized governance without forcing teams to share one cramped workspace.
Full Explanation
The right construct is a single Foundry hub with the shared connections, with each app team creating its own project under that hub. A Foundry hub is the top-level container that holds shared infrastructure such as networking, private endpoints, and resource connections, while each app team's project sits underneath the hub as its own workspace for models, data, and deployments. This matches the scenario exactly: one shared setup, multiple isolated team workspaces. The option to create one Foundry project and give each team a separate model deployment inside that same project is incorrect because a project is the team-level workspace itself, not a container designed to host multiple unrelated teams with separate governance needs; cramming three teams into one project removes the isolation they need. The option to skip Foundry and give each team its own resource group with a standalone Azure OpenAI resource is incorrect because abandoning Foundry for standalone resource groups throws away the central platform team's shared networking and connections, forcing each team to duplicate setup and increasing both cost and administrative overhead. The option to create three separate Foundry hubs, one per team, each with its own network and connections is incorrect because creating a separate hub per team recreates the shared network and connections three times over, which is precisely the duplicated effort the platform team was trying to avoid by configuring things once. The hub-and-project model is what lets centralized governance and per-team autonomy coexist.