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.

• ✓

  Federate authentication to a central identity provider.

  Why this is correct

  Federation allows the organization to centralize authentication and give users a single identity across multiple SaaS applications. That is the architectural foundation for single sign-on because the SaaS apps trust the central identity provider instead of storing separate credentials. It also makes access governance easier because one identity system can enforce stronger controls and lifecycle management.

• ✓

  Enable conditional access policies based on device posture and sign-in risk.

  Why this is correct

  Conditional access is the right control for adapting access decisions based on context. If the device is unmanaged or the location is unusual, the policy can require additional verification, limit session duration, or block access entirely. This provides a dynamic security layer that supports the business goal without forcing the same treatment for every login.

• ✗

  Create separate passwords for each SaaS app so compromise is contained.

  Why it's wrong here

  Separate passwords may reduce reuse, but they do not meet the single sign-on requirement and create more help desk burden. Users would still face password fatigue, and the organization would struggle to enforce consistent access policy across apps. The scenario calls for centralized identity, not more isolated password silos.

• ✗

  Turn off MFA because single sign-on already reduces logins.

  Why it's wrong here

  Reducing the number of logins does not replace multifactor authentication. SSO improves usability, but it also means the central identity becomes even more important to protect. MFA should remain in place, especially when conditional access may identify higher-risk sign-in events that deserve stronger verification.

• ✗

  Use shared generic accounts for contractors to simplify onboarding.

  Why it's wrong here

  Using shared generic accounts undermines the security team's requirement for individual user verification and conditional access. This approach prevents applying extra verification based on specific users, their devices, or locations, as accountability is lost and unique identity signals cannot be evaluated. While tempting for simplifying onboarding and offboarding, especially for temporary contractors needing only basic, non-auditable access to a single resource, it fundamentally conflicts with the need for granular security controls and individual identity management central to the scenario's demands.