An organization is deploying an Azure OpenAI model to internal users and wants to ensure that all content filtering settings cannot be modified by the AI development team once set. Only the security team should be able to change content filter configurations. Which RBAC approach enforces this?

The correct approach is to assign the development team the Cognitive Services OpenAI User role, which grants only data plane inference access such as submitting prompts and reading completions, without management plane permissions to modify model deployments or content filter configurations. The security team should hold the Cognitive Services Contributor role, which includes management plane permissions to configure content filters. This RBAC separation ensures developers cannot change content filter settings. The option that assigns the development team the Cognitive Services OpenAI User role and the security team the Cognitive Services User role, then enables content filter write access in Studio, is wrong because Cognitive Services User does not provide the management-plane permissions required to configure content filters; it does not give the security team the required ability to change those settings, and Studio-level write access does not replace the proper Azure RBAC assignment. The option using Azure Policy to deny content filter modifications for non-security team service principals is wrong because Azure Policy can deny specific operations but cannot effectively differentiate between individual user or service principal identities versus security team members without complex custom policy logic. The option enabling resource locks on all Azure OpenAI deployments is wrong because resource locks prevent deletion and modification by everyone, including the security team, making it impossible for the security team to update content filters legitimately.