Episode 3 — Groups — Types, Membership, and Access

In Episode 2 you managed individual identities — creating members, inviting guests, editing profiles, and restoring deleted users within the 30-day window. Managing users one by one doesn't scale; this episode shows how Microsoft Entra groups let you grant access once and have it apply to many.

Learning objectives

Distinguish Security groups from Microsoft 365 groups and choose the right type for a given scenario.
Choose between Assigned membership and dynamic membership for users or devices, and predict how rule changes affect membership.
Create and configure a group in the Microsoft Entra admin center with the correct role, name, owners, and members.
Explain what group nesting does — and does not — propagate in Microsoft Entra versus Azure RBAC.
Identify the four access assignment patterns and the groups you cannot manage in the admin center.

Why it matters

Assigning permissions, apps, licenses, and roles to individual users is slow, error-prone, and invisible to auditors. Groups let you define access once and apply it to every member — and limiting access to only those who need it is a core principle of Zero Trust. On the AZ-104 exam, group questions hinge on exact details: which group type allows devices as members, which properties are locked after creation, and why a nested group's members mysteriously lack access. Those details are precisely what this episode covers.

Why groups: assign once, apply to many

Instead of adding special permissions to each user, you create a group that applies those permissions to every member of the group. You can assign roles to a group, build membership around a job function or department, and target a Conditional Access policy at a group. Effective use of groups reduces manual work and enforces the principle of least privilege, reducing the risk of attack or breach.

Groups can manage access to resources that are:

part of your Microsoft Entra organization (permissions to manage users, applications, billing, and other objects),
external to your organization (non-Microsoft SaaS apps),
Azure services,
SharePoint sites,
on-premises resources.

Group types: Security vs Microsoft 365

You can manage two group types in the Microsoft Entra admin center:

	Security group	Microsoft 365 group
Purpose	Manage access to shared resources	Provide collaboration opportunities
Members can include	Users, devices, service principals	Users only
People outside the organization	—	Allowed as members
Can be nested in other groups	Yes (security in security)	No (see nesting limits below)
Owners	Users and service principals	Users and service principals
Group email address	No	Yes (option enabled at creation)

🧠 Mnemonic: "Security Shares access, M365 Meets people." Security groups gate resources (and can hold devices); Microsoft 365 groups gather humans — including people outside your org — around a shared mailbox.

Membership types: Assigned vs dynamic

Every group also has a membership type, which controls how members get in:

Membership type	How members are managed	Typical use
Assigned	You add specific users manually; each can have unique permissions	Stable, curated lists (e.g., a pilot group)
Dynamic membership for users	Rules on user attributes automatically add and remove users	Department- or location-based access
Dynamic membership for devices	Rules on device attributes automatically add and remove devices	Fleet management, device-targeted policy

With dynamic membership, when a member's attributes change, the system re-evaluates the rules and adds or removes the member automatically. Two hard constraints to remember:

A dynamic group is for either users or devices — never both in the same group.
Device rules can only reference device attributes — you can't build a device group based on the device owner's attributes.

Note that when a user or device attribute changes, all dynamic membership rules in the organization are processed for potential membership changes — and users added to a Microsoft 365 group this way receive the welcome notification (which you can turn off in Exchange PowerShell).

Creating and managing groups in the portal

To create groups or manage membership you need at least the Groups Administrator or User Administrator role. The flow: sign in to the Microsoft Entra admin center → Entra ID > Groups > All groups → New group, then:

Pick the Group type (Security or Microsoft 365 — the latter enables the Group email address option).
Enter a Group name — a check verifies the name isn't already in use, and the name can't start with a space (a leading space prevents the group from appearing as an option in steps like adding role assignments to group members).
Optionally set a description.
Optionally switch "Microsoft Entra roles can be assigned to the group" to Yes. This toggle:
- requires a P1 or P2 license,
- requires at least the Privileged Role Administrator role,
- automatically forces Assigned as the membership type,
- adds the ability to attach roles during creation.
Select the Membership type (Assigned, Dynamic User, or Dynamic Device).
Optionally add Owners and Members (they can also be added later), then Create.

