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.

• ✗

  Create a separate local username and password in every cloud application.

  Why it's wrong here

  Maintaining separate local credentials in every cloud application creates password sprawl and forces users to either memorize many passwords or reuse weak ones, increasing the likelihood of credential stuffing. It also fragments identity governance: deprovisioning a departing employee requires manually locating and disabling that identity in each app, which is slow, error-prone, and often incomplete. Because password complexity, rotation, and MFA policies cannot be enforced uniformly from a central point, the security posture becomes inconsistent across the SaaS estate.

• ✓

  Use federation with single sign-on from a central identity provider.

  Why this is correct

  Federation with SSO is the best option because employees authenticate once with the corporate identity provider and then access multiple applications through trusted token exchange. This reduces password sprawl, improves user convenience, and makes offboarding faster because disabling the central account removes access across connected services. It also supports stronger controls such as MFA at the identity provider rather than repeating them in every application.

• ✗

  Store the same shared password in a password manager for all applications.

  Why it's wrong here

  Reusing a single shared password across all applications via a password manager removes per-user accountability because every login appears as the same shared identity, rendering audit trails nearly useless. A single exposure of that common secret—through phishing, a data breach, or an insider—compromises every connected cloud service in one step, making targeted credential-stuffing attacks trivial. Since all users know the same secret, revoking access for one employee forces a jarring global password rotation across every application, disrupting the entire team, and this approach still provides no per-user MFA or step-up authentication.

• ✗

  Allow each application to authenticate users only by device MAC address.

  Why it's wrong here

  MAC addresses are unencrypted Layer 2 identifiers used only for devices on a local network segment; they are not transmitted to cloud applications across the internet and can be trivially spoofed with software, so the identity claim is unverifiable. MAC-based authentication ties access to a physical NIC, not to a human, meaning it cannot distinguish different users on a shared workstation or prove who is actually present. It also precludes strong authentication controls like MFA because a MAC address is static—it carries no secret, possession factor, or biometric evidence—making it a weak, low-assurance method unsuitable for remote SaaS access.

Go deeper

Related to this question