SC-300 · Question #8
You need to configure the assignment of Azure AD licenses to the Litware users. The solution must meet the licensing requirements. What should you do? To answer, select the appropriate options in…
The correct answer is Azure AD Connect settings to modify:: Directory Extensions; Assign Azure AD licenses to:: An Azure Active Directory group that has the Dynamic User membership type. Hotspot Explanation: Azure AD License Assignment via Custom Attribute Background The core requirement: Litware added a custom on-premises AD attribute (LWLicenses) and wants users to be automatically added to a Microsoft 365 licensing group based on that attribute's value…
Question
Answer Area
- Azure AD Connect settings to modify:Directory ExtensionsDirectory ExtensionsDomain FilteringOptional Features
- Assign Azure AD licenses to:An Azure Active Directory group that has the Dynamic User membership typeAn Azure Active Directory group that has only nested groupsAn Azure Active Directory group that has the Assigned membership typeAn Azure Active Directory group that has the Dynamic User membership type
Explanation
Hotspot Explanation: Azure AD License Assignment via Custom Attribute
Background
The core requirement: Litware added a custom on-premises AD attribute (LWLicenses) and wants users to be automatically added to a Microsoft 365 licensing group based on that attribute's value.
Dropdown 1 - Azure AD Connect settings to modify
Correct: Directory Extensions
Why Directory Extensions is correct
LWLicenses is a custom attribute - it does not exist in the default Azure AD schema. By default, Azure AD Connect only syncs a predefined set of attributes. Directory Extensions lets you extend the Azure AD schema by syncing additional custom on-premises attributes to Azure AD, making LWLicenses available as an attribute on the cloud user object (e.g., extension_<appId>_LWLicenses). Without this, the attribute simply never reaches Azure AD.
Why the alternatives are wrong
| Option | Why it's wrong |
|---|---|
| Domain Filtering | Controls which domains are synchronized, not which attributes. Has no effect on attribute-level data. |
| Optional Features | Enables features like Password Hash Sync, Group Writeback, or Device Writeback - none of which address syncing a custom attribute. |
Dropdown 2 - Assign Azure AD licenses to
Correct: An Azure Active Directory group that has the Dynamic User membership type
Why Dynamic User membership is correct
The requirement says users must be added automatically based on the LWLicenses attribute value. Dynamic User groups evaluate a membership rule continuously and add/remove members automatically when attribute values change. You'd write a rule like:
user.extension_<appId>_LWLicenses -eq "E5"
When the on-premises attribute is updated and synced via AAD Connect + Directory Extensions, the user is automatically placed into the group - which carries the license assignment.
Why the alternatives are wrong
| Option | Why it's wrong |
|---|---|
| Assigned membership type | Requires manual addition of members. This violates the "automatically" requirement - an admin would need to update group membership every time an attribute changes. |
| Only nested groups | Azure AD group-based licensing does not support nested groups. License assignments only apply to direct members of the licensed group - nested group members are explicitly excluded from inheriting licenses. |
Key Technical Concepts
- Directory Extensions (AAD Connect): Extends Azure AD schema with custom on-premises attributes via the
Microsoft.InfrastructureDirectoryapp registration. - Dynamic User Groups: Membership rules are re-evaluated every 24 hours (or near-real-time on attribute change). They require Azure AD P1 licensing minimum.
- Group-Based Licensing: Licenses are assigned to a group; direct members inherit the license. Nested groups and the "Only nested groups" scenario are unsupported.
Topics
Community Discussion
No community discussion yet for this question.