A city clerk's office wants data scientists to submit jobs to a shared Azure Machine Learning compute cluster but must prevent them from deleting the workspace. Which access approach is appropriate?

Assigning a workspace role that allows job submission on shared compute without Owner rights to delete the workspace is appropriate because the city clerk's office needs least-privilege collaboration: data scientists must submit jobs to a shared Azure ML compute cluster, but they must not be able to delete the workspace or broadly reconfigure municipal controls. Azure RBAC and Azure ML roles separate job-submit and data-science duties from Owner-level lifecycle operations. That split protects the shared civic platform while still enabling productive experimentation.

Assigning Contributor at the workspace scope to manage experiments and configure shared compute targets for the analytics team fails because Contributor still carries the ability to delete and reconfigure the workspace resource itself — it is broader than the stem's “cannot delete the workspace” requirement, not a safe substitute for it. Assigning Reader on the workspace and relying on a compute administrator to launch jobs for scientists fails because Reader cannot submit anything; routing every run through a separate administrator turns job submission into a bottleneck instead of giving scientists the access they actually need. Assigning Machine Learning Workspace Connection Secrets Reader to access compute credentials for job submission fails because that role only exposes connection secrets — it grants no permission to submit or run a job on the shared cluster, so scientists still could not do the work the stem describes.

Exam caveat: Contributor/Owner-style rights are broader than job-submit needs. When stems contrast “submit jobs” with “cannot delete workspace,” choose least-privilege job or data-scientist oriented roles—not Contributor or subscription Owner, and not a role that only reaches secrets instead of compute.

Operational check: verify a test scientist identity can submit a job to the shared cluster, cannot delete the workspace, and that activity appears under that identity in logs rather than a shared Owner account.