A compost-vendor app must create user accounts in its own directory when staff are assigned in Microsoft Entra ID. Which enterprise-application capability addresses that requirement, as distinct from OAuth permission grants?
Select an answer to reveal the explanation.
Short Explanation
Provisioning is the conveyor that creates users in the vendor’s directory when you assign them in Entra. OAuth grants are a different blade—those let the app call APIs, not mint accounts in the SaaS side.
Full Explanation
Enterprise applications can enable automated user provisioning to create, update, and disable accounts in the SaaS directory using SCIM or the app’s provisioning connector when users are assigned in Microsoft Entra ID. For the compost-vendor app that must create user accounts in its own directory when staff are assigned in Entra, configure automated user provisioning on the enterprise application for assigned users—distinct from merely granting OAuth permissions.
OAuth permission grants alone fail by concept: Graph consent authorizes API calls; it does not automatically provision accounts into every SaaS vendor directory. Application Proxy connectors fail: they broker on-premises application access, not SCIM provisioning into a vendor directory when users open My Apps. Azure AD Connect cloud sync rewriting on-premises OUs into the vendor’s SCIM endpoint misstates cloud sync’s purpose; customer cloud sync targets Entra, not arbitrary vendor SCIM as a substitute for the enterprise app’s provisioning feature.
Exam caveat: assignment + provisioning is a Domain 1 identity lifecycle pattern separate from OAuth consent. Operational check: enable provisioning, assign a test user, confirm the account appears in the vendor directory, remove assignment or disable the user per policy, and confirm deprovisioning behavior matches the municipal joiner-mover-leaver standard.