Azure RBAC practice questions

You need to ensure that junior administrators can view all resources in the Prod-Sub subscription but cannot create, modify, or delete any resources. Which Azure RBAC role should you assign?

Trap 1: Owner

Owner is the highest-privilege built-in role, encompassing all permissions of Contributor plus the ability to assign roles and manage access via Azure RBAC. Granting Owner to junior administrators would allow them to change access control, elevate other users' permissions, and modify or delete any resource in the scope. This is drastically more access than required for viewing resources and represents an unacceptable security risk for administrators who only need read-only visibility.

Trap 2: Contributor

Contributor grants full write access to resources in the assigned scope, allowing junior administrators to create, modify, and delete resources, as well as manage resource locks and execute actions like starting or stopping virtual machines. While it cannot assign role-based access control to others, it still goes far beyond view-only needs and exposes the environment to accidental or malicious configuration changes. The inclusion of write and delete actions violates the principle of least privilege, so it is not appropriate for a purely read-only requirement.

Trap 3: Monitoring Reader

Monitoring Reader is a purpose-built role that grants access to read monitoring data only—such as metrics, logs, alert rules, and diagnostic settings—but it does not provide general read permission over resource configuration or properties. For example, a user with this role can see a virtual machine's CPU metrics but cannot read its storage profile or network interface settings. Because the requirement asks for visibility into all resources, not just their monitoring signals, this role is too narrowly scoped and would miss core resource details.

A
Owner
Why wrong: Owner is the highest-privilege built-in role, encompassing all permissions of Contributor plus the ability to assign roles and manage access via Azure RBAC. Granting Owner to junior administrators would allow them to change access control, elevate other users' permissions, and modify or delete any resource in the scope. This is drastically more access than required for viewing resources and represents an unacceptable security risk for administrators who only need read-only visibility.
B
Contributor
Why wrong: Contributor grants full write access to resources in the assigned scope, allowing junior administrators to create, modify, and delete resources, as well as manage resource locks and execute actions like starting or stopping virtual machines. While it cannot assign role-based access control to others, it still goes far beyond view-only needs and exposes the environment to accidental or malicious configuration changes. The inclusion of write and delete actions violates the principle of least privilege, so it is not appropriate for a purely read-only requirement.
C
Reader
The Reader role is a built-in Azure RBAC role that grants read-only access to all management-plane resource information across the assigned scope, including properties, configuration, and status. It cannot create, modify, or delete resources, nor assign permissions, making it the correct least-privilege choice for junior administrators who only need to view resources. This role satisfies the requirement without introducing any write or action capabilities.
D
Monitoring Reader
Why wrong: Monitoring Reader is a purpose-built role that grants access to read monitoring data only—such as metrics, logs, alert rules, and diagnostic settings—but it does not provide general read permission over resource configuration or properties. For example, a user with this role can see a virtual machine's CPU metrics but cannot read its storage profile or network interface settings. Because the requirement asks for visibility into all resources, not just their monitoring signals, this role is too narrowly scoped and would miss core resource details.

Question 2hardmultiple choice

The platform team wants to block deployment of virtual machines that use any size except a small approved list. Operators already have Contributor access and should keep that access for other tasks. Which Azure control should the administrator use to enforce the size restriction?

Trap 1: Create a custom RBAC role that excludes unsupported VM sizes from…

RBAC role definitions authorize actions such as Microsoft.Compute/virtualMachines/write, but they cannot inspect the request body or evaluate properties like the selected SKU. A custom role cannot "exclude unsupported VM sizes" because size is a deployment parameter evaluated by Azure Policy, not an RBAC permission. Even with full Contributor equivalent write permissions, an RBAC-only approach will still allow an operator to deploy any VM SKU if no policy denies it.

Trap 2: Apply a CanNotDelete lock to the resource group that contains the…

A CanNotDelete lock is an Azure management lock that protects resources from deletion, not from creation or update. It functions at the resource/management level and does not validate or constrain configuration values such as VM size during a PUT operation. Applying CanNotDelete to a resource group would block deleting the group and its resources, but it would do nothing to stop an administrator from deploying a VM with a non-approved SKU.

Trap 3: Assign Reader permissions to the operators and rely on Azure portal…

Assigning Reader permission would revoke all write capabilities, so users could not deploy any virtual machine at all—far exceeding the intent of blocking only unsupported VM sizes. Relying on Azure portal validation is also not an enforceable control because it exists only in the portal UI; any call through Azure CLI, PowerShell, or the REST API can bypass portal warnings and submit a compliant deployment. The requirement is to actively deny disallowed SKUs, which requires an Azure Policy definition and assignment, not a restrictive RBAC role or a user-facing UI guard.

A
Assign an Azure Policy with an allowed virtual machine size rule and the Deny effect at the subscription scope.
Azure Policy is designed to enforce configuration rules such as allowed regions or allowed VM sizes. The Deny effect blocks noncompliant deployments even when the user has Contributor permissions, because policy enforcement is separate from RBAC authorization.
B
Create a custom RBAC role that excludes unsupported VM sizes from the Contributor role.
Why wrong: RBAC role definitions authorize actions such as Microsoft.Compute/virtualMachines/write, but they cannot inspect the request body or evaluate properties like the selected SKU. A custom role cannot "exclude unsupported VM sizes" because size is a deployment parameter evaluated by Azure Policy, not an RBAC permission. Even with full Contributor equivalent write permissions, an RBAC-only approach will still allow an operator to deploy any VM SKU if no policy denies it.
C
Apply a CanNotDelete lock to the resource group that contains the virtual machines.
Why wrong: A CanNotDelete lock is an Azure management lock that protects resources from deletion, not from creation or update. It functions at the resource/management level and does not validate or constrain configuration values such as VM size during a PUT operation. Applying CanNotDelete to a resource group would block deleting the group and its resources, but it would do nothing to stop an administrator from deploying a VM with a non-approved SKU.
D
Assign Reader permissions to the operators and rely on Azure portal validation.
Why wrong: Assigning Reader permission would revoke all write capabilities, so users could not deploy any virtual machine at all—far exceeding the intent of blocking only unsupported VM sizes. Relying on Azure portal validation is also not an enforceable control because it exists only in the portal UI; any call through Azure CLI, PowerShell, or the REST API can bypass portal warnings and submit a compliant deployment. The requirement is to actively deny disallowed SKUs, which requires an Azure Policy definition and assignment, not a restrictive RBAC role or a user-facing UI guard.

Question 3mediummultiple choice

Your company has two subscriptions named Dev-Sub and Prod-Sub. A new administrator must be able to create resource groups only in Dev-Sub and must not have any permissions in Prod-Sub. What should you do?

Trap 1: Assign Contributor to the administrator at the management group…

A management group scope is an inherited container; Contributor assigned there would propagate to every subscription nested under that management group, which in a typical enterprise includes both Dev-Sub and Prod-Sub, thereby over-permissioning the administrator. Even in a contrived setup where only Dev-Sub sits beneath the management group, such a high-level assignment is administratively risky and violates the principle of least privilege, because any future subscription added to that management group would automatically also receive Contributor. The requirement is explicitly for Dev-Sub only, so the assignment must be scoped at the subscription level rather than the management group.

Trap 2: Assign Owner to the administrator at the resource group scope in…

Owner at a resource group scope is doubly problematic: Owner includes the 'Manage Access' ability, allowing the administrator to grant roles to themselves or others, which is far greater privilege than the required Contributor role provides. Additionally, the resource group scope may not exist at the time of the assignment, because the administrator must first have permission at the subscription level to even create the resource group, creating a circular dependency. Even if the resource group already existed, this scope would restrict the administrator to only that one resource group, preventing them from managing other resource groups or resources in Dev-Sub that need oversight.

Trap 3: Assign Reader to the administrator at the Prod-Sub scope and…

Reader at the Prod-Sub scope is unnecessary because the administrator's duties are confined to Dev resources; read-only access to production is both irrelevant and potentially a data exposure risk. More critically, Contributor at the tenant root group ('/') would grant contributor permissions to every management group, subscription, resource group, and resource across the entire Azure tenant, completely circumventing the intended restriction to Dev-Sub. Such a wide scope is among the most dangerous RBAC misconfigurations possible, as it effectively turns the administrator into a contributor over the whole organization, far beyond any legitimate requirement.

