Technical Lab: Assign roles at different scopes
Questions
Question 1 — Multiple Choice
An audit team needs to view all resources in an Azure subscription, but should not have read permission on any management group above it. An administrator assigns the Reader role directly on the subscription.
What is the expected behavior of this assignment regarding resource groups and resources contained in the subscription?
A) The role applies only to the subscription itself; resource groups and resources require separate assignments.
B) The role propagates to all resource groups and resources contained in the subscription through scope inheritance.
C) The role propagates only to resource groups, but not to individual resources within them.
D) The role requires the role assignment to be manually replicated in each resource group to take effect.
Question 2 — Technical Scenario
An administrator executes the following command:
az role assignment create \
--assignee "dev@contoso.com" \
--role "Contributor" \
--scope "/subscriptions/aaaa-bbbb/resourceGroups/rg-producao"
Days later, the team reports that user dev@contoso.com can create resources within rg-producao, but can also view and list resources in other resource groups of the same subscription, without any other assignment being made for them.
What is the most likely cause of this behavior?
A) The Contributor role grants implicit read permissions across the entire subscription by default.
B) The user has a role assignment in a higher scope, such as the subscription itself or a management group.
C) The az role assignment create command automatically propagates permissions to the parent scope.
D) The Contributor role assigned to a resource group inherits read permissions from sibling resource groups.
Question 3 — True or False
An Owner role assignment made at the scope of a management group grants permission for the assigned user to assign roles to other users in any subscription contained within that management group, including resource groups and individual resources of those subscriptions.
True or False?
Question 4 — Technical Scenario
An organization has the following hierarchy:
Management Group: MG-Corp
└── Subscription: Sub-Financeiro
├── Resource Group: rg-relatorios
└── Resource Group: rg-dados
User ana@contoso.com has the Reader role assigned in MG-Corp. The administrator decides to also assign the Contributor role to ana@contoso.com directly in rg-relatorios.
What is the effective permission set for ana@contoso.com within rg-relatorios?
A) Only Reader, as assignments in higher scopes always take precedence over lower scopes.
B) Only Contributor, as the more specific assignment replaces the broader one.
C) The combination of Reader and Contributor, resulting in permissions from both roles applied simultaneously.
D) Neither, as conflicting assignments at different scopes cancel each other out.
Question 5 — Multiple Choice
An administrator needs to ensure that a service principal has permission to deploy resources only within a single resource group, without any access to other resource groups or the subscription. They also need this restriction to be auditable and reversible.
Which approach correctly meets these requirements?
A) Assign the Contributor role on the subscription and use a deny policy to block other resource groups.
B) Assign the Contributor role directly on the target resource group, without assignments in higher scopes.
C) Assign the Owner role on the target resource group to ensure full control and auditability.
D) Assign the Contributor role on the subscription with an ABAC condition that filters by resource group.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Azure RBAC uses downward scope inheritance. An assignment made at a parent scope automatically propagates to all child scopes. Since the hierarchy is management group > subscription > resource group > resource, a role assigned at the subscription is inherited by all resource groups and all individual resources within it.
The main error in distractors A, C, and D is assuming that inheritance is partial or non-existent. Azure RBAC does not require manual replication; propagation is automatic and complete for all descendants of the scope where the assignment was made.
Answer Key — Question 2
Answer: B
The command assigns Contributor only at the scope of rg-producao. This role does not grant any permission in other resource groups or the subscription. The described behavior, reading in other resource groups without explicit assignment, is a clear indicator that there is an assignment at a higher scope that is being inherited.
Alternatives A and D describe behaviors that do not exist in Azure's RBAC model. Alternative C reverses the direction of inheritance: assignments propagate down the hierarchy, never up. Investigating assignments at ancestral scopes is the correct first diagnostic step in this scenario.
Answer Key — Question 3
True
The Owner role includes the Microsoft.Authorization/roleAssignments/write action, which allows creating and removing role assignments. When granted at a management group, this permission is inherited throughout the hierarchy below, including subscriptions, resource groups, and individual resources.
The non-obvious point here is that the ability to delegate roles is not restricted to the scope where Owner was assigned: the user can create assignments at any child scope, which represents a significant privilege escalation vector if not controlled with Microsoft Entra Privileged Identity Management (PIM) or governance policies.
Answer Key — Question 4
Answer: C
Azure RBAC is additive: a user's effective permissions at any scope are the union of all roles assigned to them at that scope and all ancestral scopes. There is no concept of replacement or cancellation between roles in standard RBAC.
Therefore, ana@contoso.com accumulates Reader (inherited from MG-Corp) and Contributor (assigned directly to rg-relatorios), resulting in the combined permissions of both within that resource group. The only exception to this additive model are deny assignments, which are not present in this scenario.
Answer Key — Question 5
Answer: B
Assigning Contributor directly to the target resource group is the canonical way to restrict a principal's scope of operation. Azure RBAC follows the principle of least privilege by scope design: by assigning at the lowest necessary level, no permission is granted to sibling or higher scopes. Role assignments are logged in the Azure activity log, which meets the auditability requirement, and can be removed at any time, meeting the reversibility requirement.
Alternative A introduces unnecessary complexity and depends on deny assignments or Azure Policy, which are additional mechanisms. Alternative C exceeds the necessary privilege by granting permission management capability. Alternative D describes the use of ABAC conditions, which are an advanced feature for specific attribute scenarios, not the standard mechanism for scope restriction.