An organization needs to grant a specific application identity the ability to call Azure OpenAI's chat completions API and submit batch jobs, but not the ability to view or modify resource configurations, deployments, or quotas. Which RBAC configuration achieves this least-privilege access?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — a is correct because the 'Cognitive Services OpenAI User' built-in role grants exactly the permissions needed: it allows calling the Azure OpenAI data plane APIs (chat completions, embeddings, fine-tuning batch jobs) without any management plane permissions to view configurations, modify deployments, or adjust quotas. Scoping this role assignment to the specific Azure OpenAI resource (not a broader scope like resource group or subscription) further enforces least privilege.
Full explanation below image
Full Explanation
A is correct because the 'Cognitive Services OpenAI User' built-in role grants exactly the permissions needed: it allows calling the Azure OpenAI data plane APIs (chat completions, embeddings, fine-tuning batch jobs) without any management plane permissions to view configurations, modify deployments, or adjust quotas. Scoping this role assignment to the specific Azure OpenAI resource (not a broader scope like resource group or subscription) further enforces least privilege. B is wrong because 'Cognitive Services Contributor' is a management plane role that grants the ability to modify resource configurations, create deployments, and change quota settings—far beyond what is needed for API inference. C is wrong because Microsoft.CognitiveServices/accounts/read is a read-only management plane permission for reading resource configurations, not for calling the inference APIs. D is wrong because 'Cognitive Services OpenAI Contributor' at subscription scope is overly broad in both role permissions and scope—it would grant management access to all Cognitive Services resources in the subscription.