A
Assign Contributor to the administrator at the management group scope.
Why wrong: A management group scope is an inherited container; Contributor assigned there would propagate to every subscription nested under that management group, which in a typical enterprise includes both Dev-Sub and Prod-Sub, thereby over-permissioning the administrator. Even in a contrived setup where only Dev-Sub sits beneath the management group, such a high-level assignment is administratively risky and violates the principle of least privilege, because any future subscription added to that management group would automatically also receive Contributor. The requirement is explicitly for Dev-Sub only, so the assignment must be scoped at the subscription level rather than the management group.
B
Assign Contributor to the administrator at the Dev-Sub scope.
Assigning Contributor at the Dev-Sub subscription scope grants the administrator permission to create and manage all resource types within that subscription, including resource groups and any resources inside them, without granting access to other subscriptions. Contributor deliberately excludes the 'Manage Access' permission, so the administrator cannot delegate roles to others, aligning with the principle of least privilege. This scope exactly matches the requirement to administer Dev resources, and because the role assignment is scoped to the subscription, it cannot affect Prod-Sub or any other Azure scope.
C
Assign Owner to the administrator at the resource group scope in Dev-Sub.
Why wrong: Owner at a resource group scope is doubly problematic: Owner includes the 'Manage Access' ability, allowing the administrator to grant roles to themselves or others, which is far greater privilege than the required Contributor role provides. Additionally, the resource group scope may not exist at the time of the assignment, because the administrator must first have permission at the subscription level to even create the resource group, creating a circular dependency. Even if the resource group already existed, this scope would restrict the administrator to only that one resource group, preventing them from managing other resource groups or resources in Dev-Sub that need oversight.
D
Assign Reader to the administrator at the Prod-Sub scope and Contributor at the tenant root group.
Why wrong: Reader at the Prod-Sub scope is unnecessary because the administrator's duties are confined to Dev resources; read-only access to production is both irrelevant and potentially a data exposure risk. More critically, Contributor at the tenant root group ('/') would grant contributor permissions to every management group, subscription, resource group, and resource across the entire Azure tenant, completely circumventing the intended restriction to Dev-Sub. Such a wide scope is among the most dangerous RBAC misconfigurations possible, as it effectively turns the administrator into a contributor over the whole organization, far beyond any legitimate requirement.

Question 4hardmultiple choice

Based on the exhibit, where should you assign the Reader role so the Auditors group can read every current and future resource in the Sales subscription, including resource groups created later, while not granting access to the Research subscription?

Exhibit

Tenant hierarchy:
- Corp (management group)
  - Sales (subscription)
    - RG-Web
    - RG-Data
  - Research (subscription)
    - RG-Lab

Requirement from the business owner:
- Auditors must view all resources in Sales.
- Any new resource group created under Sales must also be covered.
- Auditors must not see resources in Research.

Trap 1: Assign Reader to RG-Web, because the group can then inherit access…

Assigning Reader at the RG-Web scope limits access to only that resource group and the resources it currently contains; RG-Data, which also resides in the Sales subscription, would remain completely inaccessible to the auditors. Additionally, this scope does not cover any future resource groups created in the Sales subscription, so new resources would automatically be excluded. Because the requirement is to grant read access across all current and future resources in Sales, a single resource-group assignment is insufficient and far narrower than the required subscription-level scope.

Trap 2: Assign Reader to the Corp management group, because that is the…

The Corp management group is the root management group that contains both the Sales and Research subscriptions, so a Reader assignment at this scope would inherit down to every subscription beneath it, granting auditors read access to Research, which is explicitly prohibited. Management group scope is not the only way to cover multiple subscriptions; you can assign the Reader role directly at the Sales subscription scope to achieve the desired coverage without spilling permissions. Using a management group when subscription scope suffices violates the principle of least privilege, because it expands the blast radius far beyond the stated requirement.

Trap 3: Assign Reader to each resource individually, because that avoids…

Assigning Reader individually to each resource requires enumerating every resource, and you must repeat this process for every resource created in the future, making it operationally burdensome and highly prone to omissions. This approach ignores Azure RBAC’s inheritance model, which is designed to propagate permissions from parent scopes to child resources. Even if you could track all resources today, any new resource group or resource deployed by a template would lack access until you manually add another role assignment, so it fails the requirement for full, ongoing coverage in the Sales subscription.

A
Assign Reader to RG-Web, because the group can then inherit access to resources in that resource group only.
Why wrong: Assigning Reader at the RG-Web scope limits access to only that resource group and the resources it currently contains; RG-Data, which also resides in the Sales subscription, would remain completely inaccessible to the auditors. Additionally, this scope does not cover any future resource groups created in the Sales subscription, so new resources would automatically be excluded. Because the requirement is to grant read access across all current and future resources in Sales, a single resource-group assignment is insufficient and far narrower than the required subscription-level scope.
B
Assign Reader to the Sales subscription, because subscription-level scope includes all current and future resource groups and resources in that subscription.
Subscription scope is the narrowest scope that satisfies the requirement. RBAC inheritance flows downward, so a Reader assignment at the Sales subscription applies to all current and future resource groups and resources inside Sales, but it does not grant access to the Research subscription.
C
Assign Reader to the Corp management group, because that is the only scope that can cover multiple subscriptions.
Why wrong: The Corp management group is the root management group that contains both the Sales and Research subscriptions, so a Reader assignment at this scope would inherit down to every subscription beneath it, granting auditors read access to Research, which is explicitly prohibited. Management group scope is not the only way to cover multiple subscriptions; you can assign the Reader role directly at the Sales subscription scope to achieve the desired coverage without spilling permissions. Using a management group when subscription scope suffices violates the principle of least privilege, because it expands the blast radius far beyond the stated requirement.
D
Assign Reader to each resource individually, because that avoids inheritance and limits visibility to selected items.
Why wrong: Assigning Reader individually to each resource requires enumerating every resource, and you must repeat this process for every resource created in the future, making it operationally burdensome and highly prone to omissions. This approach ignores Azure RBAC’s inheritance model, which is designed to propagate permissions from parent scopes to child resources. Even if you could track all resources today, any new resource group or resource deployed by a template would lack access until you manually add another role assignment, so it fails the requirement for full, ongoing coverage in the Sales subscription.

Question 5mediummultiple choice

A web app running in Azure App Service must upload images to a blob container without storing any account keys, passwords, or connection strings in configuration. The app uses only one Azure resource. What should the administrator configure?

Trap 1: The storage account key, because it is the simplest way to…

Using the storage account key fails because the key is a shared secret that must be stored in application settings or configuration, directly violating the requirement to avoid keys or secrets. It also grants full access to the entire storage account, including all containers and blobs, rather than least-privilege access to just the target container. The key must be manually rotated, and any leak exposes the whole account, whereas a managed identity has no persistent secret to steal.

Trap 2: A shared access signature embedded in the app settings, because SAS…

A shared access signature (SAS) is still a secret token that must be embedded in app settings, so it does not satisfy the no-secrets requirement. Unlike a managed identity, a SAS is not tied to an Azure AD identity; it is a cryptographic key that grants access based on the token's signature and expiry. It also needs to be regenerated and rotated over time, and if it is exposed, an attacker can use it until it expires. A managed identity, by contrast, is backed by Azure AD and needs no stored credential in the application.

Trap 3: An anonymous public container with write access disabled on the…

Anonymous public container access does not provide any authenticated write capability; disabling write access on the container means the web app cannot upload images at all. It would allow unauthenticated public read access to blobs, which is a severe security exposure and far beyond the minimal permissions needed for an application to upload images. The scenario requires controlled, authenticated access, which cannot be achieved with public containers, regardless of write settings.

A
A system-assigned managed identity on the App Service and an Azure RBAC role on the storage account.
A system-assigned managed identity is ideal when one Azure resource needs to access storage without secrets. The identity is created and deleted with the App Service, and RBAC can grant only the storage permissions required. This removes the need to embed keys or connection strings and aligns with credential-free application access.
B
The storage account key, because it is the simplest way to authenticate an application securely.
Why wrong: Using the storage account key fails because the key is a shared secret that must be stored in application settings or configuration, directly violating the requirement to avoid keys or secrets. It also grants full access to the entire storage account, including all containers and blobs, rather than least-privilege access to just the target container. The key must be manually rotated, and any leak exposes the whole account, whereas a managed identity has no persistent secret to steal.
C
A shared access signature embedded in the app settings, because SAS is the same as managed identity.
Why wrong: A shared access signature (SAS) is still a secret token that must be embedded in app settings, so it does not satisfy the no-secrets requirement. Unlike a managed identity, a SAS is not tied to an Azure AD identity; it is a cryptographic key that grants access based on the token's signature and expiry. It also needs to be regenerated and rotated over time, and if it is exposed, an attacker can use it until it expires. A managed identity, by contrast, is backed by Azure AD and needs no stored credential in the application.
D
An anonymous public container with write access disabled on the account.
Why wrong: Anonymous public container access does not provide any authenticated write capability; disabling write access on the container means the web app cannot upload images at all. It would allow unauthenticated public read access to blobs, which is a severe security exposure and far beyond the minimal permissions needed for an application to upload images. The scenario requires controlled, authenticated access, which cannot be achieved with public containers, regardless of write settings.

