A FinOps analyst at Cascade Regional Airlines moves several virtual machines from the Kiosk-Pilot resource group into the Kiosk-Prod resource group within the same subscription. What should the analyst expect regarding any RBAC role assignments that were scoped directly to Kiosk-Pilot?

Role assignments are bound to the scope object they were created against, whether that is a resource group, a subscription, or an individual resource. Moving a resource between resource groups changes its parent scope in the ARM hierarchy, but it does not carry along any inherited permissions that came from the old parent, because those permissions were never attached to the resource itself, they were attached to the old resource group and simply flowed down through inheritance while the VM lived there. Once the VM is a child of Kiosk-Prod instead, it inherits whatever roles are assigned at Kiosk-Prod and above, not what used to apply at Kiosk-Pilot. A role assignment scoped directly to the VM's own resource ID is different: since it targets the resource itself rather than a container, it remains attached and continues to apply after the move. The idea that all assignments transfer automatically overstates how inheritance works, and the idea that Azure blocks the move pending role cleanup is simply not how the resource-move operation behaves, resource moves across resource groups and even subscriptions are a supported and common operation. One caveat: some resource types have move limitations or require downtime, so always check the specific resource type's move support before planning a migration. After the move, verify access by reviewing Access control (IAM) directly on the moved VM and on Kiosk-Prod rather than assuming Kiosk-Pilot's settings carried over.