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.

• ✓

  Federation trust between the corporate identity provider and the SaaS provider.

  Why this is correct

  Federation trust is a technical relationship established between the corporate identity provider (IdP) and the SaaS provider's service (SP), often via standards like SAML 2.0 or OIDC. The SP relies on security assertions/tokens issued by the IdP, eliminating the need for separate accounts or passwords in the SaaS application. This enables centralized identity governance, immediate revocation when an employee leaves, and a single compliant authentication policy across all connected services.

• ✓

  Single sign-on so users authenticate once and reuse that session across apps.

  Why this is correct

  Single sign-on (SSO) is the user-facing authentication flow that allows an employee to sign in once at the corporate identity provider and automatically be authenticated to every trusted application. It works by passing a signed authentication token or session cookie to relying applications, so the user does not re-enter credentials for each SaaS app. While federation establishes the trust, SSO delivers the actual 'sign in once' experience that satisfies the requirement.

• ✗

  Shared generic accounts for each department.

  Why it's wrong here

  Creating a shared generic account for each department (e.g., a single 'sales@' login) would make every member of the department authenticate with identical credentials, destroying non-repudiation and auditability. It is impossible to tell which specific user performed a given action, which complicates incident response and compliance reporting. Additionally, password changes must be communicated to everyone, and when any user leaves, the shared password must be rotated and redistributed, making it both a security and an administrative burden.

• ✗

  Storing the same password inside every SaaS application.

  Why it's wrong here

  Storing the same password in every SaaS application forces users to use either a single weak password or a memorable one for all services, dramatically increasing the risk of credential stuffing and lateral compromise. If one SaaS provider is breached and hashes are cracked, the same password allows access to all other applications, including sensitive corporate data. This approach also violates the principle of least privilege and does nothing to address centralized authentication or account lifecycle management.

• ✗

  Disabling MFA so the sign-in process is faster.

  Why it's wrong here

  Disabling MFA is not only unnecessary for achieving single sign-on, but actively undermines security. SSO centralizes authentication at the identity provider, so an attacker who obtains a user's password gains access to every federated application at once. Keeping MFA enabled adds a strong, second-factor verification at the corporate IdP, protecting all downstream SaaS services from a single weak point without degrading the user experience.

Go deeper

Related to this question