The city must federate Workspace ONE Access to a statewide Microsoft Entra ID tenant using SAML. Which configuration is correct?
Select an answer to reveal the explanation.
Short Explanation
SAML federation is a handshake between Access and the state’s Entra tenant—you add Entra as a third-party IdP, you do not bulldoze UEM to get SSO. Sensor groups and NSX LDAP are the wrong cabinets for IdP metadata.
Full Explanation
The city must federate Workspace ONE Access to a statewide Microsoft Entra ID tenant using SAML. Add Entra ID as a third-party SAML identity provider on Workspace ONE Access—a handshake between Access and the state’s Entra tenant, not bulldozing UEM to get SSO. Replacing Workspace ONE UEM enrollment with Entra join and deleting Access fails by concept because federation for Access SSO does not require deleting Access or replacing UEM enrollment wholesale. Storing Entra SAML certificates only in Carbon Black Cloud sensor groups fails because sensor groups are not IdP metadata stores for Access SAML. Publishing the Entra tenant as an NSX-T LDAP identity source for Access logins fails because NSX LDAP sources are not how Access consumes Entra SAML federation. Exam caveat: Entra SAML federation is configured as a third-party SAML IdP on Access—not delete Access/UEM, not CBC cert storage, not NSX LDAP as SAML. Operational check: add Entra as SAML IdP with metadata and certs, test a city user login via statewide Entra, confirm UEM enrollment remains intact, and store metadata refresh procedures. Calendar certificate and metadata expiry for the statewide IdP so city login does not fail on rotation day.