AI-103 Practice Question 61: Multi Service Versus Foundry Resource
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 7 · question 1 of 10
A two-person team is prototyping an internal tool that only calls Azure AI Language for key phrase extraction and Azure AI Vision for OCR on scanned forms. They want a single key and a single endpoint to manage, and they have no plans to build agents, run evaluations, or deploy a generative model.
Which resource should they provision?
Show answer and explanation
Answer:
A multi-service Azure AI services resource gives one key and one endpoint that reaches several Foundry Tools APIs, exactly Language and Vision here, with no project, no agent surface, and no extra billable components to manage. Microsoft's own guidance frames the choice as one of scope: Azure AI services resources fit a team "thinking in features," a targeted capability embedded in an existing system, while Foundry resources fit orchestrated, agentic, or generative work. This team is squarely in the first case.
- B is wrong on two counts: standard setup is for production agent deployments needing customer-owned Cosmos DB, AI Search, and storage for thread data, and this team isn't building agents at all. Standing up three extra Azure resources for two REST calls is unjustified cost and operational overhead. - C is wrong because it reintroduces the exact problem the team is trying to avoid, two keys and two endpoints to track, when one multi-service resource already reaches both APIs. - D is wrong because a Foundry resource's value is the project/agent/evaluation surface around Azure OpenAI and Foundry Tools. Provisioning one "in case they add agents later" pays for capability they don't use today, when a multi-service resource can still be reached from a future Foundry project if that day comes.
Reference: Create a Foundry resource