Can VM Security Group Membership Grant Storage Access?

Answer Correct answer: B — A security group containing VM objects cannot be assigned a role to grant storage1 access; assign the role to each VM's managed identity instead.

Note: This section contains one or more sets of questions with the same scenario and problem. Each question presents a unique solution to the problem. You must determine whether the solution meets the stated goals. More than one solution in the set might solve the problem. It is also possible that none of the solutions in the set solve the problem. After you answer a question in this section, you will NOT be able to return. As a result, these questions do not appear on the Review Screen. You have an Azure subscription that contains two virtual machines named VM1 and VM2. Each virtual machine has system-assigned managed identity enabled. You have an Azure Storage account named storage1. Public access from all networks is enabled for storage1. You need to ensure that VM1 and VM2 can access storage1. Solution: You add each virtual machine to a security group, and then add the security group to a role on storage1. Does this meet the goal?

  1. Yes
  2. No Correct Answer

Community Insight

This item tests the difference between a VM resource and its system-assigned managed identity service principal; the trap is assuming security-group membership of the VM automatically carries RBAC permissions to storage1.

The scenario tests whether Azure VM objects can be added to a security group to grant their system-assigned managed identities access to storage1. It establishes that the solution fails (B) because RBAC role assignments must target the managed identity's service principal, not the VM resource placed in a group.

Choosing Yes (A) and assuming that adding VM1 and VM2 to a security group, then assigning that group a role on storage1, authorizes their managed identities; Azure role assignments do not flow through VM objects as group members.

Community Discussion (1 comments)

Daverhyme07 👍 2 Selected: B
Security groups are for users/service principals, not VM objects.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

The proposed solution does not meet the goal, so the answer is No (B). VM1 and VM2 each have a system-assigned managed identity, which is represented in Microsoft Entra ID as a service principal; that service principal is the security principal that can receive an Azure RBAC role assignment on storage1. Azure virtual machine resources themselves are not security principals and cannot be added to a Microsoft Entra security group in the way the solution describes. Even if a group is used, the group must contain the managed identity service principals, not the VM objects. Public network access being enabled on storage1 affects connectivity, not authorization, so it does not make the group-based assignment work.

Why the Other Options Are Wrong

Option A (Yes) is wrong because it assumes that adding a VM resource to a security group extends permissions to its managed identity. Azure role assignments to groups apply to the group's member security principals, such as users, service principals, managed identities, or other groups, not to arbitrary Azure resources like virtual machines. The network setting that allows public access from all networks does not replace the need for a correctly scoped data-plane or management-plane RBAC role. The solution would need to assign the appropriate storage role directly to each VM's managed identity service principal, or place those service principals in a group and assign the role to that group.

Community Comment Notes

Daverhyme07 captured the core distinction succinctly: "Security groups are for users/service principals, not VM objects." That aligns with the exam point that the VM's system-assigned identity is the assignable principal, while the VM resource is not. The comment's selected answer of No matches the analysis above. No other comments add a conflicting interpretation of the scenario.

Official Reference

Exam Strategy

In “does this meet the goal” items, identify the exact security principal receiving the role: for a system-assigned managed identity, that is the identity's service principal, not the VM resource. Check whether the proposed group membership is technically possible and whether the role is assigned at the correct storage scope.

Frequently Asked Questions

Why can't I add an Azure VM to a Microsoft Entra security group for storage RBAC?

The VM resource is not a security principal. To grant access, assign the storage role to the VM's system-assigned managed identity service principal, or add that service principal to the group.

Does enabling public access from all networks on storage1 authorize VM1 and VM2?

No. Public network access only affects connectivity; authentication and authorization still require a valid identity and an appropriate Azure RBAC role assignment.

More SC-500 FAQ →

Related Analysis

Practice All SC-500 Questions

Access 100 questions with complete answers and detailed explanations.

View Full SC-500 Practice Test →

← Back to SC-500 Study Guide