AI-103 Practice Question 85: BYO Thread Storage Cosmos
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 9 · question 5 of 10
A regulated fintech company runs Foundry Agent Service with the standard agent setup. Compliance requires that all customer conversation history be stored exclusively in Azure resources the company's own tenant controls, and the data-residency exception that was just approved covers only an existing Azure SQL Server estate the company already operates for other regulated workloads, not any newly provisioned NoSQL database. The team also wants the platform to keep managing conversation state automatically through thread IDs; they don't want to rewrite the application to resend full conversation history on every turn.
Can standard agent setup's bring-your-own thread storage be pointed at that existing SQL Server database?
Show answer and explanation
Answer:
Standard agent setup's resource table is specific about the technology, not just "a customer-owned database": Azure Cosmos DB (BYO Thread Storage) stores "messages, conversation history, and agent metadata," and the prerequisites call for "an Azure Cosmos DB for NoSQL account" sized to at least 3000 RU/s across its containers. There's no documented option to substitute a different engine such as SQL Server; the connection the project capability host expects is a Cosmos DB for NoSQL connection specifically. The compliance team's SQL Server exception, however solid, doesn't change what the platform will connect to.
- A is wrong because it invents a substitution the documentation doesn't support; the BYO thread-storage prerequisite is Cosmos DB for NoSQL, not "any relational or NoSQL store." - B is wrong because standard agent setup exists specifically to keep agent data (files, vector stores, and threads) in customer-owned Azure resources inside the customer's tenant; claiming Foundry Agent Service is always Microsoft-managed contradicts the entire purpose of the standard setup. - C is wrong against the stated constraint: setting store to false is the Responses API's zero-data-retention pattern, and it requires the application itself to carry conversation context forward on every call, exactly the rewrite the team said it wants to avoid. It also isn't standard agent setup's BYO thread storage; it's a different mechanism for a different API shape.
Reference: Set up standard agent resources for Foundry Agent Service