Permitting GPU nodes share a single cloud IAM role that can also modify IAM policies. What identity principle is violated for GenAI compute?
Select an answer to reveal the explanation.
Short Explanation
One mega-role that runs inference and rewrites IAM is a skeleton key for the permitting cluster. Split and shrink that GenAI compute identity. Combining duties, forever-unbounded roles, and self-rewriting trusts are the opposite of least privilege.
Full Explanation
Permitting GPU nodes that share a single cloud IAM role capable of modifying IAM policies violate least privilege for GenAI compute identities. Inference compute should authenticate only to pull approved artifacts, emit logs, or call narrowly scoped APIs—not hold IAM administration that enables privilege escalation, persistence, or policy rewriting across the municipal cloud account. The violated principle is least privilege for GenAI compute identities: separate the standing identity of GenAI workers from any role that can create users, attach policies, or alter trust relationships.
Combining inference with IAM administration also breaks separation of duties by placing operational serving power and identity governance in one principal. Making the role permanent and unbounded undermines just-in-time and time-bound access patterns that civic cloud teams use to shrink standing privilege. Allowing the role to rewrite its own trust policy casually undermines zero-trust style continuous verification of who may assume what, because a compromised GPU node could widen its own blast radius.
Exam caveat: break-glass IAM roles may exist separately with strong monitoring and dual control; they must not be the standing identity of routine GenAI GPU nodes. Operational check: review the instance profile or workload identity attached to permitting GPUs, remove iam:* or policy-mutation permissions from compute roles, alert on any GenAI compute principal calling IAM change APIs, and confirm inference still functions with the reduced permission set.