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 shared portal accounts and distribute credentials to the partner's staff.

  Why it's wrong here

  Creating shared portal accounts removes the ability to attribute actions to a specific individual, severely weakening audit trails and non-repudiation for procurement transactions. Because credentials are shared, the manufacturer cannot enforce per-user least-privilege or revoke access for a single partner employee, and any compromise or misuse cannot be traced. This approach also violates common compliance frameworks such as SOX or NIST 800-53 that require unique identification and accountability.

• ✓

  Federate access with the partner's identity provider and map claims or attributes to portal roles.

  Why this is correct

  Federation lets the partner authenticate its own users while the manufacturer trusts identity assertions from the partner identity provider. Claims or attributes can then be mapped to portal roles so access stays controlled without local password management. This is a strong fit for business-to-business access because it preserves administrative separation while still supporting centralized authorization decisions in the portal.

• ✗

  Issue one VPN account for the partner organization and let them share it internally.

  Why it's wrong here

  A single VPN account is a network-layer access mechanism, not an application authorization model, and sharing it gives the entire partner organization a persistent foothold inside the manufacturer's network. VPN access exposes the internal network to lateral movement and pivoting, while the procurement portal's role-based controls are bypassed because everyone appears as the same VPN user. It also creates a critical blind spot for security monitoring and incident response, as there is no per-user session attribution for application activity.

• ✗

  Require each partner user to create a password directly in the procurement portal.

  Why it's wrong here

  Requiring partner employees to register passwords directly in the procurement portal forces the manufacturer to operate a second identity silo instead of leveraging the partner's existing identity infrastructure. This shifts identity lifecycle management—joiner, mover, leaver—onto the manufacturer, so terminated partner users may retain stale credentials for months, creating an orphaned account risk. It also prevents the manufacturer from enforcing its own password, MFA, and conditional access policies, and users are burdened with yet another credential to remember.

Go deeper

Related to this question