Manage Azure identities and governance

Scopes from broadest to narrowest: Tenant Root Group → Management Groups → Subscriptions → Resource Groups → Resources. A role assigned at a Management Group applies to all subscriptions, resource groups, and resources within it. Inheritance only flows downward — a role on a resource does not grant access to the resource group containing it.

• Owner — full read/write/delete on all resources, plus the ability to assign roles. The only standard role that grants role assignment.
• Contributor — full read/write/delete on all resources. Cannot assign roles or manage access permissions. The right answer when the requirement is "deploy VMs and manage virtual networks" (both are resource management operations).
• Reader — view resources only. No modifications.
• User Access Administrator — assign any role at any scope. Cannot manage resources themselves. The least-privilege answer when the requirement is specifically to assign roles to other users.
• Reader and Data Access — view storage account keys and list/read storage data. Least-privilege for viewing storage account data including blob contents.
• Network Contributor — create and manage network resources (VNets, NSGs, load balancers). Does not cover VMs or role assignment.
• Storage Account Key Operator Service Role — list and regenerate storage account access keys. The correct role when the requirement is specifically key management.
• Storage Account Contributor — manage storage accounts including listing and regenerating keys. Also covers key management.
• Resource Policy Contributor — create, edit, delete, and assign Azure Policy definitions and initiatives. The least-privilege role for managing the Azure Policy governance framework.

If Group1 (Security type) has the Owner role on RG1, and Group2 (Security type) is added as a member of Group1, then User2 (a member of Group2) inherits the Owner role on RG1. RBAC role inheritance flows through nested Security groups.

The ability to sign in to a virtual machine (RDP/SSH) is a data-plane operation: Microsoft.Compute/virtualMachines/login/action. It must be placed in the dataActions section of the role definition. Adding it to actions will not grant sign-in capability — actions governs only ARM management operations, not data-plane authentication.

• "/" — entire tenant; role can be assigned anywhere.
• "/subscriptions/{subId}" — any RG or resource within that subscription.
• "/subscriptions/{subId}/resourceGroups/" — only resource groups within that subscription. This is the correct value when the requirement says "can only be assigned to resource groups in Subscription1."
• "/subscriptions/{subId}/resourceGroups/{rgName}" — a single specific resource group.

• Adding or modifying subnets in a VNet — requires Owner, Contributor, or Network Contributor scoped at or above the VNet.
• Assigning a role to a VNet — requires Owner or User Access Administrator scoped at or above the VNet.
• Adding a backend pool or health probe to a load balancer — Network Contributor scoped to that specific load balancer is the least-privilege answer. Scoping to the resource (not the RG) is more restrictive and more appropriate.
• Security Admin — manages NSG security rules and Microsoft Defender policies, but cannot modify VNet topology (subnets, address spaces).
• Private DNS Zone Contributor — manages Private DNS zones only. Combine with Network Contributor when both VNet and DNS zone management are required.

Contributor (or Network Contributor) scoped to a specific NSG grants full management of that NSG's rules. However, it does not allow creating new resources in the parent resource group or modifying the DNS settings of a network interface in that RG. To create new storage accounts or resources in the RG, Contributor must be scoped to the resource group, not an individual resource.

An ABAC condition is attached to a role assignment and uses the pattern: !(ActionMatches{'action'}) OR @Resource[attribute] = 'value'. The condition only restricts the named action — all other actions permitted by the role pass through without the condition being evaluated. For example, a condition that restricts blob reads to those with tag Environment = Production does not affect write or delete operations.

To restrict users to viewing only blobs with specific blob index tags, use a role assignment condition (ABAC) on a blob data role such as Storage Blob Data Reader or Storage Blob Data Contributor. A condition like @Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Environment<$key>] = 'Production' filters access at evaluation time. Stored access policies and SAS tokens cannot filter by blob index tags — conditions are the only mechanism for tag-based access filtering.

To remove a group-based license from a specific user, you must remove that user from the licensed group. You cannot revoke a group-based license from an individual user directly — the license is managed at the group level. An administrator can also remove a directly-assigned license from a user account, but group-based ones require group membership changes.

A user who already receives a license through group membership can additionally be assigned other licenses directly. This does not remove or conflict with the group-based license — both apply. If a user receives P2 through Group1, and is also directly assigned a Fabric license, both licenses are active simultaneously.

Individual user accounts can be deleted regardless of their license status. A user who receives a license through group membership, or who has a directly assigned license, can still be deleted. Deleting the user removes them from all group memberships and revokes all licenses automatically.

When bulk-importing users from a CSV file, the most efficient way to automatically assign them to groups based on their department is to create groups with Dynamic User membership type and rules based on user.department. As soon as the users are imported and their department attribute is populated, they are automatically added to the matching dynamic group. No manual group assignment or PowerShell script is needed afterwards.

• String — applies a fixed literal value to every group name. For example, a prefix String of "Contoso-" makes every group name start with "Contoso-".
• Attribute — dynamically inserts a value from the group creator's user profile. For example, a prefix Attribute of "Department" inserts the creator's department value (e.g., "Sales", "Engineering") at the start of the group name.

This setting controls which external domains can receive invitations from your tenant. To restrict so that only users from a specific partner domain (e.g., fabrikam.com) can be invited, configure the Collaboration restrictions setting under External Collaboration Settings. Options include allowing all domains, denying specific domains (blocklist), or allowing only specific domains (allowlist). This is the correct setting when the requirement is "only allow invitations to be sent to fabrikam.com users."

