Azure RBAC practice questions

Assign Storage Account Contributor at the resource group scope.

Why wrong: This grants management-plane control over the storage account and is much broader than needed.

Assign Reader and give the service principal a storage account access key.

Why wrong: This introduces stored credentials and does not follow the Entra-based least-privilege requirement.

Assign Contributor at the subscription scope and restrict access with naming conventions.

Why wrong: Naming conventions do not enforce security, and subscription scope is unnecessarily broad.

Microsoft.Compute/virtualMachines/delete gives the ability to remove the VM from the subscription.

Why wrong: Delete is far too permissive for a support-only role. It would allow destruction of the virtual machine, which is explicitly not required and would create unnecessary risk. This option is the opposite of least privilege for routine operations.

Microsoft.Network/networkInterfaces/write is needed because a VM start or restart always requires NIC modification rights.

Why wrong: Starting or restarting a VM does not require permission to change the network interface. Granting NIC write access would broaden the role into network administration, which the requirement explicitly excludes. That would be excessive and unrelated to the task.

Microsoft.Authorization/roleAssignments/write would let the engineer grant access to other users and manage permissions.

Why wrong: Role assignment write permissions are administrative access-control rights, not VM operations. Including them would let the engineer modify authorization for many resources, which is not needed and would violate the requirement to avoid granting access-management capabilities.

The entire subscription that contains vm-app01.

Why wrong: That scope would grant access to every resource in the subscription, which is broader than required.

The resource group that contains vm-app01.

Why wrong: This would allow management of every VM in the resource group, not just one machine.

The management group that contains the subscription.

Why wrong: This is the broadest option and would affect many subscriptions and resources.

Create a custom RBAC role that blocks resources deployed outside approved regions.

Why wrong: RBAC authorizes actions, but it cannot conditionally deny based on a resource property such as region.

Add a CanNotDelete lock to every resource group.

Why wrong: Locks prevent deletion or writes, but they do not validate required tags or allowed locations.

Grant User Access Administrator to the deployment team.

Why wrong: This only changes authorization capabilities and does not enforce deployment compliance rules.

Change the role assignment from the group to the subscription.

Why wrong: The assignment already exists at the right scope, so changing scope is not the immediate fix.

Delete and recreate the resource group.

Why wrong: Resource recreation does not resolve identity claims or token caching problems.

Assign Owner directly to the user.

Why wrong: That overprivileges the user and does not address the token refresh issue.

Assign the Reader role directly to every subscription under Corp.

Why wrong: This would work only after every subscription is configured individually. It also creates extra administrative work and does not automatically cover new subscriptions added later.

Assign the Reader role to the Auditors group at one resource group scope.

Why wrong: A resource group assignment is too narrow. It would not grant visibility across all subscriptions under the management group, only that single resource group.

Create an Azure Policy assignment to grant read access to all subscriptions.

Why wrong: Azure Policy evaluates compliance and controls configuration behavior, but it does not grant Azure RBAC permissions or provide read access.

Owner

Why wrong: Owner grants full management permissions and the ability to assign roles.

Contributor

Why wrong: Contributor allows creation, modification, and deletion of resources.

Virtual Machine Contributor

Why wrong: Virtual Machine Contributor is scoped to VM management and is not the appropriate general read-only role.

Each contractor user account individually

Why wrong: This gives access directly to each person, so changes to staff require manual role updates.

A device group

Why wrong: Device groups are for device targeting, not for assigning Azure access to people.

An Azure subscription

Why wrong: A subscription is a scope, not an identity, so it cannot be used as the assignee.

Remove the policy assignment from the management group until the migration is finished.

Why wrong: Removing the assignment weakens governance for every subscription under the management group, not just the one legacy resource.

Apply a CanNotDelete lock to the storage account.

Why wrong: A resource lock helps prevent deletion, but it does not override a policy denial for public network access settings.

Assign a Contributor role to the migration team on the storage account.

Why wrong: RBAC permissions do not bypass policy evaluation, so additional access rights will not permit a denied configuration.

Assign the Azure role directly to each contractor user account.

Why wrong: Direct user assignments work, but every membership change requires another role change. That creates more administrative effort and a higher risk of missed access removal.