Question 6easymultiple choice

A company wants to group several subscriptions for Finance, HR, and Engineering so that the same governance settings can be applied above the subscription level. What should the administrator create?

Trap 1: A resource group

A resource group is a container for Azure resources such as virtual machines, storage accounts, and databases within a single subscription. It helps organize and manage resources that share a lifecycle, but it cannot group multiple subscriptions or provide governance inheritance across subscriptions.

Trap 2: A tag

Tags are metadata key-value pairs used to categorize resources, such as by department or cost center. They are useful for reporting and filtering, but they do not create a hierarchy and cannot apply governance settings above the subscription level.

Trap 3: A resource lock

A resource lock prevents accidental deletion or modification of a specific resource or resource group, depending on where it is applied. It is a protection mechanism, not an organizational structure, and it does not group subscriptions or enable inherited governance across them.

A
A management group
Management groups are designed to contain subscriptions and provide a hierarchy above the subscription level. Policies, access controls, and other governance settings can be assigned at the management group level and inherited by the subscriptions underneath it, which makes them the correct choice for organizing Finance, HR, and Engineering subscriptions together.
B
A resource group
Why wrong: A resource group is a container for Azure resources such as virtual machines, storage accounts, and databases within a single subscription. It helps organize and manage resources that share a lifecycle, but it cannot group multiple subscriptions or provide governance inheritance across subscriptions.
C
A tag
Why wrong: Tags are metadata key-value pairs used to categorize resources, such as by department or cost center. They are useful for reporting and filtering, but they do not create a hierarchy and cannot apply governance settings above the subscription level.
D
A resource lock
Why wrong: A resource lock prevents accidental deletion or modification of a specific resource or resource group, depending on where it is applied. It is a protection mechanism, not an organizational structure, and it does not group subscriptions or enable inherited governance across them.

Question 7mediummultiple choice

A developer can access an Azure Blob container from the portal using Microsoft Entra sign-in, but their custom app gets a 403 error when reading the same blob. The storage account is configured to use Azure AD authorization. What is the most likely fix?

Trap 1: Assign the user the Reader role on the subscription.

The Reader role on the subscription provides management-plane visibility, enabling the user to see storage accounts and their properties via ARM, but it does not grant any data-plane permissions on blob containers. Azure Storage enforces a strict separation between control plane (management) and data plane (data access), and blob reads are authorized by data-plane roles such as Storage Blob Data Reader. The user's Azure AD token would still be rejected by the blob endpoint because the Reader role lacks the Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read action required to read blob content.

Trap 2: Enable shared key access so the app can bypass Azure AD permissions.

Enabling shared key access would allow requests to be authenticated with the storage account key, but it does not grant the user's Azure AD identity any data-plane permissions. It changes the authentication mechanism from Azure AD to key-based, and because shared key access is a tenant-wide setting, it would expose the entire storage account to anyone with the key—rather than selectively granting this user read access to blobs. This weakens security and does not address the 403, which stems from a missing RBAC data role.

Trap 3: Move the container to the Hot tier so Azure AD authentication can…

Changing the container's access tier to Hot does not affect authentication or authorization in any way. The Hot, Cool, and Archive tiers are designed to manage storage costs and retrieval latency, not to control which identities can access data. If the user does not have a data-plane role assignment, Azure AD authorization will fail identically in the Hot tier, so the 403 would persist. The only effective fix is to assign the appropriate RBAC data role, such as Storage Blob Data Reader.

A
Assign the user the Storage Blob Data Reader role on the container or storage account.
A 403 in this scenario usually means the identity lacks data-plane permissions. The user needs an Azure RBAC role such as Storage Blob Data Reader at the appropriate scope so the app can read blob content through Azure AD authorization.
B
Assign the user the Reader role on the subscription.
Why wrong: The Reader role on the subscription provides management-plane visibility, enabling the user to see storage accounts and their properties via ARM, but it does not grant any data-plane permissions on blob containers. Azure Storage enforces a strict separation between control plane (management) and data plane (data access), and blob reads are authorized by data-plane roles such as Storage Blob Data Reader. The user's Azure AD token would still be rejected by the blob endpoint because the Reader role lacks the Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read action required to read blob content.
C
Enable shared key access so the app can bypass Azure AD permissions.
Why wrong: Enabling shared key access would allow requests to be authenticated with the storage account key, but it does not grant the user's Azure AD identity any data-plane permissions. It changes the authentication mechanism from Azure AD to key-based, and because shared key access is a tenant-wide setting, it would expose the entire storage account to anyone with the key—rather than selectively granting this user read access to blobs. This weakens security and does not address the 403, which stems from a missing RBAC data role.
D
Move the container to the Hot tier so Azure AD authentication can succeed.
Why wrong: Changing the container's access tier to Hot does not affect authentication or authorization in any way. The Hot, Cool, and Archive tiers are designed to manage storage costs and retrieval latency, not to control which identities can access data. If the user does not have a data-plane role assignment, Azure AD authorization will fail identically in the Hot tier, so the 403 would persist. The only effective fix is to assign the appropriate RBAC data role, such as Storage Blob Data Reader.

Question 8mediummultiple choice

Based on the exhibit, the Prod management group contains three subscriptions that host application workloads. An operations group must be able to read all current and future resources in those Prod subscriptions, but it must not have access to Sandbox. Where should you assign the Reader role?

Exhibit

Management group layout:
- Corp
  - Prod
    - AppSub1
    - AppSub2
    - AppSub3
  - Sandbox
    - DevSub1
Requirement:
- OpsGroup must read everything in Prod only
- New subscriptions added under Prod should inherit access automatically

Trap 1: Assign Reader to OpsGroup at the Corp management group.

The Corp management group is a higher-level scope that includes both Prod and Sandbox, so selecting it would inadvertently grant Reader access to Sandbox resources. Since RBAC assignments at a management group are inherited by all child subscriptions, resource groups, and resources, this assignment would exceed the stated security boundary. Scoping to Prod instead ensures Sandbox remains excluded while still covering all Prod subscriptions and future additions under Prod.

Trap 2: Assign Reader to OpsGroup at one application resource group in…

Assigning Reader at the application resource group limits the permission boundary to only the resources within that single resource group. Resources in other resource groups within AppSub1, and every other subscription under Prod, would not receive Reader access, and future subscriptions added to Prod would not automatically inherit any permissions. This falls short of the requirement for uniform read-only access across all Prod subscriptions and their resources.

Trap 3: Assign Reader to OpsGroup at each subscription individually.

Assigning Reader to each subscription individually is administratively redundant and hard to scale, as every new subscription added under Prod would require a separate assignment to maintain the same access. This approach also creates a risk of inconsistency, where some subscriptions might be missed during onboarding, leaving teams without the necessary read access. Management group scoping is the preferred method because a single assignment applies uniformly to all current and future child subscriptions under Prod.

A
Assign Reader to OpsGroup at the Corp management group.
Why wrong: The Corp management group is a higher-level scope that includes both Prod and Sandbox, so selecting it would inadvertently grant Reader access to Sandbox resources. Since RBAC assignments at a management group are inherited by all child subscriptions, resource groups, and resources, this assignment would exceed the stated security boundary. Scoping to Prod instead ensures Sandbox remains excluded while still covering all Prod subscriptions and future additions under Prod.
B
Assign Reader to OpsGroup at the Prod management group.
Assigning at the Prod management group gives inherited read access to every subscription, resource group, and resource under Prod. It also automatically applies to future subscriptions added under Prod, while keeping Sandbox out of scope.
C
Assign Reader to OpsGroup at one application resource group in AppSub1.
Why wrong: Assigning Reader at the application resource group limits the permission boundary to only the resources within that single resource group. Resources in other resource groups within AppSub1, and every other subscription under Prod, would not receive Reader access, and future subscriptions added to Prod would not automatically inherit any permissions. This falls short of the requirement for uniform read-only access across all Prod subscriptions and their resources.
D
Assign Reader to OpsGroup at each subscription individually.
Why wrong: Assigning Reader to each subscription individually is administratively redundant and hard to scale, as every new subscription added under Prod would require a separate assignment to maintain the same access. This approach also creates a risk of inconsistency, where some subscriptions might be missed during onboarding, leaving teams without the necessary read access. Management group scoping is the preferred method because a single assignment applies uniformly to all current and future child subscriptions under Prod.

