Manage Azure Identities and Governance practice questions

Global Administrator

Why wrong: Global Administrator has full access to every administrative feature in Microsoft Entra ID, including user management, security, billing, and all directory-wide settings. Assigning this role to a help desk team violates the principle of least privilege because it exposes the entire tenant to unnecessary risk and a compromised help desk account could cause catastrophic damage. While it can reset passwords for any user, including other admins, that capability far exceeds the requirement for routine password resets, making it an incorrect choice.

Reader

Why wrong: The Reader role is a read-only role that can view directory resources but cannot perform any write operations, including password resets. In Microsoft Entra ID, a Reader can inspect user profiles and attributes but has no permission to modify credentials. Therefore, a help desk team assigned only the Reader role would be unable to execute password reset requests, rendering it too restrictive for the task described.

Billing Administrator

Why wrong: Billing Administrator is scoped exclusively to financial and billing activities, such as managing subscriptions, invoices, and payment methods. It has no permissions to manage user identities, alter directory objects, or reset passwords. Even though the name might suggest a broad administrative capability, it is entirely unrelated to user management, so it would not meet the help desk team's password reset requirement.

Create a Conditional Access policy that targets Helpdesk and Europe-Users.

Why wrong: Conditional Access policies evaluate sign-in risk, device compliance, location, and application access, and they are not a mechanism for granting delegated administration rights. A policy targeting the Helpdesk group and Europe-Users would only govern authentication conditions for those subjects; it cannot assign the User Administrator permission or delegate user management within an administrative unit. In short, Conditional Access controls who can sign in and under what conditions, not who can administer which directory objects.

Assign the Password Administrator role at the tenant scope and use Privileged Identity Management.

Why wrong: Privileged Identity Management (PIM) adds time-bound activation, approval, and auditability, but it does not change the scope of the role assignment. Even when activated just-in-time, a tenant-scoped Password Administrator can reset passwords for any user across the entire directory, not just Europe-Users. To correctly limit scope, the assignment itself must be scoped to the administrative unit; PIM cannot provide that restriction.

Create a custom RBAC role in the subscription and assign it to Helpdesk.

Why wrong: Custom Azure RBAC roles are defined within a subscription and apply only to Azure resource management actions such as VMs, storage, and subscriptions via ARM. They do not extend to Microsoft Entra ID directory objects, and assigning such a role to Helpdesk at the subscription scope has no effect on their ability to manage users in an administrative unit. This option conflates Azure RBAC with Microsoft Entra administrative roles, which are entirely separate permission planes.

ReadOnly

Why wrong: A ReadOnly lock would also prevent administrators from modifying resources.

Delete lock

Why wrong: Delete lock is not the Azure lock name used in the platform.

No lock and a budget alert

Why wrong: A budget alert does not prevent accidental deletion.

Owner at the RG-Dev scope

