Domain 1 of 4 · Chapter 2 of 4

Users, Groups, and Devices

Users and groups: the two objects you assign access to

A new starter in Sales who should land in the Sales distribution group, get an E5 license, and be able to sign in from a managed laptop touches every object on this page at once: a user, a group, a license, and a device. Get the model straight first and the admin tasks become bookkeeping.

A Microsoft Entra ID user is a security principal you can sign in and assign access to. Three kinds matter for the exam: cloud-only users created directly in Entra, synced users that originate in on-premises Active Directory and flow up through Microsoft Entra Connect Sync or Cloud Sync (their onPremisesSyncEnabled is true and most properties are read-only in the cloud), and guest users (userType = Guest) invited through B2B collaboration. The source matters because it dictates where you edit the object: a synced user's name or group membership is changed on-premises, not in the cloud.

A group bundles users (and sometimes devices) so you grant access, a role, a license, or a Conditional Access policy once instead of per person. Every Entra group is two independent choices: its type (what it does) and its membership (how it fills), shown below. The type comes in exactly two flavors, and they are not interchangeable. A Security group[1] manages access to resources, roles, and applications; its members can be users, devices, service principals, and other groups (nesting). A Microsoft 365 group[1] exists for collaboration, so it ships a shared mailbox, calendar, SharePoint site, and Planner, and its members can only be users. If a question hands you devices to group, it is a Security group by elimination.

Membership: Assigned versus Dynamic