Question 9mediummulti select

A contractor pool changes every month. The operations team wants Azure role access to stay the same when people join or leave, without editing role assignments for each person. Which two actions should the administrator take? Select two.

Trap 1: Assign the Azure role directly to each contractor account.

Adding role assignments directly to each contractor account means every new contractor requires a new RBAC assignment and every departure requires a revocation, causing exactly the frequent change churn the operations team wants to avoid. This approach also leaves stale grants when removals are missed, increasing security risk, and makes entitlement reviews harder because the assignments themselves change with each contractor cycle. It is functionally correct but operationally inefficient compared to a group-based assignment.

Trap 2: Create a Microsoft 365 group and use it for VM sign-in.

Microsoft 365 groups are designed for collaboration scenarios such as Teams, SharePoint, and unified mailboxes, not as the primary container for delegating Azure resource permissions. Although they can technically hold security principals, Azure RBAC common practice strongly prefers Azure AD security groups for access control. Additionally, 'VM sign-in' is a data-plane concern that wouldn't be resolved by a group type choice; Azure RBAC governs the management plane, and VM login requires separate configuration like Azure AD-joined VMs.

Trap 3: Use a user-assigned managed identity for each contractor.

User-assigned managed identities are workload identities used by Azure resources to authenticate to services (e.g., a VM accessing Key Vault), and they cannot represent individual human contractors. Since they are service principals rather than user accounts, they do not support interactive sign-on, password resets, or per-person audit logs. Using one per contractor would conflate human access with workload access and break the monthly membership model entirely.

A
Create a security group in Microsoft Entra ID for the contractor pool.
A security group is the right identity container for changing membership. Contractors can be added or removed from the group without touching the Azure RBAC assignment itself, which keeps access administration simple and consistent over time.
B
Assign the Azure role directly to each contractor account.
Why wrong: Adding role assignments directly to each contractor account means every new contractor requires a new RBAC assignment and every departure requires a revocation, causing exactly the frequent change churn the operations team wants to avoid. This approach also leaves stale grants when removals are missed, increasing security risk, and makes entitlement reviews harder because the assignments themselves change with each contractor cycle. It is functionally correct but operationally inefficient compared to a group-based assignment.
C
Create a Microsoft 365 group and use it for VM sign-in.
Why wrong: Microsoft 365 groups are designed for collaboration scenarios such as Teams, SharePoint, and unified mailboxes, not as the primary container for delegating Azure resource permissions. Although they can technically hold security principals, Azure RBAC common practice strongly prefers Azure AD security groups for access control. Additionally, 'VM sign-in' is a data-plane concern that wouldn't be resolved by a group type choice; Azure RBAC governs the management plane, and VM login requires separate configuration like Azure AD-joined VMs.
D
Assign the Azure role to the security group rather than to individual users.
Assigning the Azure role to the security group rather than to individual users decouples the role assignment from membership churn. The single RBAC assignment to the group persists across monthly contractor changes, and only the group's membership list is updated. This minimizes administrative overhead, reduces the risk of orphaned permissions, and keeps access reviews aligned with the group.
E
Use a user-assigned managed identity for each contractor.
Why wrong: User-assigned managed identities are workload identities used by Azure resources to authenticate to services (e.g., a VM accessing Key Vault), and they cannot represent individual human contractors. Since they are service principals rather than user accounts, they do not support interactive sign-on, password resets, or per-person audit logs. Using one per contractor would conflate human access with workload access and break the monthly membership model entirely.

Question 10mediummulti select

A contractor must manage only VM1 and VM2 in rg-prod. The contractor must not be able to manage any other resource in the resource group. Which two role assignment scopes should you create? Select two.

Trap 1: Assign the role at the rg-prod resource group scope.

Assigning the role at rg-prod scope grants the contractor permission on every resource contained in that resource group, including any network interface (NIC), disk, network security group, or other VM not equal to VM1/VM2. While this is more contained than subscription scope, it still exceeds the requirement because the contractor would be able to manage all current and future resources placed in rg-prod. Resource-group scoped RBAC assignments do not provide object-level filtering; they apply uniformly to every resource within the resource group. Thus it is wrong because the requested minimal access scope is per-VM, not per-resource-group.

Trap 2: Assign the role at the subscription scope.

A role assignment at subscription scope cascades to all resource groups and resources within the subscription, meaning the contractor would gain management rights over every VM, network interface, storage account, and other resource in rg-prod and any other resource group. This violates the explicit 'only vm1 and vm2' requirement because subscription-scoped assignments override any narrower assignments and cannot be restricted to a subset of resources. Even with conditional access or additional deny assignments, subscription scope is far too broad and would expose unrelated Azure resources.

Trap 3: Assign the role at the management group scope.

Management group scope propagates the role assignment down to every subscription in the management group's hierarchy, covering potentially thousands of resources across multiple subscriptions. This is the broadest type of Azure RBAC scope and would grant the contractor full management capabilities on VMs and other services far outside rg-prod. Because management group hierarchy can include rg-prod only as a tiny subset, this scope is unjustifiably expansive. It is incorrect for the same reason as broader scopes generally but specifically because it cascades across subscriptions and management groups.

A
Assign the role at the VM1 resource scope.
In Azure RBAC, a role assignment scoped to a specific resource applies only to that resource. Assigning the Virtual Machine Contributor role (or similar) on VM1's resource ID gives the contractor permission to manage VM1 without inheriting any access to VM2 or any other resource in rg-prod. This satisfies least privilege for VM1, and when combined with an identical assignment on VM2, the contractor's effective scope is exactly those two VMs. This is a correct approach because resource-scope assignments cannot affect sibling resources.
B
Assign the role at the VM2 resource scope.
This assignment targets VM2's own scope, so the contractor's permissions are limited to VM2's operations such as start, stop, restart, or apply extensions, with no visibility into rg-prod's other resources. Since RBAC scopes do not overlap from one resource to another, this assignment complements the VM1 resource-scope assignment. Together, the two assignments create a composite effective set of permissions covering only VM1 and VM2. It is correct because resource-scope assignments are the narrowest built-in Azure RBAC scope.
C
Assign the role at the rg-prod resource group scope.
Why wrong: Assigning the role at rg-prod scope grants the contractor permission on every resource contained in that resource group, including any network interface (NIC), disk, network security group, or other VM not equal to VM1/VM2. While this is more contained than subscription scope, it still exceeds the requirement because the contractor would be able to manage all current and future resources placed in rg-prod. Resource-group scoped RBAC assignments do not provide object-level filtering; they apply uniformly to every resource within the resource group. Thus it is wrong because the requested minimal access scope is per-VM, not per-resource-group.
D
Assign the role at the subscription scope.
Why wrong: A role assignment at subscription scope cascades to all resource groups and resources within the subscription, meaning the contractor would gain management rights over every VM, network interface, storage account, and other resource in rg-prod and any other resource group. This violates the explicit 'only vm1 and vm2' requirement because subscription-scoped assignments override any narrower assignments and cannot be restricted to a subset of resources. Even with conditional access or additional deny assignments, subscription scope is far too broad and would expose unrelated Azure resources.
E
Assign the role at the management group scope.
Why wrong: Management group scope propagates the role assignment down to every subscription in the management group's hierarchy, covering potentially thousands of resources across multiple subscriptions. This is the broadest type of Azure RBAC scope and would grant the contractor full management capabilities on VMs and other services far outside rg-prod. Because management group hierarchy can include rg-prod only as a tiny subset, this scope is unjustifiably expansive. It is incorrect for the same reason as broader scopes generally but specifically because it cascades across subscriptions and management groups.

Question 11hardmulti select

A subscription already grants Contributor to an application team. The organization wants to prevent deployments in unsupported Azure regions and ensure every new resource has an Environment tag. Which two controls should be implemented with Azure Policy rather than RBAC? Select two.