Why wrong: Owner at the RG-Dev scope is too broad because, in addition to managing all resources in the resource group, it grants the ability to manage role assignments (Microsoft.Authorization/*). This means the junior administrator could grant themselves or others additional rights, escalate privileges, or inadvertently change access policies for the entire resource group. Even at resource-group scope, Owner implies full control over access management and all resource types, which is far beyond the requirement of merely managing virtual machines.

Reader at the subscription scope

Why wrong: Reader at the subscription scope is insufficient because it only permits viewing resource configurations and metadata, with no write actions such as Microsoft.Compute/virtualMachines/write or start. A junior administrator with Reader cannot stop, start, resize, or perform any operational task on a VM; they can only observe the current state. While the subscription scope is broad, the lack of any management permissions makes this assignment completely ineffective for the stated goal of managing VMs.

Contributor at the subscription scope

Why wrong: Contributor at the subscription scope gives the junior administrator full management rights over every resource and resource group in the entire subscription, excluding only access management. This includes the ability to create, modify, and delete virtual networks, storage accounts, and any other service, which is substantially more permissive than needed. Assigning Contributor at the subscription scope violates least privilege and increases the risk of accidental or intentional changes to production workloads outside RG-Dev.

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.

Assign Storage Account Contributor at the resource group scope.

Why wrong: Storage Account Contributor is a control-plane role that allows managing the storage account's configuration, such as networking, redundancy, and access tier, but it includes no dataActions for reading or writing blob content—therefore, it does not satisfy the upload/read requirement. Assigning this role at the resource group scope expands the permission to every storage account in that group, not just the target account, and still leaves the service principal unable to access blob data. This option is both insufficient (no data access) and overly broad (resource-group-level management), making it a poor fit for a narrowly scoped automation task.

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

Why wrong: The Reader role provides read-only access to the storage account's management plane (e.g., account keys, properties), but it does not grant any data plane permissions, so the service principal could not upload or read blobs without an additional credential. Giving the storage account access key as a workaround introduces a static, shared secret that grants full data access to all blobs, tables, queues, and file shares in the account, completely bypassing RBAC and making it impossible to scope permissions to a single container. This solution also conflicts with a least-privilege, Entra-based security model because access keys are non-auditable, long-lived, and must be stored and rotated.

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

Why wrong: Assigning Contributor at the subscription scope is excessively broad—it grants management-plane control over every resource in the subscription, including virtual machines, networks, and the storage account's configuration, but notably does not grant direct access to blob data via RBAC. Naming conventions are not an actual security boundary; they only impose a policy for naming resources and can be bypassed, so they do nothing to restrict the service principal's effective permissions. This approach violates the principle of least privilege and unnecessarily exposes the entire subscription to modification if the service principal is compromised.

Reading the resource group's activity log will fail because lock-protected scopes cannot be queried.

Why wrong: The Azure activity log is a control-plane audit trail, and reading it is a query against resource metadata rather than a write to the resource itself. A ReadOnly lock only blocks create, update, and delete operations on the locked scope and its child resources, so any GET- or list-based read—including subscription-level or resource-group-level activity log queries—still succeeds. Lock-protected scopes can be queried; the lock does not impose an access control restriction that prevents observation, so this option incorrectly equates write protection with read denial.

Listing the resources in the resource group with Azure CLI will fail because enumeration is a write operation.

Why wrong: Listing resources is a read-only management operation and is not blocked by a ReadOnly lock. The lock prevents create, update, and delete actions, but it does not stop inventory or discovery commands. That makes this option incorrect.

Fetching the current VM configuration from the ARM API will fail because reads are denied by the lock.

Why wrong: Fetching the current VM configuration from the ARM API is a GET request that returns the resource's existing properties; it performs no mutation of state. A ReadOnly lock rejects state-changing calls like PUT, PATCH, or DELETE, but explicitly allows read operations, so the GET succeeds without error. The statement that reads are denied reverses the actual semantics of the lock—ReadOnly means you can read but not write, not that reads are blocked.

Check for a CanNotDelete lock on the resource group because that lock blocks all deployments.

Why wrong: The CanNotDelete lock, also called ReadOnly lock, prevents deletion or Write operations on existing resources, but it does not block the creation of new resources in the resource group. A deployment that adds a new resource (e.g., a public IP or VM) is generally allowed even when the resource group has a CanNotDelete lock. The lock would only interfere if the deployment tried to modify or delete an existing resource. Thus, checking for a CanNotDelete lock is not the correct step when the error message is about authorization, because locks are not an RBAC denial and do not prevent initial resource creation.

Confirm that the VM size is available in the region because size availability is the most common authorization issue.

Why wrong: VM size availability is a quota/capacity issue, not an authorization issue. When a SKU is unavailable in a region, Azure returns an error about insufficient capacity or quota, such as 'SkuNotAvailable', which is distinct from an authorization failure. Checking the available VM sizes would not address a permissions or policy denial, and it would not resolve an AuthorizationFailed error. The question asks about an authorization problem, so conflating size availability with RBAC or policy is a common but incorrect troubleshooting path.

Inspect whether tags are inherited from the subscription because tag inheritance can deny a deployment request.

Why wrong: Tag inheritance is a policy effect that copies tags from a resource group or subscription to resources after creation, but it does not itself deny a deployment. A deny policy could enforce that certain tags exist, but tag inheritance is a modify effect, not a deny effect, and it does not block the initial operation. Inspecting inherited tags would only be relevant if a policy explicitly denies resources lacking a specific tag—and even then, the root cause is the policy, not the inheritance mechanism. Therefore, checking tag inheritance is not a meaningful step when investigating an authorization error, since tags alone lack the ability to block deployment.

Place all production workloads into one shared resource group so governance and reporting are simpler.

Why wrong: A single shared resource group is a poor design for a multi-application environment. It creates large administrative boundaries, complicates lifecycle management, and makes deployments riskier. It does not provide a scalable governance or reporting model for separate applications.

Use management groups instead of tags because tags are not useful for cost reporting.

Why wrong: This answer presents a false dichotomy: management groups and tags solve different problems. Management groups provide hierarchical RBAC and policy inheritance across subscriptions, but they cannot carry resource-level metadata such as owner or application. Tags are the native Azure mechanism for cost allocation, enabling per-resource chargeback in Azure Cost Management and custom reports. Replacing tags with management groups would eliminate the ability to tag individual resources with cost center, project, or environment, making accurate app-level cost reporting impossible; both should be used together.

Assign the baseline only at one subscription and copy the settings manually to every new subscription.

Why wrong: Manual copying creates drift and operational overhead, especially as subscriptions are added over time. The requirement calls for automatic inheritance, so this approach does not satisfy the need for a repeatable production baseline across current and future subscriptions.

Store the storage account access key in a script variable.

Why wrong: Placing the storage account access key inside a script variable does not remove the secret from the automation content; it simply hides it behind a variable name, and the plaintext key remains visible to anyone with read access to the script or to process environment dumps. Access keys also grant full account-level access and are difficult to rotate without breaking the script, so this violates the requirement to keep secrets out of scripts/templates and increases blast radius if the script is leaked.

Create a separate local administrator account for the script to use.

Why wrong: A separate local administrator account is a machine-level credential, not an Azure AD identity, so it cannot authenticate to Azure Blob Storage or use RBAC permissions. The script would still need to store the password somewhere, and managing a local account on every VM adds operational overhead while providing no defense against secret leakage. This does not meet the requirement for a reusable, secure Azure authentication mechanism across the three VMs.

Embed a SAS token directly in the Bicep parameters file.

Why wrong: A SAS token is still a secret, and placing it in a parameters file exposes it to anyone who can read the deployment artifact. That conflicts with the requirement to avoid secrets in templates and scripts.

ReadOnly lock on the resource group.

Why wrong: A ReadOnly lock blocks both delete and all create/update operations at the resource group scope. For a workload VM, this means you cannot start, stop, restart, or apply OS updates, effectively freezing the VM and interfering with routine maintenance and patching. While it would technically prevent deletion, the lock is too broad for a critical VM that must remain operationally manageable; CanNotDelete is the more precise protection.

A policy assignment that denies delete operations.

Why wrong: An Azure Policy assignment with a deny effect could theoretically block delete operations, but it requires authoring a custom policy definition and introduces governance complexity with possible exemptions and policy assignment scope. Policy evaluation occurs based on compliance rules, and the configuration may take time to propagate or be subject to overrides by exemptions, making it a less direct and immediate safeguard than a resource lock. In this scenario, the intended protection is a targeted, always-on denial on the specific resource group, which is exactly what a CanNotDelete lock provides.

A management group assignment with Contributor removed.

Why wrong: Removing the Contributor role at a management group or subscription level is a coarse-grained access control change that affects all resources under that scope, not just the one resource group. Even if Contributor is removed, other identities such as an Owner or User Access Administrator may still retain permissions to delete the resource group. The requirement is for a precise, unconditional block on deletion for this specific critical resource group, which only an Azure resource lock can grant; access control modification alone is not a tailored deletion safeguard.

Assign Reader at the subscription scope so the staff can view the VMs.

Why wrong: Reader at the subscription scope provides read-only visibility to every resource group and resource in the subscription, including RG-Dev, but it contains no action that can change VM state. The restart action is an authorization call to Microsoft.Compute/virtualMachines/restart/action, which Reader explicitly lacks. Moreover, subscription-level scope gives helpdesk staff a subscription-wide resource listing, violating least privilege and expanding the security surface.

Assign Contributor at the RG-Dev scope.

Why wrong: Contributor at the RG-Dev scope grants write/delete permissions across every resource type in that resource group, including virtual networks, network interfaces, and public IP addresses. It allows deletion of VMs, changing network configurations, and other destructive operations that are far broader than a simple restart task. This violates least privilege because it exposes much more than the Microsoft.Compute/virtualMachines/restart/action needed by helpdesk, even if scoped to one resource group.

Assign Virtual Machine Administrator Login at the RG-Dev scope.

Why wrong: Virtual Machine Administrator Login is a data-plane role that authorizes RDP or SSH sign-in to the guest operating system via Microsoft.Compute/virtualMachines/login/action. Restarting a VM in the Azure portal or via CLI/SDK is a control-plane operation, Microsoft.Compute/virtualMachines/restart/action, which this role does not include. Therefore helpdesk staff would be able to log into the OS but could not actually restart the machine from Azure control plane.

Apply a ReadOnly lock to the resource group.

Why wrong: A ReadOnly lock is an Azure lock that blocks any write operation, including create, update, and delete; it does not block reads. In a production resource group, operators need to perform actions such as scaling a VM scale set, applying OS patches, or reconfiguring endpoints, all of which are write operations. This lock would effectively make the resources inert, preventing routine administration and incident response, so it does not suit the operational requirement.

Move the resource group to a management group.

Why wrong: Management groups in Azure are logical containers that aggregate multiple subscriptions for organizing governance, policy, and compliance at scale; they exist above subscriptions and do not directly contain resource groups. Moving a resource group into a management group is not a supported operation—you can only move a subscription between management groups. Even if a resource group could be moved, it would not create a deletion lock or preserve tags; it would only inherit policies from the management group level.

Grant Resource Policy Contributor to the operators.

Why wrong: The Resource Policy Contributor role grants the ability to define, assign, and manage Azure Policy definitions and initiative assignments, but these policies are for enforcing governance rules across resources. It does not provide any deletion locks, nor does it add ownership tags to resources; policy set at the management group or subscription level can be used to enforce tagging, but the role alone does not preserve ownership data. The operators would still be able to delete the resource group, and no chargeback metadata would be attached.

Assign Reader to everyone in the company.

Why wrong: Assigning Reader to everyone in the company grants read-only access to all resources, but it does not restrict the delete permissions of other users, and it does absolutely nothing to organize the three subscriptions. Reader is a built-in role that only allows viewing of resource settings and monitoring data; it neither prevents delete actions (which would require a lock) nor creates any governance hierarchy. Moreover, giving Reader to every employee exposes potentially sensitive configuration and data to the entire company, violating least privilege; it is not a tool for organizing subscriptions or protecting production resources.

Use a distribution list for the subscriptions.

Why wrong: Distribution lists (or Exchange distribution groups) are purely email distribution mechanisms that deliver messages to multiple recipients; they are not Azure AD security principals capable of being assigned roles or permissions. As email objects, they have no ability to aggregate subscriptions for Azure governance, cannot inherit or apply policies, and offer no deletion protections for resources. Relying on a distribution list for subscription organization is effectively a no-op in Azure, since it has no effect on the Azure control plane.

Move the resource group into a different region.

Why wrong: Moving a resource group to a different Azure region changes only the location of the resource group's metadata, not the region of the resources inside, and it certainly provides no deletion protection. Resource groups are logical containers; their region does not denote where resources physically run, nor does it act as an access control boundary. Accidental deletion is prevented by Azure resource locks, not by geographic placement, so this action is both irrelevant to the goal and potentially disruptive to resource management.

Assign Reader separately on each subscription.

Why wrong: Per-subscription assignment would work initially, but it creates repetitive administration. The requirement explicitly asks for one role assignment to maintain, so this is not the best approach.

Assign Reader at the tenant root and remove the management group.

Why wrong: Tenant root is not the intended governance boundary for this scenario, and removing the management group defeats the goal of organizing subscriptions under Corp. The question requires a scoped, maintainable hierarchy.

Create a resource group for each subscription and assign Reader there.

Why wrong: Resource group assignments do not cover an entire subscription, and they do not solve the need for broad audit visibility across multiple subscriptions. This adds complexity without meeting the requirement.

Assign the role at the resource group scope.

Why wrong: A resource group scope is a container scope, not a resource-specific scope. Assigning the Reader role at the resource group level causes Azure RBAC to inherit that role to every resource within the group, including any VMs, virtual networks, databases, or other services that happen to reside there. This grants access far beyond the two named resources, violating the principle of least privilege. Even if the resource group currently contains only the storage account and Key Vault, future resources added to that group would automatically inherit the same reader permissions—an unintended security exposure.

Assign the role at the subscription scope.

Why wrong: Subscription scope in Azure RBAC applies the role assignment to the entire subscription, meaning the Reader role would be inherited by every resource group and every resource in every region within that subscription. This includes not just the intended storage account and Key Vault, but also any other subscription resources that the team has no business need to read. Subscription-level assignments are typically reserved for subscription-level governance activities or when granting broad read-only visibility to an entire environment, not for granting access to two discrete resources. The over-broad scope also complicates auditing and makes it harder to enforce least privilege across the subscription.

Assign the role at the management group scope.

Why wrong: A management group scope is the highest level in the Azure RBAC hierarchy and causes the role assignment to be inherited by every subscription underneath that management group, and consequently every resource group and resource in each of those subscriptions. This scope is often used for enterprise-wide governance or to enforce consistent access policies across multiple subscriptions, but it is entirely inappropriate for granting read access to exactly two resources. Because the assignment flows down to every child scope, the team would gain reader permissions across hundreds or thousands of resources, creating a massive security blast radius. The only way to restrict access to two specific resources is to scope assignments directly to those resource resources or to a custom resource group created solely for them.

A Microsoft 365 group

Why wrong: Microsoft 365 groups are designed for collaboration scenarios such as shared mailboxes, calendars, SharePoint sites, and Teams. Although it is technically possible to use them for role assignment, they bring unnecessary collaboration features and a separate lifecycle that can complicate access control. As a best practice, Azure RBAC roles should be assigned to security groups, not Microsoft 365 groups, to keep role management independent from collaboration workloads.

A guest user account

Why wrong: A guest user account is a single external identity in Microsoft Entra ID, so it cannot represent a changing set of contractors. Adding or removing a contractor would require creating or deleting individual guest accounts and then editing each RBAC role assignment separately. Guest users are also subject to invitation workflows and cross-tenant relationships, making them cumbersome for dynamic access management compared to a security group.

A managed identity

Why wrong: A managed identity is an Azure AD identity automatically managed by Azure and used by resources (like VMs or Function Apps) to authenticate to Azure services. It is a workload identity, not a human identity, and cannot contain members. Contractors cannot be added to a managed identity, and assigning roles to it would grant access to the underlying resource, not to people, so it fails to address the team's needs entirely.

At one resource group in each subscription

Why wrong: Applying Reader to one resource group per subscription only covers the resources inside that specific resource group. Resources in other resource groups within the same subscription, such as virtual networks or storage accounts, would be invisible to the audit group. This approach also forces you to create and maintain one assignment per subscription, rather than a single inheritance-based assignment, so it does not satisfy access to every subscription's resources.

At a single resource

Why wrong: A single-resource scope grants Reader only to that one resource, so the audit group could not see any other resources in the subscription. To meet the requirement, you would need to create an assignment for every individual resource across all subscriptions, which is impractical and incomplete. This scope is far too narrow for an enterprise-wide audit group.

At the tenant root only for one application

Why wrong: Assigning at the tenant root (the root management group) grants Reader to every subscription and resource in the entire Azure AD tenant, which exceeds the stated need and violates least privilege if the audit group should only see designated subscriptions. Moreover, the mention of 'one application' is semantically invalid because a tenant-root role assignment is not filtered to an application; it applies to all resources under the scope. Therefore, this option is both over-broad and conceptually flawed.

Apply a ReadOnly lock to rg-payroll-prod.

Why wrong: ReadOnly would block writes and many administrative changes, which conflicts with the need to keep updating and operating the resources.

Apply a tag named Protected=True to rg-payroll-prod.

Why wrong: Tags help with organization and reporting, but they do not enforce deletion protection or any access restriction.

Create an Azure Policy assignment that denies all delete operations.

Why wrong: Policy can enforce rules, but the requirement specifically calls for protecting a resource group from deletion, which is the lock use case.

Remove the policy and reassign it at the resource group scope

Why wrong: Removing and reassigning the policy at a narrower resource group scope does not retroactively evaluate resources that were deployed before the assignment; the append effect only runs when a resource is created or updated. Reassignment also changes the compliance scope but leaves existing VMs untouched, and it may even exclude resources outside that resource group. Without a remediation task, the missing tag will persist on all pre-existing virtual machines.

Grant the policy assignment Reader access

Why wrong: Granting Reader access to the policy assignment does not give the policy engine permission to modify existing VMs; Reader only allows viewing resource properties, and the append effect is not applied retroactively by RBAC. Remediation requires a task that uses a system-assigned managed identity with a contributor-style role to update tags. Thus, this action neither evaluates nor fixes the already-deployed virtual machines.

Apply a CanNotDelete lock to the subscription

Why wrong: A CanNotDelete lock on the subscription prevents deletion of resources but allows read and update operations, so it does not block tag editing nor does it force the missing Environment tag to be added. Policy evaluation is independent of locks; locks only protect against accidental destructive actions. Therefore, existing VMs remain non-compliant because the lock does not trigger any policy evaluation or remediation.