At a bank, any developer can deploy a model into the production Microsoft Foundry project. What should the architect change?
Select an answer to reveal the explanation.
Short Explanation
A vault door does not protect the cash if every badge in the building opens it. You restrict who can deploy a model into the production Foundry project. A reminder to be careful does not decide who is allowed to publish.
Full Explanation
Model security includes who is allowed to deploy. If any developer can publish into the production Microsoft Foundry project, the production boundary is not real, and the architect should restrict that right to named roles. Leaving deployment open and posting a reminder keeps the same people able to publish, and a reminder is not a permission. Copying production models into a notebook the whole company can open widens who can change a model instead of narrowing who can deploy. Turning off deployment records hides the publishes that already happen and makes the gap harder to detect after the fact. The named roles should be a small production-deploy group, reviewed when people change teams, and everyone else should publish only in a non-production project. A successful test deploy is not evidence that the same person should publish into the bank's live project. Exam caveat: restricting who can deploy is separate from restricting who can call the model at runtime. A caller right does not have to equal a deploy right. Operational check: attempt a deploy with an account that should not have production rights and confirm the project rejects it, then confirm a named role still can publish.