SY0-701 Security Architecture Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use LDAP binds directly against each application and manage local passwords separately.

  Why it's wrong here

  Using LDAP binds directly against each application forces the SaaS to reach into your directory over LDAP, which many cloud vendors do not support natively and which exposes bind credentials across many services. It also leaves local passwords to be managed per application, creating credential sprawl and inconsistency, and offers no automated framework for provisioning or deprovisioning as employees join, move, or leave. While LDAP can serve as an internal authentication backbone, it is not designed for modern external SaaS and mobile clients.

• ✓

  Use OpenID Connect federation with OAuth 2.0 access tokens and SCIM provisioning.

  Why this is correct

  OpenID Connect (OIDC) provides a federated identity layer that supports both browser-based SSO through authorization code flows and native mobile app sign-in via PKCE, while OAuth 2.0 access tokens grant the SaaS apps scoped API access on behalf of the user. SCIM (System for Cross-domain Identity Management) automates the creation, update, and deactivation of user accounts in the SaaS applications, ensuring offboarding is immediate and no orphaned accounts linger. Together they give the organization centralized lifecycle control, strong authentication, and least-privilege API access, which is the modern standard for SaaS identity management.

• ✗

  Use shared local accounts in each application and sync passwords nightly from the directory.

  Why it's wrong here

  Creating shared local accounts in each application and syncing passwords nightly from the directory is deeply problematic: individual accountability is lost because multiple employees use the same credentials, and any password change may not propagate for up to 24 hours, leaving windows where former employees retain access. Nightly sync also creates a brittle, batch-oriented provisioning process that fails to support immediate deprovisioning or real-time lifecycle events, and password synchronization requires storing or transmitting joins that often violate security policy. This pattern is essentially a manual SSO workaround that introduces both security and operational risks.

• ✗

  Use Kerberos constrained delegation to each vendor tenant for every application.

  Why it's wrong here

  Kerberos constrained delegation relies on the internal Kerberos protocol and mutual trust between the service and the domain controller, which is almost impossible to establish with external vendor tenants because they are not joined to your Active Directory forest. Even if some vendors support Kerberos for SSO, it does not address API authorization or identity lifecycle automation, so you would still need a separate provisioning mechanism. This approach is also operationally complex and brittle in cloud/hybrid environments, where the identities and protocols are not native.