Trap 1: Create a custom RBAC role that blocks resources deployed outside…

A custom RBAC role that attempts to block resources outside approved regions cannot work because RBAC permissions are based on actions (such as Microsoft.Resources/deployments/write) and do not inspect resource properties like location during evaluation. Even with deny assignments or custom roles, you cannot express a condition that says 'this deployment is allowed only if the region is X' purely through role-based permissions. Azure Policy is the service that performs property-based evaluation and is the appropriate mechanism for this requirement.

Trap 2: Add a CanNotDelete lock to every resource group.

Adding a CanNotDelete lock to every resource group is wrong here because locks are designed to prevent accidental deletion or modification of critical resources, not to enforce deployment-time compliance rules like allowed regions or required tags. A lock does not evaluate the properties of a newly deployed resource; it operates after the resource exists and cannot inspect the deployment request itself. Contributor users would still be able to create resources in any region, and the lock would not add the Environment tag or reject an unapproved location.

Trap 3: Grant User Access Administrator to the deployment team.

Granting User Access Administrator to the deployment team is incorrect because that role only manages Azure RBAC role assignments and does not enforce any governance or compliance requirements on resource deployments. It would give the team the ability to grant themselves or others additional permissions, making governance worse, but it would not restrict the region or validate tags. Since the team already has Contributor, they can create resources; adding User Access Administrator does nothing to constrain where or how they do it.

A
Assign an allowed-locations policy at the management group or subscription scope.
An allowed-locations policy assignment at the management group or subscription scope is correct because Azure Policy evaluates the location property of each resource during deployment and can deny any request that specifies a non-approved region. Policy inheritance means the restriction applies to all child subscriptions and resource groups without requiring additional assignments, and it does not depend on the contributor role assignment the team already has. Because the team is a Contributor, they can create resources anywhere within the subscription; only a policy can intercept and block that action based on the region.
B
Create a custom RBAC role that blocks resources deployed outside approved regions.
Why wrong: A custom RBAC role that attempts to block resources outside approved regions cannot work because RBAC permissions are based on actions (such as Microsoft.Resources/deployments/write) and do not inspect resource properties like location during evaluation. Even with deny assignments or custom roles, you cannot express a condition that says 'this deployment is allowed only if the region is X' purely through role-based permissions. Azure Policy is the service that performs property-based evaluation and is the appropriate mechanism for this requirement.
C
Assign a policy that enforces the Environment tag on new resources.
Assigning a policy that enforces the Environment tag on new resources (using effects such as deny, append, or modify) is a correct governance action because tags are metadata stored on the resource itself and are fully inspectable by Azure Policy. For example, a policy with the deny effect can reject deployments that omit the tag, while the append or modify effect can automatically add the tag after creation. This works independently of RBAC, so even users with Contributor rights cannot bypass the tagging requirement.
D
Add a CanNotDelete lock to every resource group.
Why wrong: Adding a CanNotDelete lock to every resource group is wrong here because locks are designed to prevent accidental deletion or modification of critical resources, not to enforce deployment-time compliance rules like allowed regions or required tags. A lock does not evaluate the properties of a newly deployed resource; it operates after the resource exists and cannot inspect the deployment request itself. Contributor users would still be able to create resources in any region, and the lock would not add the Environment tag or reject an unapproved location.
E
Grant User Access Administrator to the deployment team.
Why wrong: Granting User Access Administrator to the deployment team is incorrect because that role only manages Azure RBAC role assignments and does not enforce any governance or compliance requirements on resource deployments. It would give the team the ability to grant themselves or others additional permissions, making governance worse, but it would not restrict the region or validate tags. Since the team already has Contributor, they can create resources; adding User Access Administrator does nothing to constrain where or how they do it.

Question 12hardmultiple choice

A Windows VM runs an application that uploads files to a blob container every hour. Security forbids storing storage account keys or long-lived SAS tokens on the VM. The application must be able to write only to that container and nothing else. What should the administrator configure?

Trap 1: Store the storage account key in an environment variable on the VM

Storing the storage account key in an environment variable introduces a long-lived symmetric secret directly onto the VM. The key grants full data-plane access to every container, queue, table, and file in the entire storage account, far exceeding the requirement to upload only to one blob container. Additionally, environment variables are visible to any process or user with access to the VM, making the key vulnerable to exfiltration and requiring manual rotation instead of using Azure AD-backed identity.

Trap 2: Create a service SAS with write permission on the storage account

A service SAS with write permission at the storage account level creates a delegation token scoped to the entire Blob service, meaning the bearer can write to any container in the account, not just the intended one. Even if the SAS is designed for a single service, it is still a shared secret that must be embedded in the app's configuration or URL. Unlike managed identity, a SAS cannot be automatically rotated by Azure AD and is harder to revoke per-resource without invalidating all tokens sharing the same policy.

Trap 3: Assign Contributor on the storage account to the VM's…

Contributor on the storage account is an Azure Resource Manager (ARM) role that governs control-plane operations such as creating, deleting, or updating the storage account itself. It does not include data-plane permissions, so the VM's managed identity would still be unable to upload blobs to a container. Furthermore, even if data access were included, the account-wide scope violates least privilege because it grants management rights to the entire storage resource instead of limiting access to the specific container.

A
Store the storage account key in an environment variable on the VM
Why wrong: Storing the storage account key in an environment variable introduces a long-lived symmetric secret directly onto the VM. The key grants full data-plane access to every container, queue, table, and file in the entire storage account, far exceeding the requirement to upload only to one blob container. Additionally, environment variables are visible to any process or user with access to the VM, making the key vulnerable to exfiltration and requiring manual rotation instead of using Azure AD-backed identity.
B
Create a service SAS with write permission on the storage account
Why wrong: A service SAS with write permission at the storage account level creates a delegation token scoped to the entire Blob service, meaning the bearer can write to any container in the account, not just the intended one. Even if the SAS is designed for a single service, it is still a shared secret that must be embedded in the app's configuration or URL. Unlike managed identity, a SAS cannot be automatically rotated by Azure AD and is harder to revoke per-resource without invalidating all tokens sharing the same policy.
C
Assign Storage Blob Data Contributor to the VM's managed identity at the container scope
A managed identity avoids stored credentials, and the Storage Blob Data Contributor role grants blob read/write permissions without exposing account keys. Assigning it at the container scope keeps access limited to one container instead of the whole storage account. This is the least-privilege, Azure-native approach for an app that needs ongoing upload access.
D
Assign Contributor on the storage account to the VM's system-assigned identity
Why wrong: Contributor on the storage account is an Azure Resource Manager (ARM) role that governs control-plane operations such as creating, deleting, or updating the storage account itself. It does not include data-plane permissions, so the VM's managed identity would still be unable to upload blobs to a container. Furthermore, even if data access were included, the account-wide scope violates least privilege because it grants management rights to the entire storage resource instead of limiting access to the specific container.

Question 13mediummatching

Match each access requirement to the most appropriate Azure Storage authentication or authorization approach.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Enable a managed identity on the VM and assign a data-plane RBAC role

User delegation SAS

Storage account key

Azure RBAC data role assignment

Trap 1: SAS: Uses Azure AD identities to authenticate.

This is a misconception: SAS tokens do not authenticate an identity. Instead, a SAS carries a signed token that authorizes anonymous bearer access (the token itself is the key), and it is usually signed with the storage account key or a user-delegation key. While a user-delegation SAS is created using an Azure AD identity's key, the SAS token does not contain the identity's credentials and does not perform authentication.

Trap 2: Azure AD authentication: Provides anonymous read access.

Azure AD authentication requires a valid OAuth 2.0 token from Azure AD; it is necessarily authenticated and never anonymous. Anonymous read access is achieved only when public access is enabled on the container and the request presents no credentials. Since Azure AD authentication involves a token in the Authorization header, it is the antithesis of anonymous access.