Adding or removing members and owners later follows the same path (All groups → select group → Members or Owners); the process is identical for members and owners.

Editing a group's Properties exposes an important asymmetry:

Group type: cannot be changed after creation. To change it, delete the group and create a new one.
Membership type: can be changed — except when the group is role-assignable (the Entra-roles toggle was enabled).
Object ID: read-only, but you can copy it for PowerShell commands.

One edge case worth knowing: in cross-tenant delegated administration (GDAP), group creation isn't supported if the target tenant uses a group naming policy whose prefix/suffix references attributes of the calling user (such as department) — use an admin account in the target tenant instead.

Nesting groups — and the trap

For security groups, you can add an existing group as a member of another group (nested groups) via the child group's Group memberships page → + Add memberships. Nested groups can be used for membership and Conditional Access scopes. Removing a nested group from its parent removes any inherited access for its members.

But here is the exam trap. In Microsoft Entra, nested groups do NOT gain access to shared resources and applications assigned to the parent group — only members of the parent group get that access. Group-based licensing likewise ignores nested members. Yet in Azure RBAC, role assignments ARE transitive through security group nesting: a member of a nested group does receive a role assigned to the parent. These are two different systems with opposite behaviors:

Nesting also comes with a long not-supported list:

Adding groups to a group synced with on-premises Active Directory.
Adding security groups to Microsoft 365 groups.
Adding Microsoft 365 groups to security groups or to other Microsoft 365 groups.
Assigned membership to shared resources and apps for nested security groups.
Applying licenses to nested security groups.
Adding distribution groups in nesting scenarios.
Adding security groups as members of mail-enabled security groups.
Adding groups as members of a role-assignable group.

Four access assignment patterns

When granting access to a resource, you have four patterns:

Pattern	Who decides membership/access
Direct assignment	The resource owner assigns the user directly to the resource
Group assignment	The resource owner assigns a group; all members get access automatically
Rule-based assignment	The owner creates a group with a rule on user attributes that defines who's in
External authority assignment	Access comes from an external source (on-premises directory, SaaS app)

Groups you can't manage in the admin center

Two families of groups appear in your tenant but can't be managed in the Azure portal or Microsoft Entra admin center:

Groups synced from on-premises Active Directory — manage them on-premises (the same hybrid rule you saw for synced users in Episode 2).
Distribution lists and mail-enabled security groups — manage them in the Exchange admin center or Microsoft 365 admin center.

Best practices

Assign at least two owners to every group, for continuity.
Enable self-service group management with a group naming policy, group expiration policies, and join approval.
Use sensitivity labels to classify and govern Microsoft 365 groups.
Automate membership with dynamic groups based on attributes like department, location, or job title.
Run periodic access reviews (Microsoft Entra Identity Governance) and manage membership with access packages (entitlement management: approval workflows, access expiration, centralized grant/review/revoke).
Use group-based licensing to simplify provisioning and keep license assignments consistent — that's the heart of Episode 4.
Enforce RBAC to control who can manage groups.

Exercises

Exercise 3.1 — Create a security group with owners and members

In a trial tenant, create a security group named SG-Helpdesk-Pilot with Assigned membership, one owner, and two members. Which role do you need at minimum, and which two properties will you be unable to change afterward?

Solution

Minimum role: Groups Administrator (User Administrator also works).

Portal steps:

