AI-103 Practice Question 63: Customer Managed Key Prerequisites
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 7 · question 3 of 10
A hospital network's compliance team requires that it be able to revoke the encryption key for its Foundry resource's data at rest at any time, cutting off access immediately. An engineer enables the system-assigned managed identity on the Foundry resource, creates a key in an Azure Key Vault in a different region for cost-tracking reasons, and switches the resource's encryption type to Customer-Managed Keys. The operation fails.
What is the most likely cause?
Show answer and explanation
Answer:
Microsoft's prerequisites for configuring CMK are explicit: "Deploy the key store and the Foundry resource in the same Azure region," and "Enable soft delete and purge protection on the key store ... (required by Azure)." A key vault in a different region, chosen here for cost tracking, fails that requirement and blocks the encryption switch, independent of any identity or permission setup.
- A is wrong because both identity types are supported. A system-assigned identity works fine; it just doesn't exist until the resource is created, which changes the *order* of steps (grant access after creation) but isn't a supported/unsupported distinction. - C is wrong because the documented minimum is a 2048-bit RSA key, not 4096-bit, and key size isn't the failure implied by the scenario. - D is wrong because CMK can be enabled on an existing resource; the portal path is Resource Management > Encryption, select Customer-Managed Keys, and supply the key store URL and key name. Creation-time-only would make CMK impossible to adopt after the fact, which contradicts the documented update flow.
Reference: Configure Customer-Managed Keys for Microsoft Foundry