A
SAS: Provides time-limited delegated access with specified permissions.
A Shared Access Signature (SAS) is a cryptographically signed URI that grants time-limited, delegated access to specific Azure Storage resources without exposing the storage account key. You can specify allowed permissions (e.g., read, write, delete, list) and a validity window, making it suitable for sharing temporary access. The token is signed with either the account key or a user-delegation key derived from Azure AD, and it is validated by the service for each request.
B
Azure AD authentication: Uses Azure AD identities to authenticate users and applications.
Azure AD authentication signs the request with an OAuth 2.0 access token obtained by the user or application after authenticating to Azure AD. This method supports Azure AD identities, service principals, and managed identities, and integrates with RBAC to authorize actions. It is the recommended alternative to Shared Key authorization because it enables conditional access, MFA, and auditing.
C
Public access: Allows anonymous read access to containers and blobs.
Public access is a container/account-level setting that allows any unauthenticated client to issue read requests to blobs or container metadata. It can be configured as 'Blob' (anonymous read only for blobs) or 'Container' (anonymous read plus list of blobs). Because no identity or token is presented, this access is anonymous and is typically used for immutable, universally accessible content such as web assets.
D
RBAC: Assigns granular permissions to Azure AD users, groups, or apps.
RBAC grants permissions via role assignments to users, groups, or apps in Azure AD, with built-in roles such as Storage Blob Data Owner/Reader/Contributor. Roles can be scoped to a management group, subscription, resource group, storage account, or an individual container/queue. RBAC is the primary authorization mechanism for Azure AD-authenticated requests, meaning the request must first be authenticated via Azure AD.
E
SAS: Uses Azure AD identities to authenticate.
Why wrong: This is a misconception: SAS tokens do not authenticate an identity. Instead, a SAS carries a signed token that authorizes anonymous bearer access (the token itself is the key), and it is usually signed with the storage account key or a user-delegation key. While a user-delegation SAS is created using an Azure AD identity's key, the SAS token does not contain the identity's credentials and does not perform authentication.
F
Azure AD authentication: Provides anonymous read access.
Why wrong: Azure AD authentication requires a valid OAuth 2.0 token from Azure AD; it is necessarily authenticated and never anonymous. Anonymous read access is achieved only when public access is enabled on the container and the request presents no credentials. Since Azure AD authentication involves a token in the Authorization header, it is the antithesis of anonymous access.

Question 14mediummultiple choice

A contractor needs read-only access to resources in one application resource group. The access must be removed immediately when the contractor is removed from the contractor team. What is the best access strategy?

Trap 1: Assign Reader directly to the contractor's user account at the…

Assigning Reader directly to the contractor's user account at the subscription scope bypasses group-based management and exposes all resource groups in the subscription, including those unrelated to the contractor's role. Direct user assignments create administrative overhead during personnel changes, as each user must be manually updated or removed instead of simply adding or removing them from a central Entra ID group. The correct assignment should target the contractor group at the resource group scope to achieve least privilege and simplify access reviews.

Trap 2: Assign Contributor to the contractor group at the resource group…

The Contributor role at the resource group scope grants full management rights to all resources in that resource group, including the ability to create, delete, and modify resources—directly contradicting the read-only requirement. Contributor also allows altering the configuration of existing resources, which could cause unintended outages or security changes, even though it cannot assign roles to others. Reader is the only built-in role that provides read-only access, and it must be assigned at the appropriate scope.

Trap 3: Assign Reader to the contractor group at the management group scope.

Assigning Reader to the contractor group at the management group scope places the role assignment on the root container, causing the role to be inherited by every subscription and resource group beneath it. This violates least privilege because the contractor would gain read access to unrelated resources across the entire management hierarchy, not just the single resource group. While group-based assignment is the correct approach, the scope must be narrowed to the specific resource group to limit the blast radius.

A
Assign Reader directly to the contractor's user account at the subscription scope.
Why wrong: Assigning Reader directly to the contractor's user account at the subscription scope bypasses group-based management and exposes all resource groups in the subscription, including those unrelated to the contractor's role. Direct user assignments create administrative overhead during personnel changes, as each user must be manually updated or removed instead of simply adding or removing them from a central Entra ID group. The correct assignment should target the contractor group at the resource group scope to achieve least privilege and simplify access reviews.
B
Assign Reader to the Entra ID contractor group at the resource group scope.
This is the best practice because Azure RBAC supports group-based assignments, and scope should be as narrow as possible. Assigning Reader to the contractor group at the resource group gives the team exactly the access needed and ensures removal from the group immediately revokes access through group membership changes. It is easier to audit and manage than assigning permissions to individual contractor accounts.
C
Assign Contributor to the contractor group at the resource group scope.
Why wrong: The Contributor role at the resource group scope grants full management rights to all resources in that resource group, including the ability to create, delete, and modify resources—directly contradicting the read-only requirement. Contributor also allows altering the configuration of existing resources, which could cause unintended outages or security changes, even though it cannot assign roles to others. Reader is the only built-in role that provides read-only access, and it must be assigned at the appropriate scope.
D
Assign Reader to the contractor group at the management group scope.
Why wrong: Assigning Reader to the contractor group at the management group scope places the role assignment on the root container, causing the role to be inherited by every subscription and resource group beneath it. This violates least privilege because the contractor would gain read access to unrelated resources across the entire management hierarchy, not just the single resource group. While group-based assignment is the correct approach, the scope must be narrowed to the specific resource group to limit the blast radius.

Question 15mediummultiple choice

Based on the exhibit, where should the Reader role be assigned so the audit team automatically has access to every current and future subscription under Corp?

Exhibit

Azure governance hierarchy
Root management group
└── Corp
    ├── Prod
    │   ├── Sub-001
    │   └── Sub-002
    └── NonProd
        ├── Sub-101
        └── Sub-102
Requirement: The audit team needs read-only access across all subscriptions that are or will be placed under Corp, without creating separate assignments for each subscription.

Trap 1: Assign Reader at the subscription scope for Sub-001.

Assigning Reader at the subscription scope for Sub-001 only grants access to that single subscription and has no effect on other subscriptions that may exist under the Corp management group. Each additional subscription would require a separate Reader assignment, and any subscription added to Corp in the future would also need its own assignment, defeating the purpose of centralized management. This option fails to meet the requirement for automatic, ubiquitous read access across the entire hierarchy, which the management group assignment provides.

Trap 2: Assign Reader at the resource group scope in each subscription.

Assigning Reader at the resource group scope in each subscription is insufficient because a resource group is a lower-level scope than a subscription, so the assignment applies only to resources within that specific resource group, not to resources in other resource groups. To cover the whole environment, you would need to create a separate assignment for every resource group in every subscription, and any new resource group created later would be missed. This approach is operationally inefficient and does not leverage Azure's built-in inheritance; the management group scope is the correct target.

Trap 3: Assign Reader directly to each resource that the audit team might…

Assigning Reader directly to each resource the audit team might review is impractical and heavily error-prone, as it would require enumerating every existing resource and manually assigning the role to each one. New resources created after the assignment would not automatically inherit the role, so the audit team would lose visibility over time without constant updates. This approach also contradicts Azure RBAC's design, where inheritance flows from resource group to resource, and it ignores the need for a single, maintainable control point; a management group assignment is the only option that scales.

A
Assign Reader at the Corp management group scope.
Assigning the Reader role at the Corp management group scope is correct because Azure RBAC role assignments are inherited by all child scopes: subscriptions, resource groups, and resources that reside under that management group. Since Corp presumably contains all current and future subscriptions, a single assignment guarantees the audit team has read-only visibility across the entire hierarchy without needing further assignments. This aligns with the recommended practice of assigning roles at the highest applicable scope to minimize administrative overhead and ensure consistent access.
B
Assign Reader at the subscription scope for Sub-001.
Why wrong: Assigning Reader at the subscription scope for Sub-001 only grants access to that single subscription and has no effect on other subscriptions that may exist under the Corp management group. Each additional subscription would require a separate Reader assignment, and any subscription added to Corp in the future would also need its own assignment, defeating the purpose of centralized management. This option fails to meet the requirement for automatic, ubiquitous read access across the entire hierarchy, which the management group assignment provides.
C
Assign Reader at the resource group scope in each subscription.
Why wrong: Assigning Reader at the resource group scope in each subscription is insufficient because a resource group is a lower-level scope than a subscription, so the assignment applies only to resources within that specific resource group, not to resources in other resource groups. To cover the whole environment, you would need to create a separate assignment for every resource group in every subscription, and any new resource group created later would be missed. This approach is operationally inefficient and does not leverage Azure's built-in inheritance; the management group scope is the correct target.
D
Assign Reader directly to each resource that the audit team might review.
Why wrong: Assigning Reader directly to each resource the audit team might review is impractical and heavily error-prone, as it would require enumerating every existing resource and manually assigning the role to each one. New resources created after the assignment would not automatically inherit the role, so the audit team would lose visibility over time without constant updates. This approach also contradicts Azure RBAC's design, where inheritance flows from resource group to resource, and it ignores the need for a single, maintainable control point; a management group assignment is the only option that scales.

