What Does Dynamic group Mean?
On This Page
Quick Definition
Dynamic groups are a type of security or Microsoft 365 group that automatically adds or removes members based on rules you set. For example, you can create a rule that says if a user is in the Sales department, they automatically become a member of the Sales group. This saves time because you don't have to add or remove people by hand when things change.
Commonly Confused With
An assigned group requires manual addition and removal of members by an administrator. A dynamic group adds and removes members automatically based on rules. The key difference is automation: assigned groups need human action, dynamic groups update themselves.
If you create a group called “Marketing Team” and add John manually, that is an assigned group. If you create a rule that says “add anyone whose department is Marketing,” that is a dynamic group.
A role-assignable group is a special type of group that can be assigned to Azure AD administrative roles or Azure RBAC roles. Dynamic groups cannot be used for this purpose. Role-assignable groups must be manually managed and cannot be dynamic.
You need a group that can be given the “User Administrator” role. That group must be a role-assignable group and cannot be dynamic. A dynamic group can be a security group but not role-assignable.
A distribution group is used for email communication to a list of recipients. Dynamic groups are security groups used for access control and licensing. Distribution groups do not have security features, while dynamic groups do. Also, dynamic groups cannot be mail-enabled.
You want to send an email to all Sales department employees. You can use a distribution group. You want to give Sales employees access to a shared folder. You use a dynamic security group.
An Administrative Unit is used to delegate administrative permissions over a subset of users, groups, or devices. A dynamic group is used for automatic membership based on attributes. They solve different problems: AU is about delegation, dynamic groups are about automatic membership.
You want to let the HR manager manage only HR users. You create an Administrative Unit for HR. You want all HR users to get a specific license automatically. You create a dynamic group with a rule for department equals HR.
Must Know for Exams
For the MS-102 exam (Microsoft 365 Administrator), dynamic groups are a key topic because they are used extensively in Microsoft 365 for licensing, access control, and management. The exam objectives for MS-102 include deploying and managing Microsoft 365 tenants, managing users and groups, and implementing identity synchronization. You will see questions that ask you to configure dynamic group rules to automate license assignments or to manage access to Microsoft 365 services. You need to know the difference between dynamic groups and assigned groups, and when to use each type. You might also be asked to troubleshoot why a user is not being added to a dynamic group, which usually points to an attribute issue or a sync delay.
For the AZ-104 exam (Microsoft Azure Administrator), dynamic groups appear in the context of managing Azure AD and identity governance. The exam objectives include managing Azure AD users and groups, and implementing and managing hybrid identities. You may encounter scenarios where you need to create a dynamic group to support role-based access control (RBAC) or to manage access to Azure resources. You will also need to understand how dynamic groups interact with Azure AD Connect for hybrid environments, especially when attributes are synchronized from on-premises Active Directory. The exam may test your ability to write a rule syntax and to understand the limitations of dynamic groups, such as the fact that they cannot contain members from other groups (nesting is not supported).
In both exams, dynamic groups are often the correct answer when a question describes a need for automatic membership updates based on changing employee attributes. Questions may be scenario-based, where you are given a business requirement and must select the correct group type and rule. You might also see comparison questions asking you to identify the best method for assigning licenses or controlling access. The traps often involve confusing dynamic groups with administrative units or with role-assignable groups.
Simple Meaning
Think of a dynamic group like a smart club that has an automatic door. Instead of a bouncer checking a list and letting people in one by one, the door reads a badge that each person wears. The badge has information on it, like the person's job title or department. The door is programmed to let in only people whose badges say they work in a specific department, like Sales. If someone changes jobs and their badge gets updated to a different department, the door no longer lets them into the Sales club area. They automatically lose access. You don’t need a person to update the list. The club runs itself.
In IT, dynamic groups work the same way. You write a rule that looks at a user’s attributes, such as department, country, job title, or even whether they are a full-time employee. Microsoft Entra ID (formerly Azure AD) checks these attributes regularly and adds or removes users from the group automatically. This is extremely useful for large organizations where people are constantly being hired, promoted, or leaving. Without dynamic groups, an IT administrator would have to manually update every group every time someone’s role changes. That is slow and error-prone. With dynamic groups, the membership rules do all the work in the background. The group is always up to date without any manual effort. This makes access control, license assignment, and policy targeting much more efficient and reliable.
Full Technical Definition
A dynamic group in Microsoft Entra ID (Azure AD) is a group type that supports rule-based membership evaluation. It uses an expression syntax based on user or device attributes to automatically add or remove members. The rules are written using a specific syntax that resembles a simple programming expression, such as user.department -eq “Sales”. This syntax supports operators like -eq (equals), -ne (not equals), -startsWith, -contains, and -like, along with logical operators -and, -or, and -not. Parentheses can be used to nest expressions and control evaluation order.
Dynamic groups rely on the Microsoft Entra ID provisioning engine. When a user or device attribute changes, the engine recalculates the group membership. This recalculation usually happens within a few minutes, though it can take longer for very large tenants. The groups can be either security groups or Microsoft 365 groups, but they cannot be mail-enabled distribution groups. The rules are applied at the tenant level, and the maximum number of dynamic group rules per tenant is 5,000.
Dynamic groups are defined using the Azure portal, Microsoft Graph API, or PowerShell with the AzureAD module. The rule syntax uses a specific schema with predefined attributes. For users, common attributes include department, jobTitle, country, city, userType, and custom extension attributes. For devices, common attributes include deviceOSType, deviceModel, and displayName. You can create rules that combine multiple conditions, such as adding users who are in the Sales department AND are full-time employees.
One critical technical detail is that dynamic groups are evaluated based on the user’s or device’s current attribute values at the time of evaluation. Historical changes are not tracked. If an attribute is missing or null, the rule may not match that user, so administrators must ensure that the required attributes are populated. Dynamic groups also have a processing limit for very large groups, and membership changes can be delayed during peak times.
In terms of security, dynamic groups can be used to assign licenses, manage access to applications, and apply conditional access policies. However, there is a limitation: you cannot use dynamic groups in nested group assignments in some scenarios. Always check the specific exam objectives for each exam for the most current limitations.
Real-Life Example
Imagine you run a large hospital with hundreds of doctors and nurses. Each staff member has an ID badge that shows their role, like “Cardiologist” or “ER Nurse.” The hospital has an automatic security system that controls access to the operating rooms. Instead of giving each person a physical key, the system reads the badge whenever someone walks up to the door. The system is programmed to allow entry only to people whose badge says “Cardiologist” or “ER Nurse.” If a nurse transfers from the ER to the cardiology department, their badge is updated with the new role. The next time they enter the OR, the system recognizes the update and keeps access. If a doctor leaves the hospital, their badge is deactivated, and the system automatically prevents entry. No one has to manually update a list of who can enter the OR. The badge itself triggers the correct access.
In the IT world, a dynamic group works exactly like this badge-reading system. Your organization’s user database (Entra ID) is like the badge system. Each user has attributes, like department or job title, which are like the information on the badge. Instead of a door, you have a group that controls access to resources like email, apps, or files. You write a rule that says, “If a user’s department equals Sales, add them to the Sales Group.” When a new salesperson is hired, their attribute is set to Sales, and Entra ID automatically adds them to the Sales Group. When they move to Marketing, the attribute changes, and they are moved automatically. The group membership always matches the current reality without anyone having to lift a finger.
Why This Term Matters
In modern IT environments, managing group membership manually is not practical. Organizations with thousands of employees see constant changes: people join, leave, get promoted, transfer between departments, or change roles. If IT administrators have to manually update every group every time someone’s role changes, the process becomes slow and prone to mistakes. A human might forget to remove an employee from a group after they leave, creating a security risk. Or they might add someone to the wrong group, granting access to resources they should not have.
Dynamic groups solve these problems by automating membership. They ensure that the right people have access to the right resources based on their current attributes. This is especially important for security groups used in conditional access policies. For example, you can create a dynamic group that includes only users in the Finance department, and then apply a conditional access policy that requires multi-factor authentication for that group. Because the group is dynamic, the policy always applies to the correct users, even if the Finance team changes.
Dynamic groups also reduce administrative overhead. Instead of spending hours each week updating groups, IT teams can focus on more strategic work. They also reduce the risk of human error, which is a common cause of security breaches. For certification exams, understanding dynamic groups is important because Microsoft heavily emphasizes automation and identity governance. Questions often test your ability to choose when to use a dynamic group versus a manually assigned group, and how to write a rule that meets a specific business requirement.
How It Appears in Exam Questions
In exams, dynamic group questions typically fall into several patterns. The first is the “select the correct group type” question. You are given a scenario where a company needs to automatically manage group membership based on user attributes like department or country. The correct answer is usually a dynamic group. The wrong answers might include an assigned security group, a mail-enabled security group, or a distribution group.
A second pattern is the “write or interpret a rule” question. You might be shown a rule expression, such as user.department -eq “Sales”, and asked what that rule does. The answer is that it adds all users whose department attribute equals “Sales” to the group. You might also be asked to identify the correct syntax, including the correct attribute name and operator. For example, you need to know that -eq is used for equality, not ==.
A third pattern is the troubleshooting question. A user reports that they are not in a dynamic group that they should be in. You need to identify why. The possible causes include: the user’s attribute value does not match the rule (e.g., the department is “sales” in lowercase, but the rule expects “Sales” with a capital S), the attribute is not populated for that user, the user is synced from on-premises and the attribute has not synchronized yet, or there is a delay in group membership evaluation (which can take up to 30 minutes in some cases).
A fourth pattern is the comparison question, where you are asked to differentiate between dynamic groups and other group types, such as role-assignable groups or nested groups. You may also be asked which type of group supports rule-based membership. In these questions, the correct answer is always dynamic groups, but you must be careful not to pick an option that says “assigned group” or “nested group.”
Practise Dynamic group Questions
Test your understanding with exam-style practice questions.
Example Scenario
You are the IT administrator for a company called Contoso, which has 2,000 employees. The company has a new policy: all employees in the Finance department must have access to a specific financial reporting application. However, the Finance department has a lot of turnover, with people moving in and out of the department frequently. You need a solution that ensures that only current Finance employees can access the application, without requiring manual updates each time someone changes departments.
You decide to use a dynamic group. You create a new dynamic security group in Microsoft Entra ID called “Finance Users.” You then write a rule that adds members based on the department attribute: user.department -eq “Finance”. You save the rule, and within a few minutes, all users whose department attribute is set to “Finance” become members of the group. Then you assign the financial reporting application to this group. If a user named Sarah moves from Finance to Human Resources, the HR department updates her department attribute in the user directory to “Human Resources.” The dynamic group rule is automatically reevaluated. Sarah is removed from the “Finance Users” group, and she no longer has access to the financial reporting application. Similarly, if a new employee named Tom joins the Finance department, his department attribute is set to “Finance” during onboarding. He is automatically added to the group without any manual intervention. The group membership always matches the current Finance team, and access to the application is always correct. This saves IT hours of manual work every month and prevents security issues from stale group memberships.
Common Mistakes
Thinking dynamic groups can be nested inside other dynamic groups.
Microsoft Entra ID does not support nested dynamic groups. You cannot add a dynamic group as a member of another dynamic group. The membership rule only evaluates user or device attributes, not other group memberships.
If you need to create a group based on members of another group, use a manually assigned group or consider using a different approach like combining conditions in a single rule.
Assuming dynamic group membership updates instantly.
Dynamic group membership is not updated in real time. The evaluation process runs periodically, usually every few minutes, but it can take longer, especially in large tenants or during peak times.
Wait at least 30 minutes after changing a user attribute before checking membership. For immediate updates, you can manually trigger a recalculation using PowerShell or the Azure portal.
Using the wrong operator like == instead of -eq in the rule syntax.
The dynamic group rule syntax is not standard PowerShell. It uses specific operators like -eq, -ne, -startsWith, and -contains. Using == will cause the rule to fail validation or not work as expected.
Always use the correct operators as documented by Microsoft. For example, use -eq for equals, not ==. Use the Azure portal’s rule builder to avoid syntax errors.
Believing that dynamic groups can be used to assign roles in Azure RBAC.
Dynamic groups cannot be used as role-assignable groups for Azure RBAC. Only specific groups designated as ‘role-assignable’ can be assigned to Azure roles, and those groups must be manually assigned.
Use a manually assigned role-assignable group for Azure role assignments. Dynamic groups are best for licensing, security group membership, and conditional access policies.
Expecting dynamic groups to work with mail-enabled distribution groups.
Dynamic groups cannot be mail-enabled. They can only be security groups or Microsoft 365 groups. Mail-enabled groups must be created and managed separately.
If you need a dynamic email distribution list, you cannot use a dynamic group for that purpose. Instead, consider using a distribution group with manual membership or an alternative solution.
Exam Trap — Don't Get Fooled
{"trap":"The exam shows a scenario where a user is not being added to a dynamic group, and the trap attribute is showing the wrong attribute name, like using “City” instead of “city” or using “Department” with a capital D.","why_learners_choose_it":"Learners often assume that attribute names are case-insensitive or that they can be written in any format. They may also remember the concept but forget the exact syntax."
,"how_to_avoid_it":"Always use the exact attribute names as defined in the Microsoft documentation. The correct attribute is “department” (lowercase), not “Department.” Similarly, use “city”, “jobTitle”, etc.
Use the attribute picker in the Azure portal to avoid typos."
Step-by-Step Breakdown
Identify the business requirement
Determine what criteria should drive group membership. For example, you need all users from the Sales department to be in a group. This step ensures you build the right rule.
Create the dynamic group in Microsoft Entra ID
Go to the Azure portal, navigate to Groups, and choose “New group.” Select either “Security” or “Microsoft 365” as the group type. Then choose “Dynamic User” as the membership type. This step sets the foundation for automatic management.
Write the dynamic membership rule
Use the rule builder or manually enter the expression. For a simple rule, use: user.department -eq “Sales”. This expression tells the system to add any user whose department attribute equals “Sales” to the group. You can add more conditions using -and or -or.
Validate the rule syntax
Before saving, use the “Validate Rule” feature in the Azure portal to check that the rule is syntactically correct. This prevents errors that could cause the group not to populate. The validation also shows a sample of users who would be added.
Save the group and wait for processing
After saving, the group membership will be evaluated. Initially, it may take a few minutes to see members. Subsequent changes to user attributes will trigger reevaluation. This step ensures the group starts populating automatically.
Assign resources or policies to the group
Once the dynamic group has members, you can assign licenses, applications, or conditional access policies to the group. Because the group is dynamic, the assignments are automatically applied to the correct users as membership changes.
Practical Mini-Lesson
Dynamic groups are one of the most powerful tools for automating identity management in Microsoft 365 and Azure AD. In practice, a professional administrator uses dynamic groups to reduce manual work and improve security. The most common use case is license assignment. For example, you can create a dynamic group for all users in the Sales department and assign a Microsoft 365 E3 license to that group. When a new salesperson is hired, they are automatically added to the group and receive the license without any administrator action. When someone moves out of Sales, the license is automatically removed.
To configure this, you must first ensure that user attributes are populated correctly. In a hybrid environment, attributes like department, country, or jobTitle are often stored in on-premises Active Directory and synchronized to Azure AD via Azure AD Connect. If the attribute is not synchronized, the dynamic group will not work. Therefore, it is critical to verify that the attribute you plan to use is being synced and that values are consistent. For example, if some users have “Sales” and others have “Sales Department,” you may need to clean the data.
Another practical consideration is the rule complexity. Simple rules work best. If you try to create a rule with many conditions using -and and -or, it can become hard to debug. Always test the rule with a small set of users first. You can use the “Validate Rule” feature to see how many users will be added. If the number looks wrong, check the attribute values.
What can go wrong? One common issue is that the rule uses an attribute that is not populated for most users. For example, if you use the “country” attribute and it is blank for many users, those users will not be added. Another issue is that the rule uses a case-sensitive comparison. While -eq is case-insensitive, some operators like -startsWith are case-insensitive as well, but it is always safe to use consistent casing in your data. Another problem is that dynamic groups cannot be used for nested groups. If you try to add a dynamic group as a member of another group, it will not work.
Performance is also a consideration. For very large organizations with hundreds of thousands of users, dynamic group evaluation can take longer. Microsoft recommends keeping the number of dynamic groups under 5,000 per tenant and avoiding overly complex rules. Finally, remember that dynamic groups cannot be used for Azure role assignments. For that, you must use a manually assigned role-assignable group. Keep these practical points in mind when working with dynamic groups in production or in exam scenarios.
Memory Tip
Think of dynamic groups as “set and forget” groups: you set the rule once, and the group automatically keeps itself correct.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
An A record is a type of DNS resource record that maps a domain name to an IPv4 address.
Frequently Asked Questions
Can a dynamic group contain devices as well as users?
No, a dynamic group can be configured for either users or devices, but not both. You must choose the membership type when creating the group: “Dynamic User” or “Dynamic Device.”
How long does it take for a dynamic group to update after a user attribute changes?
Typically, the update happens within a few minutes, but it can take up to 30 minutes in large tenants or during peak times. You can force a manual recalculation using PowerShell or the Azure portal.
Can I use a dynamic group to assign an Azure RBAC role?
No, dynamic groups cannot be used for Azure RBAC role assignments. You need a manually assigned role-assignable group for that purpose.
What happens if a user’s attribute is missing or null?
If the attribute used in the rule is missing or null for a user, the user will not be added to the dynamic group. It is important to ensure that all users have the required attributes populated.
Can I create a dynamic group rule that uses multiple attributes?
Yes, you can combine multiple attributes using the -and and -or logical operators. For example, user.department -eq “Sales” -and user.country -eq “US”.
Is there a limit on the number of dynamic groups I can have in a tenant?
Yes, the maximum number of dynamic group rules per tenant is 5,000. If you need more, you may need to consolidate rules or use a different approach.
Summary
A dynamic group is a powerful feature in Microsoft Entra ID that automates group membership based on user or device attributes. Instead of manually adding and removing people, you write a rule, and the system does the rest. This automation saves time, reduces errors, and ensures that access to resources stays current with the organization’s structure. Dynamic groups are used for license assignment, conditional access policies, and managing access to applications. They are a staple for IT professionals who manage Microsoft 365 and Azure environments.
For certification exams like MS-102 and AZ-104, understanding dynamic groups is essential. You need to know when to use a dynamic group instead of an assigned group, how to write a correct rule, and how to troubleshoot issues like missing attributes or syncing delays. Common mistakes include trying to nest dynamic groups, using wrong syntax, or expecting instant updates. Remember that dynamic groups cannot be used for Azure role assignments and cannot be mail-enabled.
In the real world, mastering dynamic groups helps you build a responsive, automated identity governance system. It is one of the first steps toward reducing manual overhead in IT operations. Always ensure your user attributes are clean and consistent, and test rules before applying them broadly. With dynamic groups, you set the rule once, and the group maintains itself, giving you peace of mind and more time for other tasks.