AI-103 Practice Question 93: Agent Definition Disaster Recovery
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 10 · question 3 of 10
A team is writing a disaster-recovery plan for its Foundry Agent Service deployment. They've learned that the service keeps no built-in backups and supports no point-in-time restore, and that conversation threads cannot be recovered if lost. Their goal is narrower: after an outage or a region loss, quickly stand their agents (prompts, model choice, and tool bindings) back up in a new project or region, accepting that thread history will not come with them.
What should they do to prepare for that outcome?
Show answer and explanation
Answer:
This is the first item on Microsoft's own DR readiness checklist: "Treat agent definitions as code. Store agent definitions, knowledge assets, and tool bindings in source control so you can redeploy them quickly," paired with "Automate redeployment of agents... using the Azure AI Foundry REST API... or the Azure AI Projects SDK." Redeployed agents come up with new agent IDs and no access to prior threads, matching exactly what the team has already accepted will be lost.
- A is wrong because no such recovery feature exists for agents: the guidance states plainly that "Agent Service doesn't provide built-in disaster recovery capabilities. It doesn't replicate state, create backups, or support point-in-time restore." - B is wrong because the Agent Service itself has "no supported method for active-active, multi-region replication," regardless of the redundancy configured on a dependency store; replicating the database doesn't reconstruct the agent layer on top of it. - C is wrong because the same guidance rules this out explicitly: "Microsoft Support can't recover orphaned data, migrate data between projects, or combine state from multiple sources."
Reference: Foundry Agent Service disaster recovery