AZ-500 Manage identity and access Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Navigate to the resource group, then open Access control (IAM), then add a role assignment, then select a role, then select a user, then review and assign.

  Why this is correct

  To correctly assign an Azure RBAC role, you must first navigate to the resource group that defines the scope of the assignment. Opening the Access control (IAM) blade at that scope lets you view current assignments and click 'Add role assignment' to launch the wizard. Inside the wizard, you select the role (such as Contributor), then on the Members tab select the user, and finally click Review + assign to commit the assignment. This order aligns with the portal's required workflow, where the scope, role, and principal must be specified in that sequence.

• ✗

  Select a role, then navigate to the resource group, then open Access control (IAM), then add a role assignment, then select a user, then review and assign.

  Why it's wrong here

  This sequence is invalid because the role selection step cannot occur in isolation before you have established the assignment context. In the Azure portal, the role picker is only available after you open the Access control (IAM) blade and click 'Add role assignment' — the role is chosen within that wizard, not before navigating to the resource group. Attempting to select a role first would have no target scope or IAM blade to attach it to, so the assignment cannot be created. Therefore, this order is technically impossible and will fail.

• ✗

  Select a user, then navigate to the resource group, then open Access control (IAM), then add a role assignment, then select a role, then review and assign.

  Why it's wrong here

  This ordering is incorrect because Azure RBAC assignment requires the role to be selected before specifying the principal (user). In the 'Add role assignment' wizard, the Role tab comes first; after picking the role, you proceed to the Members tab to search for and select the user. If you attempt to select the user first, the wizard cannot bind that principal to any permissions because the role (which defines permitted actions) has not been chosen yet. Thus, the user-selection step must follow role selection, not precede it.

• ✗

  Navigate to the subscription, then open Access control (IAM), then add a role assignment, then select a role, then select a user, then review and assign.

  Why it's wrong here

  This sequence is wrong because it assigns the role at the subscription scope instead of the resource group scope. If the question explicitly requires a resource-group-level assignment, navigating to the subscription and assigning the role there would grant permissions to the user across every resource group within that subscription — a much broader privilege than intended. The IAM blade is available at all scopes, but the scope must match the requirement; using the subscription path would create an over-privileged assignment and fail the stated objective. Therefore, the correct scope is the resource group, not the subscription.

Go deeper

Related to this question