Question 16mediummultiple choice

An administrator added a user to an Entra security group that already has Contributor on a resource group. The role assignment is correct, but the user still gets 'You do not have access' in the Azure portal 5 minutes later. What is the most likely next step?

Trap 1: Change the role assignment from the group to the subscription.

Changing the role assignment from the group to the subscription does not update the user's existing access token, so the immediate symptom—stale group claims—would remain until the token expires. Additionally, this change may inadvertently grant broader access across the entire subscription, violating least-privilege principles and introducing unnecessary security risk. The user would still need to sign out and sign back in for any new assignment to take effect, making this an indirect and potentially harmful workaround rather than a fix.

Trap 2: Delete and recreate the resource group.

Deleting and recreating the resource group is destructive and does not affect the user's access token or its claims. The token is issued by Entra ID and is completely independent of the resource group's lifecycle, so the stale group claim would persist even after recreation. Furthermore, recreating a resource group removes all contained resources and role assignments, causing significant downtime and requiring full reconfiguration—none of which resolves the identity/token refresh problem.

Trap 3: Assign Owner directly to the user.

Directly assigning the Owner role to the user overprivileges them and bypasses the group-based access model entirely. The user would retain permanent Owner rights even after being removed from the security group, creating long-term security and compliance issues. Also, the current access token would not reflect this new direct assignment until refreshed, so it fails to solve the immediate problem; a token refresh is the appropriate low-impact action, not granting excessive elevated privileges.

A
Change the role assignment from the group to the subscription.
Why wrong: Changing the role assignment from the group to the subscription does not update the user's existing access token, so the immediate symptom—stale group claims—would remain until the token expires. Additionally, this change may inadvertently grant broader access across the entire subscription, violating least-privilege principles and introducing unnecessary security risk. The user would still need to sign out and sign back in for any new assignment to take effect, making this an indirect and potentially harmful workaround rather than a fix.
B
Have the user sign out and sign back in to refresh the access token.
When a user is added to a group that holds a role assignment, the existing access token does not include the new group claim. Entra ID tokens are cached for their lifetime (typically 60-90 minutes), and during that window the Azure portal cannot see the updated membership. Signing out clears the cached token and session state; signing back in forces a fresh token issuance that includes the updated group claims, so RBAC evaluation recognizes the user's new permissions immediately. This is the direct, least-privilege fix.
C
Delete and recreate the resource group.
Why wrong: Deleting and recreating the resource group is destructive and does not affect the user's access token or its claims. The token is issued by Entra ID and is completely independent of the resource group's lifecycle, so the stale group claim would persist even after recreation. Furthermore, recreating a resource group removes all contained resources and role assignments, causing significant downtime and requiring full reconfiguration—none of which resolves the identity/token refresh problem.
D
Assign Owner directly to the user.
Why wrong: Directly assigning the Owner role to the user overprivileges them and bypasses the group-based access model entirely. The user would retain permanent Owner rights even after being removed from the security group, creating long-term security and compliance issues. Also, the current access token would not reflect this new direct assignment until refreshed, so it fails to solve the immediate problem; a token refresh is the appropriate low-impact action, not granting excessive elevated privileges.

Question 17mediummultiple choice

You need to ensure that a finance analyst can view all resources in the Finance-Sub subscription and also view spending details, but cannot create, modify, or delete any resources. Which built-in Azure RBAC role should you assign?

Trap 1: Owner

The Owner role provides full management permissions, including all of Contributor's abilities plus the capacity to assign roles in Azure RBAC and manage role assignments, effectively granting complete control over resources and access. This would allow the finance analyst to modify or delete resources and change permissions, which is a security risk. It is overly permissive for a view-only requirement, violating the principle of least privilege.

Trap 2: Contributor

Contributor has the ability to create, modify, and delete resources, but unlike Owner, it cannot grant access to others because it cannot manage role assignments. While it provides full management access to resources, it still allows the analyst to make destructive changes like deleting a virtual machine or altering configurations. This is not suitable for a view-only role as it exceeds the required read-only access.

Trap 3: Virtual Machine Contributor

The Virtual Machine Contributor role is scoped specifically to virtual machines and their supporting resources, allowing the creation, management, and deletion of virtual machines but not other resource types like storage or networking. It is a write and management role, not a general read-only view-all role, and it would fail to cover all resources the analyst needs to see. Even if it were read-only, it is narrowly scoped and would not satisfy the requirement to view all resources.

A
Owner
Why wrong: The Owner role provides full management permissions, including all of Contributor's abilities plus the capacity to assign roles in Azure RBAC and manage role assignments, effectively granting complete control over resources and access. This would allow the finance analyst to modify or delete resources and change permissions, which is a security risk. It is overly permissive for a view-only requirement, violating the principle of least privilege.
B
Contributor
Why wrong: Contributor has the ability to create, modify, and delete resources, but unlike Owner, it cannot grant access to others because it cannot manage role assignments. While it provides full management access to resources, it still allows the analyst to make destructive changes like deleting a virtual machine or altering configurations. This is not suitable for a view-only role as it exceeds the required read-only access.
C
Reader
The Reader role is a built-in Azure RBAC role that grants read-only access to all resources and resource groups, allowing the analyst to view everything they are assigned to without the ability to make any changes. It includes permissions like listing secrets but cannot read secret values for certain services like Key Vault (in older models). This role is ideal for auditing and visibility purposes, ensuring the finance analyst can monitor resources but not alter configurations.
D
Virtual Machine Contributor
Why wrong: The Virtual Machine Contributor role is scoped specifically to virtual machines and their supporting resources, allowing the creation, management, and deletion of virtual machines but not other resource types like storage or networking. It is a write and management role, not a general read-only view-all role, and it would fail to cover all resources the analyst needs to see. Even if it were read-only, it is narrowly scoped and would not satisfy the requirement to view all resources.

Question 18easymultiple choice

A developer already has permission to create resource groups. The company wants to allow deployments only in the East US and West US regions. Which service should enforce this rule?

Trap 1: Azure RBAC, because region selection is part of user permissions.

Azure RBAC grants permissions through role definitions that list management actions, but it has no concept of allowable deployment regions. Even a user with the Contributor role can create resources in any location unless an Azure Policy with a deny effect (such as 'Allowed locations') explicitly rejects the request. RBAC only authorizes an identity to perform an action; it does not evaluate or enforce attributes like the region of a resource during deployment. Thus, RBAC is about access control, not compliance enforcement for geographic restrictions.

Trap 2: A network security group, because it can block unsupported regions.

A network security group (NSG) is a stateful packet-filtering firewall that governs traffic to and from subnets or network interfaces using rules based on source/destination IP, port, and protocol. NSGs operate at the network layer after a resource has been deployed and are completely unaware of Azure Resource Manager provisioning requests or the physical Azure region in which a resource is placed. They cannot intercept deployment-time decisions or block a resource from being created in an unsupported region. Therefore, NSGs are entirely the wrong tool for enforcing location restrictions.

Trap 3: A read-only lock, because it limits changes to approved regions.

Azure resource locks are management-layer safeguards that prevent accidental deletion or modification by denying all change operations within the locked scope. A read-only lock (CanNotDelete) blocks any management action that would alter a resource, but it does not analyze the region of a new deployment request. In fact, applying a read-only lock to a resource group prevents any new resource from being deployed because deployment requires write permissions on the group, which the lock denies. This makes the lock not only ineffective for region compliance but also disruptive to normal operations.

