A team member must power on and shut down AHV VMs in a Nutanix environment managed by Prism Central, but must not modify storage containers. Which RBAC approach follows least privilege?
Select an answer to reveal the explanation.
Short Explanation
Think of RBAC like handing someone a house key: you give the key to the room they need, not the master key. If they only need to start and stop VMs, give them a role with VM power-control rights only. The trap is thinking admin roles are easier—they'll also open storage editing when your user shouldn't touch it.
Full Explanation
Nutanix RBAC controls what an authenticated user can do by mapping users or groups to roles, and roles to specific privileges. For least privilege, the role should contain only the privileges required for the task—here, virtual-machine power operations—and exclude privileges that modify storage containers or other infrastructure objects. Scope the assignment to the relevant cluster, project, or organizational unit when supported, so the permission applies only where the workload exists. A role that combines VM and storage administration is too broad because it grants the user capability beyond the stated need, even if the user never uses the extra rights. A storage-focused role is also wrong because storage privileges do not inherently authorize starting or stopping virtual machines; the required VM power privilege must still be present. Granting full platform administration and hiding menus is not a security control, because the underlying API permissions remain available even if the graphical interface omits a button. Exam caveat: Nutanix RBAC is enforced through assigned privileges, not through UI visibility or user discipline. Operational check: after assigning the role, log in as the test user and confirm VM power controls work while storage-edit actions are denied.