Sign in to the Microsoft Entra admin center (entra.microsoft.com) as at least a Groups Administrator.
Browse to Entra ID > Groups > All groups and select New group.
Group type: Security.
Group name: SG-Helpdesk-Pilot (no leading space — the name check also verifies it isn't already in use).
Membership type: Assigned.
Under Owners, select the link, pick one user, then Select. Under Members, pick two users, then Select.
Select Create.

Unchangeable afterward: the Group type (Security → Microsoft 365 requires deleting and recreating the group) and the Object ID (read-only, but copyable for PowerShell). The membership type would also be locked if you had enabled "Microsoft Entra roles can be assigned to the group."

Exercise 3.2 — Reason about a dynamic membership rule

You want a group that automatically contains every user whose department attribute equals Sales. (a) Which membership type do you pick? (b) A member, Dana, transfers and her department changes to Marketing — what happens? (c) Could the same group also automatically include the Sales team's laptops?

Solution

(a) Dynamic membership for users, with a rule on the user attribute department matching "Sales". Membership is then managed by rule, not by hand.

(b) When Dana's attribute changes, the system re-evaluates the dynamic membership rules and automatically removes her from the group — and with her, any access, apps, or licenses delivered through the group. No admin action needed.

(c) No. A dynamic group targets either users or devices, never both. You'd create a separate dynamic membership group for devices — and remember its rules can only reference device attributes, not the device owners' attributes.

Exercise 3.3 — The nested-group license mystery

Group G-AllStaff has a license assigned to it (group-based licensing). Security group G-Interns is added as a nested member of G-AllStaff. Amir is a direct member of G-Interns only. Does Amir get the license? Would he get a Reader role that Azure RBAC assigns to G-AllStaff on a subscription?

Solution

License: no. Applying licenses to nested security groups is not supported — group-based licensing only serves direct members of the licensed group, and in Entra, nested groups don't gain access to what's assigned to the parent. To license Amir, add him (or G-Interns' members) directly to G-AllStaff, or assign the license to G-Interns too.

RBAC role: yes. Azure RBAC role assignments are transitive through security group nesting, so Amir, as a member of a group nested in G-AllStaff, receives the Reader role on the subscription. Same nesting, opposite outcomes — two different systems.

Key takeaways

Security groups manage access and can contain users, devices, and service principals; Microsoft 365 groups are for collaboration, contain users only, allow external people, and get a group email address.
Membership is Assigned or dynamic (users or devices, never both); dynamic rules auto-add and auto-remove members when attributes change; device rules can't reference owner attributes.
Creating and managing groups requires Groups Administrator or User Administrator; the role-assignable toggle requires P1/P2 plus Privileged Role Administrator and forces Assigned membership.
Group type can never be changed after creation; membership type can — unless the group is role-assignable.
Entra nesting does not propagate access to shared resources, apps, or licenses; Azure RBAC role assignments are transitive through nesting.
You can't manage on-prem-synced groups (manage on-premises) or distribution lists / mail-enabled security groups (Exchange or Microsoft 365 admin center) in the Entra admin center.
Best practice: at least two owners, naming and expiration policies, access reviews, and group-based licensing.

Quick recall

Q: Which group type can contain devices and service principals as members? A: Security groups. Microsoft 365 groups contain users only (but can include people outside the organization).

Q: You created a Microsoft 365 group but needed a security group. Can you switch the type? A: No — Group type can't be changed after creation. Delete the group and create a new one.

Q: What three things happen when you enable "Microsoft Entra roles can be assigned to the group"? A: It requires P1/P2 licensing, requires the Privileged Role Administrator role, and forces Assigned membership (which then can't be changed).

Q: Scenario — a security group nested inside a parent group that's assigned to an application: do the nested group's members get the app? A: No. In Entra, only members of the parent group get access to shared resources and apps; nesting doesn't propagate it. (Contrast: an Azure RBAC role on the parent would reach them transitively.)

Q: Why should a group name never start with a space? A: A leading space prevents the group from appearing as an option in steps such as adding role assignments to group members.

Q: Where do you manage a distribution list that shows up in your tenant? A: In the Exchange admin center or Microsoft 365 admin center — not in the Entra admin center.

Coming up

Groups become truly powerful when they carry licenses. Episode 4 maps the Microsoft Entra ID editions — Free, P1, P2, and the Entra Suite — to the admin features that need them, then walks through group-based licensing: how it works, the usage-location requirement, and the pitfalls (nested groups, moving users) that catch admins out.