4 of the 11 questions we have for this objective, shown with the answer and the reasoning.
Manage access to Azure resources
Glenmoor Robotics has a subscription named Sub-Dev that contains resource groups RG-Web, RG-Data, and RG-Shared. A contractor team represented by the security group GRP-WebContractors must be able to deploy and manage resources in RG-Web only. The team must not have any visibility of RG-Data or RG-Shared. Least privilege is required and the assignment should take effect for future members of the group automatically.
What should you do?
- AAssign the Contributor role to GRP-WebContractors at the Sub-Dev subscription scope.A subscription-scope assignment is inherited by every resource group, so the contractors would be able to manage RG-Data and RG-Shared as well.
- BAssign the Contributor role to GRP-WebContractors at the RG-Web resource group scope.A resource group scope assignment applies to RG-Web and everything inside it and nothing outside it, and assigning to the group covers future members without extra work.
- CAssign the Contributor role to each current member of GRP-WebContractors at the RG-Web resource group scope.Individual assignments give the right scope but do not automatically cover people who join the group later, so this fails the automatic-coverage requirement.
- DAssign the Reader role to GRP-WebContractors at the Sub-Dev scope and the Contributor role at the RG-Web scope.The subscription-level Reader assignment gives the contractors visibility of RG-Data and RG-Shared, which the scenario forbids.
Why: Azure role assignments are inherited downward from the scope at which they are made: management group, subscription, resource group, resource. To confine access to one resource group, assign at that resource group. The deciding constraints are least privilege (no access to sibling resource groups) and automatic coverage of future members (assign to the group, not to individuals). Option D is a common real-world pattern but violates the stated requirement that the team have no visibility outside RG-Web.
Manage access to Azure resources
Fallbrook Textiles has a subscription named Sub-Ops that contains resource groups RG-App and RG-Infra. A user named omar.haddad@fallbrook.example has the Reader role assigned at the Sub-Ops scope and the Contributor role assigned at the RG-App scope. RG-Infra contains a virtual network named vnet-core and RG-App contains a web app named app-orders.
Which statement correctly describes the effective access of omar.haddad?
- AHe can modify app-orders and can modify vnet-core.His only write-capable role is Contributor at RG-App, which does not extend to RG-Infra where vnet-core lives.
- BHe can modify app-orders and can view but not modify vnet-core.Reader at the subscription is inherited by both resource groups, and Contributor at RG-App adds write rights only within RG-App, so he reads everywhere and writes only in RG-App.
- CHe can view but not modify app-orders because the subscription-level Reader role takes precedence.Azure RBAC has no precedence between allow roles; permissions are additive, so Contributor at RG-App is not reduced by Reader at a higher scope.
- DHe can modify app-orders but cannot see vnet-core because the Contributor assignment is scoped to RG-App.The subscription-level Reader assignment is inherited by RG-Infra, so he can see vnet-core.
Why: Effective access in Azure RBAC is the union of all role assignments that apply at or above the resource. There is no concept of a narrower assignment being overridden by a broader one. The deciding detail is the combination of Reader at subscription (inherited everywhere) with Contributor at one resource group (write only there). Option C reflects the common misconception that a lower-privilege role at a higher scope limits a higher-privilege role at a lower scope; only deny assignments or Azure Policy can restrict what a role otherwise allows.
Manage access to Azure resources
Ashgrove Financial has 14 subscriptions organized under a management group named MG-Corp, with two child management groups MG-Prod and MG-NonProd. The central security team, represented by the group GRP-SecOps, must have read access to every resource in every current and future subscription under MG-Corp. The company wants to minimize administrative effort.
What should you do?
- AAssign the Reader role to GRP-SecOps on each of the 14 subscriptions.Fourteen assignments work today but every new subscription would need another manual assignment, which does not minimize administrative effort.
- BAssign the Reader role to GRP-SecOps at the MG-Corp management group scope.A single assignment at the top management group is inherited by MG-Prod, MG-NonProd, all 14 subscriptions, and any subscription moved under MG-Corp in the future.
- CAssign the Reader role to GRP-SecOps at the MG-Prod and MG-NonProd management group scopes.Two assignments cover the current children, but a subscription placed directly under MG-Corp or a new child management group would be missed.
- DAssign the Security Reader role to GRP-SecOps at the Tenant Root Group scope.Security Reader is a Microsoft Defender for Cloud role, not general resource read, and assigning at the Tenant Root Group goes beyond MG-Corp to subscriptions the security team was not scoped to.
Why: Management groups exist precisely so that role assignments and policies can be applied once and inherited across many subscriptions. The deciding constraints are future subscriptions must be covered automatically and minimal effort, which points to a single assignment at the highest management group that bounds the requirement, MG-Corp. Assigning any higher (Tenant Root Group) exceeds the intended scope, and assigning any lower leaves gaps. Reader is the correct general-purpose role; Security Reader is a Defender-specific role that sounds similar.
Manage access to Azure resources
Ironvale Manufacturing has a subscription named Sub-Plant. A user named dana.cole@ironvale.example holds the Contributor role at the Sub-Plant scope and the Owner role at resource group RG-Line3. Dana attempts to assign the Reader role to a colleague at the Sub-Plant subscription scope and receives an authorization error. Dana then successfully assigns the Reader role to the same colleague on RG-Line3.
Why did the subscription-scope assignment fail while the resource group assignment succeeded?
- AContributor excludes Microsoft.Authorization/*/Write, so Dana cannot create role assignments at the subscription scope, while Owner on RG-Line3 includes that action for that resource group.Contributor is defined with NotActions that remove role assignment rights, so at subscription scope Dana has no permission to write role assignments; Owner at RG-Line3 includes Microsoft.Authorization/*/Write for that scope and below.
- BRole assignments can only be created at resource group scope or below.Role assignments can be created at management group, subscription, resource group, or resource scope by anyone with sufficient permission.
- CA subscription has a limit of 4,000 role assignments and Sub-Plant has reached it.Hitting the assignment limit would produce a limit error, not an authorization error, and would also block the resource group assignment because it counts against the same subscription limit.
- DThe Reader role cannot be assigned at subscription scope by a user who also holds Contributor.There is no rule that prevents a user with Contributor from assigning Reader; the limitation is that Contributor itself lacks role assignment permissions.
Why: Interpreting an access failure requires reading the role definition at the scope where the action was attempted. Contributor contains Actions of * but NotActions that include Microsoft.Authorization/*/Write and Microsoft.Authorization/*/Delete, so it can do everything except manage access. Owner has no such exclusion. The deciding detail is that the same user succeeded at RG-Line3, where Owner applies, and failed at the subscription, where only Contributor applies. The 4,000-assignment limit is a real limit but produces a different error and would affect both scopes.