Use a Microsoft 365 group and assign the Azure role to it.

Why wrong: Microsoft 365 groups are mainly for collaboration scenarios. They are not the preferred choice for Azure access delegation when a security group is the clearer, more appropriate administrative construct.

Create a management group for the contractors and assign the role there.

Why wrong: Management groups are used to organize subscriptions and apply governance at scale. They are not meant to represent a temporary project team or manage individual contractor membership.

A subscription dedicated to the application.

Why wrong: A subscription can isolate a workload, but it is usually too large and expensive to use as the primary container for one application.

A management group.

Why wrong: Management groups are intended for organizing subscriptions and applying governance at a higher level, not for grouping the individual resources of one application.

A tag value that names the application.

Why wrong: Tags help classify resources, but they do not create a management boundary or allow lifecycle operations on the whole application as one unit.

Assign the service desk the Contributor role on the application resource group.

Why wrong: Contributor grants Azure resource permissions, which violates the requirement to avoid subscription or resource access.

Assign the service desk the User Administrator directory role to manage the application users.

Why wrong: User Administrator is broader than necessary and grants powerful tenant-wide directory capabilities.

Create individual user assignments for every employee instead of using group-based access.

Why wrong: Direct assignments do not delegate membership management and become difficult to maintain over time.

Only the Reader role from the subscription scope is inherited by the storage account.

Why wrong: This ignores the more specific Contributor assignment at the resource group scope.

Neither role is inherited because storage accounts require a direct assignment.

Why wrong: Azure RBAC supports inheritance from subscription and resource group scopes.

Both roles are merged into a new custom role automatically.

Why wrong: Azure does not combine role assignments into a new role definition.

Assign Reader separately at each subscription scope.

Why wrong: Separate subscription assignments would work technically, but they do not meet the requirement to avoid one assignment per subscription.

Assign Reader at one resource group in each subscription.

Why wrong: A resource group assignment is too narrow and would not cover the whole subscription. It also creates many more assignments than requested.

Create a lock on each subscription to provide Reader access.

Why wrong: Resource locks protect resources from changes; they do not grant read permissions. They are unrelated to RBAC access delegation.

Apply all governance controls individually to each new subscription after it is created.

Why wrong: This is operationally expensive and risks inconsistent configuration as subscriptions grow.

Use a resource lock on the subscription root.

Why wrong: Locks are not designed for hierarchical organization or for enforcing a reusable governance baseline.

Place all resources into one shared resource group per business unit.

Why wrong: Resource groups are too narrow for subscription-level governance and do not solve subscription inheritance.

Assign Reader at the RG-Finance resource group scope.

Why wrong: This only grants access to one resource group and does not cover other subscriptions under Corp.

Assign Reader separately at each subscription scope.

Why wrong: This works for current subscriptions but requires extra assignments whenever a new subscription appears.

Assign Reader only at the individual resource scope.

Why wrong: This would be far too narrow and would not provide access to the rest of the environment.

Store the storage account key in the app configuration and use it from the application

Why wrong: Account keys work, but they create secret management overhead and are not credential-free.

Create an anonymous public container so the app can upload without authentication

Why wrong: Anonymous access is insecure and does not provide the required controlled upload authentication.

Use a shared access signature generated from the storage account root key

Why wrong: A SAS is temporary, but generating it from an account key still depends on a stored secret.

Store the storage account key in an environment variable on the VM

Why wrong: This still exposes a long-lived secret on the VM and gives access far broader than the single container.

Create a service SAS with write permission on the storage account

Why wrong: A SAS is still a shared secret, and using the account scope is broader than the single container requirement.

Assign Contributor on the storage account to the VM's system-assigned identity

Why wrong: Contributor is an Azure Resource Manager role, not a data-plane blob access role, so it does not grant the needed container upload permissions.

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

Why wrong: A SAS in app settings reintroduces a secret and undermines the goal of a secretless design.

Rotate the storage account keys weekly.

Why wrong: Rotating keys does not eliminate key-based authentication and still leaves secrets in active use.

Grant Reader access to the resource group because it includes the storage account.

Why wrong: Reader is a management-plane role and does not grant blob data access for reading objects.