A Foundry project lead wants to let a new data scientist run experiments and view results inside one specific Foundry project, but must prevent that person from changing the project's content filtering policies or deleting deployments. What should the lead do?
Select an answer to reveal the explanation.
Short Explanation
You want the data scientist to run experiments and view results in that one Foundry project without touching content filtering or deployments, so assign them a scoped Azure role on that project that grants contributor-level experiment access without administrative permissions. Don't hand over subscription owner credentials, duplicate the lead's admin role, or disable content filtering; those either overshoot or remove safety controls.
Full Explanation
The correct approach is assigning the data scientist a scoped Azure role limited to that single Foundry project, one that grants contributor-level access for running experiments and viewing results but withholds administrative actions. That lets the person do their job while the project lead retains sole control over sensitive settings like content filtering policies and deployment deletion. Sharing the Azure subscription owner credentials with the data scientist is incorrect because it grants unrestricted control over every resource in the subscription, far beyond the one project the data scientist needs, and violates the principle of least privilege. Giving the data scientist the same role as the lead but asking them informally not to change settings is incorrect because it relies on trust rather than an enforced boundary; nothing technically prevents an accidental or unauthorized change. Disabling content filtering entirely so there is nothing to accidentally change is incorrect because it removes a safety control for everyone using the deployment just to avoid one person changing it, trading a real protection for a false sense of simplicity rather than restricting who can edit it.