Parks computer-vision training shares a GPU queue that lets one project read another project’s training datasets. What cluster control is needed?
Select an answer to reveal the explanation.
Short Explanation
Shared GPUs without walls mean Project A can peek at Project B’s photos. Isolate tenants so training data stays in its lane. Cluster-admin for all, world-readable mounts, and no accounting dissolve isolation.
Full Explanation
Parks computer-vision training that shares a GPU queue yet lets one project read another project’s training datasets needs multi-tenant isolation so projects cannot read each other’s training data. Shared accelerators are fine; shared readable dataset mounts are not. Cross-project reads create confidentiality failures (other teams’ imagery) and integrity failures (tampering or accidental training on the wrong corpus). Isolation via separate identities, storage ACLs, and namespace boundaries keeps each parks CV project’s data in its lane while still using a common GPU pool.
Granting every project cluster-admin to simplify scheduling fails because cluster-admin dissolves isolation. Mounting all datasets world-readable to reduce job failures fails because it intentionally creates the cross-read problem. Disabling job accounting so teams cannot see who ran what fails because it removes auditability without fixing data isolation.
Exam caveat: multi-tenancy on shared GPUs is about identity and storage isolation, not giving everyone admin or making datasets world-readable “for convenience.”
Operational check: assign per-project service accounts; mount only that project’s datasets; verify a negative test where project A’s job cannot list project B’s training paths; keep job accounting enabled for abuse detection.