A
Azure RBAC, because region selection is part of user permissions.
Why wrong: Azure RBAC grants permissions through role definitions that list management actions, but it has no concept of allowable deployment regions. Even a user with the Contributor role can create resources in any location unless an Azure Policy with a deny effect (such as 'Allowed locations') explicitly rejects the request. RBAC only authorizes an identity to perform an action; it does not evaluate or enforce attributes like the region of a resource during deployment. Thus, RBAC is about access control, not compliance enforcement for geographic restrictions.
B
Azure Policy, because it can restrict which regions are allowed for deployments.
This is correct because Azure Policy can enforce a list of allowed locations at deployment time. The developer may still have RBAC permission to create resources, but the policy can deny deployments outside East US and West US. That makes Policy the proper control for region compliance, while RBAC handles access rights separately.
C
A network security group, because it can block unsupported regions.
Why wrong: A network security group (NSG) is a stateful packet-filtering firewall that governs traffic to and from subnets or network interfaces using rules based on source/destination IP, port, and protocol. NSGs operate at the network layer after a resource has been deployed and are completely unaware of Azure Resource Manager provisioning requests or the physical Azure region in which a resource is placed. They cannot intercept deployment-time decisions or block a resource from being created in an unsupported region. Therefore, NSGs are entirely the wrong tool for enforcing location restrictions.
D
A read-only lock, because it limits changes to approved regions.
Why wrong: Azure resource locks are management-layer safeguards that prevent accidental deletion or modification by denying all change operations within the locked scope. A read-only lock (CanNotDelete) blocks any management action that would alter a resource, but it does not analyze the region of a new deployment request. In fact, applying a read-only lock to a resource group prevents any new resource from being deployed because deployment requires write permissions on the group, which the lock denies. This makes the lock not only ineffective for region compliance but also disruptive to normal operations.

Question 19mediummultiple choice

A company wants development and production workloads for the same application to have separate budgets, separate subscription administrators, and different access controls. The central IT team still wants to apply the same security policies to both environments. What is the best design?

Trap 1: Use one subscription and separate the environments with tags only

Tags are key-value metadata used for cost allocation, inventory, and automation, but they are not an enforcement boundary: Azure RBAC does not evaluate tag values when determining whether a user can manage a resource. With a single subscription, dev and prod share the same billing account, subscription quota, and subscription-level role assignments, so a user with Contributor rights could modify resources regardless of their tag. Even if Azure Policy forces tagging, it does not provide independent budgets, administrators, or fault isolation, so tags alone cannot satisfy the isolation requirement.

Trap 2: Use one management group and two resource groups, one for dev and…

Resource groups are logical containers within a single subscription, so dev and prod would still share the same subscription-level billing account, quota, and any subscription-scoped role assignments such as Owners. Azure Policy inherited from the management group can enforce tagging or location, but it cannot separate budgets, isolate service quotas, or prevent subscription administrators from accessing both resource groups. A resource group is a management boundary, not a billing or security boundary, so this design fails to meet the requirement for independent dev and prod environments.

Trap 3: Put production in a management group and development in a resource…

A management group and a resource group are at different levels of the Azure hierarchy: management groups may contain subscriptions, and subscriptions contain resource groups. Placing production in a management group and development in a resource group means they are not peer environments, so policies, budgets, and RBAC would have to be configured at structurally different scopes, making governance inconsistent and potentially leaving development without a proper management-group context. This violates the hierarchical model and does not create separate billing or administrative boundaries for the two workloads.

A
Use one subscription and separate the environments with tags only
Why wrong: Tags are key-value metadata used for cost allocation, inventory, and automation, but they are not an enforcement boundary: Azure RBAC does not evaluate tag values when determining whether a user can manage a resource. With a single subscription, dev and prod share the same billing account, subscription quota, and subscription-level role assignments, so a user with Contributor rights could modify resources regardless of their tag. Even if Azure Policy forces tagging, it does not provide independent budgets, administrators, or fault isolation, so tags alone cannot satisfy the isolation requirement.
B
Use one management group and two resource groups, one for dev and one for prod
Why wrong: Resource groups are logical containers within a single subscription, so dev and prod would still share the same subscription-level billing account, quota, and any subscription-scoped role assignments such as Owners. Azure Policy inherited from the management group can enforce tagging or location, but it cannot separate budgets, isolate service quotas, or prevent subscription administrators from accessing both resource groups. A resource group is a management boundary, not a billing or security boundary, so this design fails to meet the requirement for independent dev and prod environments.
C
Create a separate subscription for dev and prod, then place both subscriptions under the same management group
Separate subscriptions create independent billing scopes, quota limits, and RBAC administration boundaries, so production and development can each have their own Owner, budget, and outage isolation. Placing both subscriptions under the same management group lets you inherit Azure Policy, Azure RBAC, and tag governance centrally, ensuring consistent compliance and tagging without merging the dev and prod administrative or cost boundaries. This reflects the Azure best practice of using subscriptions as isolation boundaries and management groups as policy and governance containers.
D
Put production in a management group and development in a resource group
Why wrong: A management group and a resource group are at different levels of the Azure hierarchy: management groups may contain subscriptions, and subscriptions contain resource groups. Placing production in a management group and development in a resource group means they are not peer environments, so policies, budgets, and RBAC would have to be configured at structurally different scopes, making governance inconsistent and potentially leaving development without a proper management-group context. This violates the hierarchical model and does not create separate billing or administrative boundaries for the two workloads.

Question 20hardmulti select

A web app uses a managed identity to read blobs from a storage account. Security now wants to ensure no future requests can authenticate with shared keys and the app should continue to use secretless access. Which two changes should the administrator make? Select two.

Trap 1: Generate a service SAS and place it in an app setting.

A service SAS (Shared Access Signature) is constructed from the account key and grants delegated, time-limited access to specific storage resources. Storing it in an app setting means you have reintroduced a secret into the application configuration, undermining the entire purpose of using a managed identity; moreover, the SAS must be managed, monitored, and rotated before expiry. In addition, if shared key access is disabled, a service SAS becomes invalid because it depends on the account key, making this approach incompatible with the intended secure architecture.

Trap 2: Rotate the storage account keys weekly.

Rotating storage account keys on a weekly basis simply generates new shared secrets; it does not eliminate the use of shared-key authentication. As long as the application uses the account key, you still have to deploy the new key to the app settings and handle the rotation, which is both a security risk and an operational burden. Because the problem explicitly calls for a managed identity to read blobs, key rotation is orthogonal and does not contribute to a secretless solution — the correct approach is to remove key-based authentication entirely.

Trap 3: Grant Reader access to the resource group because it includes the…

The built-in Reader role is a management-plane (or control-plane) RBAC role that only permits 'read' on ARM resources, such as listing storage accounts and viewing their properties. It does not include dataActions like 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read', which are required to read blob objects. Even if assigned at the resource group level, Reader inherits down to the storage account but still lacks any data-level permissions, so the application would get 403 errors when attempting to access the blobs.

A
Assign the Storage Blob Data Reader role to the managed identity on the storage account or container.
The Storage Blob Data Reader role is a data-plane RBAC role that specifically authorizes read operations against blob containers and blobs. Assigning it to a managed identity at the storage account or container scope grants access based on the identity's Entra ID token, eliminating any need for shared keys or connection strings. This is the fundamental mechanism for secretless, identity-based access, and it works with both system-assigned and user-assigned managed identities.
B
Disable shared key access on the storage account.
Disabling shared key access on the storage account removes the ability to authenticate with the account access keys, which are long-lived secrets often stored in configuration. When enabled, this setting forces every data-plane request to be authenticated through Microsoft Entra ID (or, if explicitly allowed, SAS tokens) — so the earlier role assignment to the managed identity becomes the effective path. Note that this action is a security hardening measure; it does not by itself grant any blob-read permission but ensures key-based authentication cannot be used as a fallback, thereby aligning with a zero-secret architecture.
C
Generate a service SAS and place it in an app setting.
Why wrong: A service SAS (Shared Access Signature) is constructed from the account key and grants delegated, time-limited access to specific storage resources. Storing it in an app setting means you have reintroduced a secret into the application configuration, undermining the entire purpose of using a managed identity; moreover, the SAS must be managed, monitored, and rotated before expiry. In addition, if shared key access is disabled, a service SAS becomes invalid because it depends on the account key, making this approach incompatible with the intended secure architecture.
D
Rotate the storage account keys weekly.
Why wrong: Rotating storage account keys on a weekly basis simply generates new shared secrets; it does not eliminate the use of shared-key authentication. As long as the application uses the account key, you still have to deploy the new key to the app settings and handle the rotation, which is both a security risk and an operational burden. Because the problem explicitly calls for a managed identity to read blobs, key rotation is orthogonal and does not contribute to a secretless solution — the correct approach is to remove key-based authentication entirely.
E
Grant Reader access to the resource group because it includes the storage account.
Why wrong: The built-in Reader role is a management-plane (or control-plane) RBAC role that only permits 'read' on ARM resources, such as listing storage accounts and viewing their properties. It does not include dataActions like 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read', which are required to read blob objects. Even if assigned at the resource group level, Reader inherits down to the storage account but still lacks any data-level permissions, so the application would get 403 errors when attempting to access the blobs.