The second, independent choice is how the group fills. An Assigned group is curated by hand: an owner or admin adds and removes each member. A Dynamic group fills itself from a membership rule[2] evaluated against object attributes, so when a user's department changes the engine adds or removes them automatically. Two hard rules the exam leans on:

  • A single dynamic group targets users OR devices, never both, and a device rule may reference device attributes only (you cannot build a device group from the owner's department). 'All Sales people' and 'All Windows laptops' are two separate groups.
  • You cannot edit a dynamic group's members directly; the rule is the membership. Editing the rule requires the Groups Administrator, Intune Administrator, or User Administrator role, and the whole dynamic membership feature requires Microsoft Entra ID P1[2] for every member who benefits.
Rule syntax (single expression):  (user.department -eq "Sales")
Multi-condition:  (user.department -eq "Sales") and (user.country -eq "US")
Device rule:      (device.deviceOSType -eq "Windows")

The -eq, -contains, -match, -startsWith operators and and/or/not joiners build the rule; -match takes a regular expression. A malformed rule leaves the group empty rather than erroring loudly, which is the usual real-world trap.

A group = two choicesType (what it does)Security groupAccess to resources, roles, appsUsers, devices, SPs, nestingMicrosoft 365 groupCollaboration: mailbox, SharePointUsers onlyMembership (how it fills)AssignedAdmin adds each memberby handDynamicRule fills it; users OR devicesRequires Entra ID P1
The two independent axes of any Entra group: type and membership. Modeled on the Microsoft Entra groups concepts docs.

Licenses and custom security attributes

Licensing is where candidates lose easy marks, because two facts changed and the exam tracks the change.

Set Usage location first. Before any license can be assigned to a user, that user must have a Usage location[3] set, because some services are not available in every country; a user without one inherits the directory's location. Forget it and the assignment fails.

The license UI moved. Since September 1, 2024, the Microsoft Entra admin center and the Azure portal no longer expose license assignment in their UI[4]. User and group license assignment is now done in the Microsoft 365 admin center, while Microsoft Graph and PowerShell still work for scripted and bulk assignment. If an exam answer says 'assign the license in the Azure portal', it is testing whether you know this.

Group-based licensing

Instead of licensing 500 people one at a time, group-based licensing[4] attaches one or more product licenses to a security group: every member is licensed automatically on join and loses the license on leave, the lifecycle the figure traces. Entra recomputes assignments within minutes of a membership change. The rules that get tested:

  • It requires Microsoft Entra ID P1 or higher (or a qualifying Microsoft 365 Business Premium / Office 365 E3-and-higher plan) for every user who benefits, and you must hold at least one license per unique member of a licensed group.
  • Nested groups are not honored: only first-level members of the licensed group receive the license. Members of a sub-group do not.
  • You can disable individual service plans within a product when assigning (for example license Microsoft 365 but turn off Yammer for one department).
  • When licenses run short or two assigned products conflict, Entra flags the affected users so an admin can act; the user shows a license error rather than silently getting the product.

Pair group-based licensing with a dynamic security group and a department's licensing becomes fully self-managing: the HR attribute drives membership, membership drives the license.

Custom security attributes

Custom security attributes[5] are business-defined key-value pairs you attach to Entra objects to store data, categorize objects, or drive attribute-based access control (ABAC)[6]. Four facts the exam turns on:

  • They are assignable to users and enterprise applications (service principals) only, organized into attribute sets, and typed as Boolean, integer, or string (single or multi-value, free-form or predefined).
  • Access is RBAC-gated by a separate set of roles: Attribute Definition Administrator (the minimum to create attributes), Attribute Assignment Administrator (the minimum to assign values), plus the matching Reader roles, scoped at tenant or attribute-set level.
  • Crucially, Global Administrator and other admin roles have no access by default: someone with at least Privileged Role Administrator must grant an Attribute role first. This is the single most tested custom-security-attribute fact.
  • The feature is free in all editions of Microsoft Entra ID, with a ceiling of 500 active attribute definitions per tenant.

The practical line versus directory extensions: extensions store non-sensitive app data that anyone who can read the object can read; custom security attributes store sensitive, access-control data behind their own RBAC.

License on groupAttach to security groupFirst-level memberjoins the groupJoinLeaveAuto-licensedwithin minutesDe-licensedon leaveNested sub-group members: not honored
Group-based licensing lifecycle: join auto-licenses a first-level member, leave removes it, nesting is not honored. Modeled on the Microsoft Entra group-based licensing docs.

Devices: join versus registration

The device decision is a clean fork, so lead with the rule: register a device the user owns, join a device the organization owns. Both produce a device object in Entra ID and both can be governed by Conditional Access; what differs is ownership and which account the user signs in with.

Microsoft Entra registration[7] (also called Workplace join) targets bring-your-own-device (BYOD) and mobile scenarios. The user keeps signing in with their personal or local account (a Microsoft account, a local Windows account, an Apple ID) and only attaches a work identity to reach organizational resources. It spans Windows 10+, macOS, iOS, Android, and Linux, and is how a personal phone gets Conditional Access without the company taking over the device.

Microsoft Entra join[8] targets organization-owned devices. The user signs in with their Entra (work) account, and the device is suitable for cloud-only and hybrid organizations. It covers all Windows 11 and Windows 10 devices except Home editions, Windows Server 2019+ VMs in Azure (not Server Core), macOS 13+, and several Linux editions, and is provisioned by the Out-of-Box Experience, bulk enrollment, or Windows Autopilot. Join unlocks SSO to both cloud and on-premises resources and Windows Hello for Business sign-in.

Microsoft Entra hybrid join is the third option, and the one the SC-300 only touches at the hybrid seam: an on-premises AD-domain-joined device is also registered with Entra ID, so it answers to Group Policy and on-premises AD while gaining cloud SSO and Conditional Access. It is the migration bridge for organizations not yet ready for cloud-only join, configured through Microsoft Entra Connect; the deep configuration of Connect itself lives in the Hybrid Identity subtopic.

Why join is not enrollment

A predictable misread: joining or registering a device is not the same as enrolling it in MDM. Join/register establishes the device identity in Entra ID; enrollment (typically Microsoft Intune) is a separate step that brings the device under management policy (encryption, password complexity, compliance). A device can be Entra registered without ever being enrolled, which is exactly why a Conditional Access 'require compliant device' control can block a registered-but-unenrolled personal phone.

Who owns the device?Personal vs organizationUser (BYOD)OrganizationMicrosoft Entra registeredPersonal/local sign-inAdds a work identityAlready AD domain-joinedon-premises?YesNoMicrosoft Entra hybrid joinKeeps GPO + on-prem ADAdds cloud SSO + CAMicrosoft Entra joinWork-account sign-inCloud-only or hybrid orgAll three create a device object; MDM enrollment (Intune) is a separate step
Device ownership picks registration vs join; on-premises AD domain membership then picks hybrid join. Modeled on the Microsoft Entra device identity docs.

Bulk operations and exam-pattern recognition

At scale you stop clicking. The Microsoft Entra admin center[9] offers Bulk create, Bulk invite, Bulk delete, and Bulk restore operations driven by a downloaded CSV template you fill and re-upload. For anything repeatable or pipelined, Microsoft Graph PowerShell[10] is the current tooling.

# Microsoft Graph PowerShell (the MSOnline and AzureAD modules are retired)
Connect-MgGraph -Scopes "User.ReadWrite.All","Group.ReadWrite.All"

# Create a user
$pw = @{ Password = "<temp>"; ForceChangePasswordNextSignIn = $true }
New-MgUser -DisplayName "Ann Lee" -UserPrincipalName "ann@contoso.com" `
  -MailNickname "annlee" -AccountEnabled -PasswordProfile $pw -UsageLocation "US"

# Create a security group and add a member
$g = New-MgGroup -DisplayName "Sales" -MailEnabled:$false `
  -MailNickname "sales" -SecurityEnabled -GroupTypes @()
New-MgGroupMember -GroupId $g.Id -DirectoryObjectId (Get-MgUser -UserId "ann@contoso.com").Id

Note UsageLocation is set at creation so a license can be assigned afterward, and that the legacy MSOnline and AzureAD PowerShell modules are deprecated in favor of Microsoft Graph PowerShell; an exam answer naming Connect-AzureAD is testing whether you know it retired.

What the questions look like

  • "Group devices for a dynamic Intune target." The answer is a Security group with a Dynamic Device rule. Distractor: a Microsoft 365 group (holds users only) or a dynamic group spanning users and devices (impossible, one or the other).
  • "Assign a license but it fails / the option is missing." Either the user has no Usage location, or the candidate is told to use the Azure portal / Entra admin center UI, which no longer offers license assignment (use the Microsoft 365 admin center or PowerShell).
  • "License a sub-group's members via the parent." Wrong: group-based licensing covers first-level members only; nested membership is not honored.
  • "Let a non-admin read salary attributes." The answer is an Attribute Assignment/Definition role, not Global Administrator, which has no attribute access by default.
  • "Personal phone needs work email + Conditional Access." That is Microsoft Entra registration, not join; join is for organization-owned hardware where the user signs in with the work account.
  • "Bulk onboard 500 users from HR." CSV Bulk create in the Entra admin center, or Microsoft Graph PowerShell (New-MgUser), not the retired AzureAD module.

Comparing the two group types with dynamic membership and group-based licensing

Decision axisSecurity groupMicrosoft 365 groupDynamic membershipGroup-based licensing
Primary purposeAccess to resources, roles, appsCollaboration (mailbox, SharePoint)Auto-fill from attribute ruleAuto-license members
Can containUsers, devices, SPs, nested groupsUsers onlyUsers OR devices (not both)Members of a security group
Membership edited byOwner/admin or a ruleOwner/admin or a ruleThe rule only, not by handGroup membership
License neededFree (Assigned)Free (Assigned)Entra ID P1Entra ID P1 or M365/O365 E3+
Nesting honored?Yes, for accessLimitedn/aNo, first-level members only

Decision tree

Purpose of the group?Access vs collaborationAccess to resourcesCollaborationMembers include devices?or service principalsMicrosoft 365 groupUsers only; mailbox,SharePoint, PlannerYes/eitherUsers onlySecurity groupUsers, devices, SPs, nestingAuto-fill from attributes?needs Entra ID P1NoYesAssigned membershipAdmin curates membersDynamic membershipRule fills users OR devices
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Group type and membership type are two independent choices

An Entra group is defined by two separate axes: its type (Security or Microsoft 365) sets the purpose, and its membership type (Assigned or Dynamic) sets how members get in. You pick both when you create the group, so 'a dynamic security group' and 'an assigned Microsoft 365 group' are both valid combinations. Treating type and membership as one menu is the usual source of wrong answers.

Security groups hold devices; Microsoft 365 groups hold users only

A Security group manages access to resources, roles, and apps and can contain users, devices, service principals, and other groups (nesting). A Microsoft 365 group is for collaboration (shared mailbox, SharePoint, Planner) and can contain users only. So whenever you need to group devices or service principals, it has to be a Security group.

Trap Putting devices into a Microsoft 365 group; it accepts users only, so a device-targeting group must be a Security group.

1 question tests this
A dynamic group targets users OR devices, never both

When you want membership to fill automatically from attributes, you choose Dynamic User or Dynamic Device, and a single dynamic group can only be one of them. A device rule may reference device attributes only, so you cannot build a device group from the owner's department. 'All Sales staff' and 'All Windows laptops' are therefore two separate groups.

Trap Writing one dynamic rule that mixes user and device attributes to cover both; a dynamic group is users-only or devices-only, and device rules see device attributes only.

You cannot hand-edit a dynamic group's members

A dynamic group's membership is governed entirely by its rule, so an owner or admin cannot add or remove individual members the way they can in an Assigned group. To change who is in it you edit the rule, which requires the Groups Administrator, Intune Administrator, or User Administrator role. If you need manual control over exactly who is a member, use an Assigned group.

Trap Trying to remove one user directly from a dynamic group; only the rule controls membership, so you must change the rule or switch to an Assigned group.

Dynamic membership requires Microsoft Entra ID P1

Dynamic membership rules are a paid feature: every member who benefits needs a Microsoft Entra ID P1 license. The free Entra tier gives you Assigned groups only. A malformed rule, rather than erroring, simply leaves the group empty, so test the rule after editing.

Group-based licensing rides on a security group and needs P1 or M365 E3+

Group-based licensing attaches one or more product licenses to a security group; members are licensed automatically when they join and lose the license when they leave, and Entra recomputes within minutes. It requires Microsoft Entra ID P1 (or a qualifying Microsoft 365 Business Premium / Office 365 E3-and-higher plan) for every benefiting user, and you must hold at least one license per unique member of the group. You can disable individual service plans within a product when you assign it.

Group-based licensing only licenses first-level members

Group-based licensing does not flow through nested groups: only the direct, first-level members of the licensed group receive the license, and members of a sub-group do not. To license everyone, either flatten the membership or license each group directly. This is a favorite distractor because nesting works for access but not for licensing.

Trap Licensing a parent group and expecting members of nested sub-groups to inherit it; group-based licensing honors first-level members only.

Set a user's Usage location before assigning any license

A license cannot be assigned to a user until that user has a Usage location set, because some services are restricted by country; a user without one inherits the directory's location. Forget it and the license assignment fails. This is the first thing to check when a license assignment errors.

Trap Assigning a license to a freshly created user that has no Usage location; the assignment fails until the Usage location is set.

1 question tests this
License assignment moved out of the Azure portal and Entra admin center

Since September 1, 2024 the Microsoft Entra admin center and the Azure portal no longer expose license assignment in their UI; user and group license assignment is done in the Microsoft 365 admin center. Microsoft Graph and PowerShell still assign licenses, so scripted and bulk workflows are unaffected. An answer telling you to assign the license in the Azure portal UI is testing this change.

Trap Choosing 'assign the license in the Microsoft Entra admin center / Azure portal' UI; since September 2024 that UI is gone and assignment happens in the Microsoft 365 admin center (or Graph/PowerShell).

Custom security attributes attach only to users and service principals

Custom security attributes are business-defined key-value pairs you assign to Microsoft Entra objects, but the supported targets are users and enterprise applications (service principals) only. They are organized into attribute sets and typed as Boolean, integer, or string (single or multi-value, free-form or predefined), and you can use them to drive attribute-based access control (ABAC). Unlike directory extensions, which anyone who can read the object can read, custom security attributes hold sensitive data behind their own RBAC.

Global Administrator has no custom-security-attribute access by default

Custom security attributes are gated by a dedicated set of roles, and Global Administrator and other admin roles cannot read, define, or assign them until granted one. Attribute Definition Administrator is the minimum to create attributes; Attribute Assignment Administrator is the minimum to assign values; matching Reader roles grant read-only access. These can be scoped at the tenant or at a single attribute set.

Trap Assuming Global Administrator can read or assign custom security attributes; by default it has no access, so you must grant an Attribute Definition or Attribute Assignment role explicitly.

3 questions test this
Custom security attributes are free, with a 500-definition tenant cap

The custom security attributes feature is included free in all editions of Microsoft Entra ID, so it does not require P1 or P2. A tenant can hold up to 500 active attribute definitions. That free-tier status is worth remembering because so many other group and licensing features on this topic do require P1.

Register a device the user owns; join a device the org owns

Microsoft Entra registration (Workplace join) is for bring-your-own-device and mobile scenarios: the user keeps signing in with a personal or local account and only attaches a work identity for access. Microsoft Entra join is for organization-owned devices, where the user signs in with their Entra work account, and it suits cloud-only or hybrid organizations. Both produce a device object in Entra ID and both can be governed by Conditional Access; the deciding line is ownership and the sign-in account, not the operating system.

Trap Joining a user-owned personal device to get it work email and Conditional Access; personal devices should be Entra registered, and join is reserved for organization-owned hardware.

Entra join covers Windows 10/11 except Home, plus macOS and Linux

Microsoft Entra join supports all Windows 11 and Windows 10 devices except Home editions, Windows Server 2019+ VMs in Azure (Server Core excluded), macOS 13 or newer, and several Linux editions. It is provisioned through the Out-of-Box Experience, bulk enrollment, or Windows Autopilot. Windows Home cannot be Entra joined, which is a common distractor.

Trap Expecting to Microsoft Entra join a Windows Home edition device; Home editions are not supported, only Pro/Enterprise/Education and the listed macOS and Linux builds.

Hybrid join bridges an AD-domain device to the cloud

Microsoft Entra hybrid join takes a device that is already joined to on-premises Active Directory and also registers it with Entra ID, so it keeps Group Policy and on-premises AD authentication while gaining cloud SSO and Conditional Access. It is the migration option for organizations not yet ready for cloud-only Entra join, and it is configured through Microsoft Entra Connect. Reach for it when existing AD-domain-joined Windows devices must come under Conditional Access without re-imaging.

Joining or registering a device is not enrolling it in MDM

Device join and registration establish the device's identity in Entra ID, but they do not place the device under management policy. MDM enrollment, typically Microsoft Intune, is a separate step that enforces compliance like encryption and password rules. This is why a Conditional Access 'require compliant device' control can still block a device that is Entra registered but never enrolled.

Trap Assuming an Entra registered or joined device automatically satisfies a 'require compliant device' Conditional Access control; compliance comes from separate Intune enrollment, not from the device identity alone.

1 question tests this
Bulk user and group operations use a CSV template in the Entra admin center

The Microsoft Entra admin center provides Bulk create, Bulk invite, Bulk delete, and Bulk restore operations, each driven by a CSV template you download, fill in, and upload. Use it to onboard or offboard many users at once without scripting. For repeatable or pipelined automation you move to PowerShell or Microsoft Graph instead.

Automate Entra identity tasks with Microsoft Graph PowerShell, not the retired modules

The current PowerShell tooling for Entra users, groups, licensing, and devices is Microsoft Graph PowerShell (for example Connect-MgGraph, New-MgUser, New-MgGroup). The older MSOnline and AzureAD modules are deprecated and retired, so scripts built on Connect-AzureAD or the MSOnline cmdlets should be migrated. An exam answer naming AzureAD or MSOnline cmdlets is usually the wrong, dated choice.

Trap Reaching for the AzureAD or MSOnline PowerShell modules to script Entra changes; both are retired, and Microsoft Graph PowerShell (Connect-MgGraph, New-MgUser) is the supported tooling.

Synced users are edited on-premises, not in the cloud

A user that originates in on-premises Active Directory and flows up through Microsoft Entra Connect Sync or Cloud Sync is a synced user, with onPremisesSyncEnabled set and most properties read-only in Entra ID. You change a synced user's name, attributes, or group membership in on-premises AD, and the change syncs up. Cloud-only and guest (B2B) users, by contrast, are edited directly in Entra.

Trap Trying to edit a synced user's attributes directly in the Microsoft Entra admin center; synced properties are read-only in the cloud and must be changed in on-premises AD.

Conditional Access application filters work only with String custom security attributes

To target applications dynamically with a Conditional Access policy, tag them with a custom security attribute and add a filter for applications under Target resources (Select resources, then Edit filter). Conditional Access filters for applications only work with custom security attributes of type String; other data types such as Boolean are not supported by the policy filter even though they can be defined. Filters are evaluated at token-issuance runtime, not configuration, so newly tagged apps are covered automatically without editing the policy.

Trap Selecting a non-String attribute (for example Boolean) for the filter; only String is supported

4 questions test this
Deleted users are soft-deleted for up to 30 days and managed via /directory/deletedItems

A deleted user remains available in a soft-deleted state for up to 30 days, and after 30 days it is permanently deleted. Using the Microsoft Graph API: list deleted users with GET /directory/deletedItems/microsoft.graph.user, restore one with POST /directory/deletedItems/{id}/restore, and permanently remove one with DELETE /directory/deletedItems/{id}. After a permanent delete the account cannot be recovered.

Trap Sending DELETE to /users/{id} again to purge it instead of DELETE /directory/deletedItems/{id}

3 questions test this
Block sign-in without deleting by setting accountEnabled to false

To stop a user from signing in while keeping the account, send PATCH /users/{id} with accountEnabled set to false; this is exactly what the Block sign in toggle does in the admin center. For an app running without a signed-in user, User.EnableDisableAccount.All plus User.Read.All is the least privileged combination of application permissions to update accountEnabled.

Trap Deleting the account or removing licenses when only a sign-in block was needed

3 questions test this
Configuring Intune forces device registration to All and removes the None option

Enrollment with Microsoft Intune or mobile device management for Microsoft 365 requires device registration. If you've configured either of these services, the Users may register their devices with Microsoft Entra ID setting is set to All and None becomes unavailable.

Trap Expecting to disable registration with None while Intune is configured

3 questions test this
Add a group member with New-MgGroupMember using -GroupId and -DirectoryObjectId

The New-MgGroupMember Microsoft Graph PowerShell cmdlet adds a member to a group. Pass the target group's object ID to -GroupId and the user's (or directory object's) object ID to -DirectoryObjectId. It maps to the POST /groups/{group-id}/members/$ref Microsoft Graph API.

Trap Reaching for retired AzureAD module cmdlets like Add-AzureADGroupMember instead of the Graph cmdlet

3 questions test this
Get-MgSubscribedSku: ConsumedUnits are assigned, PrepaidUnits.Enabled are purchased

Get-MgSubscribedSku reports each licensing plan's ConsumedUnits (licenses already assigned to users) and PrepaidUnits.Enabled (active purchased licenses). Licenses still available to assign equal PrepaidUnits.Enabled minus ConsumedUnits.

Trap Reading ConsumedUnits as the licenses remaining rather than the licenses already assigned

4 questions test this
Creating a user via Graph requires five properties including passwordProfile

POST /users (and the New-MgUser cmdlet) requires accountEnabled, displayName, mailNickname, userPrincipalName, and passwordProfile at a minimum. In PowerShell, supply -PasswordProfile a hash table containing a Password key (and optionally ForceChangePasswordNextSignIn). Creating a user needs the User.ReadWrite.All (or Directory.ReadWrite.All) permission.

Trap Omitting mailNickname, which is required even though it is easy to overlook

4 questions test this

Also tested in

References

  1. https://learn.microsoft.com/en-us/entra/fundamentals/concept-learn-about-groups
  2. https://learn.microsoft.com/en-us/entra/identity/users/groups-dynamic-membership
  3. https://learn.microsoft.com/en-us/entra/identity/users/licensing-group-advanced
  4. https://learn.microsoft.com/en-us/entra/fundamentals/concept-group-based-licensing
  5. https://learn.microsoft.com/en-us/entra/fundamentals/custom-security-attributes-overview
  6. https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-overview
  7. https://learn.microsoft.com/en-us/entra/identity/devices/concept-device-registration
  8. https://learn.microsoft.com/en-us/entra/identity/devices/concept-directory-join
  9. https://learn.microsoft.com/en-us/entra/identity/users/users-bulk-add
  10. https://learn.microsoft.com/en-us/powershell/microsoftgraph/overview