Cross-Tenant Access Settings configure trust and access controls between two specific Azure AD tenants — for example, whether MFA claims from a partner tenant are trusted, or whether B2B direct connect (shared channels in Teams) is enabled. This is not for controlling which domains can be invited; it is for managing the trust relationship after a guest relationship exists.

• Connected organisation — an external tenant explicitly configured for access requests. Users from connected organisations can request access packages if the policy allows.
• Non-connected organisation — not explicitly configured. Whether their users can request access depends on whether the access package policy allows requests from "All users" (including unconnected external users).
• Access expiration — when an access package assignment expires, the user is removed from all resources in that package (groups, app assignments, SharePoint sites).

1. Day 365 (access expires) — the user is removed from Group1 and all other resources in the access package. The guest account still exists in the tenant.
2. Day 395 (365 + 30-day grace period) — if the external user lifecycle settings specify "remove the user after N days with no active access packages," the guest account itself is deleted from the tenant.

• Attribute Definition Administrator — creates and manages attribute sets and individual attribute definitions. Cannot assign attribute values to objects.
• Attribute Assignment Administrator — assigns attribute values to Entra identity objects. Cannot create new attribute definitions.

Both roles are needed together to set up and use custom security attributes: one creates the definition, the other assigns values. To configure both tasks (create Property1 AND ensure Admin1 can assign it to users), configure Custom security attributes (to create the definition) and Roles and administrators (to grant the Attribute Assignment Administrator role to Admin1) in the Entra ID blade.

Custom Security Attributes can be assigned to users, security groups, and service principals. All three are supported. A service principal represents an application's identity in Entra — it is a valid target for attribute assignment. Custom Security Attributes cannot be assigned to Azure resources (VMs, storage accounts, etc.) — only to Entra identity objects.

To assign an Entra admin role (e.g., User Administrator) to a user: open the user's profile in the Microsoft Entra admin centre → navigate to the Directory role blade → click "Add assignments" and select the desired role. The Licenses blade assigns product licenses. The Groups blade manages group memberships. The Directory role blade is the only location for Entra admin role assignment from the user account properties.

When SSPR is enabled for "Selected" users (rather than All), it can only be scoped to Security groups. Microsoft 365 groups and Mail-enabled security groups cannot be used to scope SSPR. This is consistent with the general pattern that SSPR group targeting requires Security groups specifically.

• Global Administrator — full SSPR configuration authority.
• Authentication Policy Administrator — can configure authentication policies including all SSPR settings. This is the dedicated role for this purpose.
• Authentication Administrator — can manage authentication methods for non-admin users; limited SSPR scope.
• Security Administrator — manages security policies, Defender settings, and security posture. Does not have authority to configure SSPR settings.

• Security questions are an optional SSPR method that must be explicitly enabled in the Authentication methods blade.
• Administrators configure how many questions users must register (e.g., 3) and how many they must correctly answer to reset (e.g., 3). These two numbers can differ — a user might register 5 questions but only need to answer 3 to reset.
• A user who has successfully answered the required number of security questions AND any other required methods can reset their password immediately.

• Auto-registration is enabled or disabled on the virtual network link in the private DNS zone — specifically the "Enable auto registration" toggle on that link.
• When enabled, Azure creates an A record in the private zone whenever a VM in the linked VNet starts up, and removes it when the VM is deallocated.
• All VMs in the linked VNet are auto-registered — there is no per-VM opt-in or opt-out.
• Auto-registration only works with private DNS zones. Public DNS zones do not support it.

Co-administrator can only be added to an Azure subscription. When presented with a list of possible targets — Management Group, Subscription, Resource Group, VM — the only valid answer is the subscription. Attempting to add a co-administrator to a resource group, VM, or management group is not possible.

• User-level FTPS credentials — a username and password set by the developer in the Azure portal. These are specific to the user but use a custom deployment password, not the user's Microsoft Entra credentials. Valid for FTP/FTPS deployments but not for Entra-authenticated deploys.
• App-level FTPS credentials — auto-generated per web app. These are shared by anyone who deploys to that app and also do not use Entra credentials.
• Microsoft Entra credentials (Web Deploy) — uses the developer's actual Entra identity for deployment via Web Deploy. The least-privilege RBAC role that enables this is Website Contributor. This is the correct answer when the requirement specifies using Entra credentials with least privilege.

1. Enable a system-assigned managed identity on the Azure resource (App Service, VM, etc.).
2. Assign the managed identity a Key Vault role — Key Vault Secrets User for read-only secret access, or Key Vault Secrets Officer for read/write.
3. The application uses DefaultAzureCredential or ManagedIdentityCredential in the SDK to authenticate automatically.

No credentials are stored anywhere — the managed identity token is issued by Entra ID at runtime.

Any application with the appropriate role assignment can access a Key Vault regardless of which Azure region it is in. An App Service in West Europe can access a Key Vault in East US — region proximity does not affect access permissions. Network restrictions (firewall rules, VNet service endpoints, private endpoints) must be explicitly configured if you want to limit access by network location.

• Allow all networks — the default; any internet IP can reach the vault (subject to RBAC/access policies).
• Selected networks — allow access from specific VNets (via service endpoints) or specific IP address ranges.
• Private endpoint only — all public access is blocked; vault is accessible only through the private endpoint from within the VNet.