Free Salesforce Platform Identity and Access Management Architect Practice Test Questions

Explanation:
NTO needs a partner portal with external IdP (Ping Identity) and one registration per partner to avoid duplicates. The solution must ensure the partner registers first in Experience Cloud, not directly in the IdP, so Salesforce can enforce uniqueness before the identity is propagated externally. The recommended pattern is IdP-initiated after local registration.

Correct Option:

A. Create a custom page in Experience Cloud to self register partner with Experience Cloud and Ping Identity store.
This allows NTO to enforce business rules (unique partner registration) within Salesforce before or while creating the identity in Ping. Experience Cloud self-registration can be extended to call Ping’s API to provision the external identity after Salesforce validation, preventing duplicates.

Incorrect Option:

B. On successful creation of Partners using Self Registration page in Experience Cloud, create Identity in Ping.
While similar to A, this option lacks the “custom page” aspect. Standard self-registration may not seamlessly trigger Ping user creation without customization. More importantly, option A explicitly includes the custom page needed for external IdP provisioning, making B incomplete and less precise.

C. Create a custom web page in the Portal and create users in the IdP and Experience Cloud using published APIs.
This reverses the flow. Creating the user in IdP first or simultaneously without Salesforce-first validation risks duplicates. Salesforce should be the system of record for partner uniqueness. Also, “Portal” is vague — Experience Cloud is the correct term.

D. Allow partners to register through the IdP and create partner users in Salesforce through an API.
This is IdP-initiated registration, which bypasses Salesforce’s duplicate prevention at the point of entry. By the time Salesforce receives the user via API, a duplicate might have already been created in the IdP, violating the “register only once” requirement.

Reference:
Salesforce Identity and Access Management Architect Guide — “External Identity Provider with Experience Cloud” and “Just-in-Time Provisioning vs. API Provisioning”; Trailhead: “Identity for Partners and Customers” module.

Explanation:
Universal Containers needs a B2C application with SSO using Salesforce Identity. For external consumers (not employees or partners), the appropriate license must support authentication, profile management, and social sign-on without requiring full CRM or community access. Salesforce offers specific Identity licenses for external users.

Correct Option:

C. External Identity
The External Identity license is designed specifically for B2C and external identity use cases. It allows unlimited external users to authenticate via Salesforce Identity, including SSO, social logins, and registration flows. Users get an identity record but no access to Salesforce CRM or Experience Cloud pages, making it cost-effective for pure authentication scenarios.

Incorrect Option:

A. Salesforce Platform
This license provides access to custom objects and apps but is intended for internal employees or partners building custom applications. It is not optimized for B2C SSO, has higher per-user costs, and includes platform access that external consumers do not need.

B. Partner Community
Partner Community licenses are for B2B scenarios where partners need access to cases, opportunities, or custom objects. They include Contact and Account relationships and are too expensive and feature-heavy for simple B2C SSO. Also, they require a partner account model.

D. Identity Only
This is a deprecated license from older Salesforce Identity offerings. The current recommended license for B2C SSO is External Identity. Identity Only is no longer available for new implementations and lacks modern features like social sign-on and progressive profiling.

Reference:

Salesforce Help Article: "External Identity License" – Learn about licenses for external users.

Salesforce Identity and Access Management Architect Guide – "Selecting the Right License Type for External Users."

Trailhead: "Get Started with Salesforce Identity for External Users" – Unit on External Identity vs. Community Licenses.

Explanation:
Dynamic branding in Experience Cloud allows different brands or sub-brands to display unique logos, colors, and content based on a URL parameter, without creating separate sites. This is useful when multiple partner or customer entities access the same Experience Cloud site but require distinct visual identities during and after login.

Correct Options:

B. To use dynamic branding, the community must be built with the Customer Account Portal template.
The Customer Account Portal template is specifically designed to support dynamic branding features. This template includes the necessary components and architecture to switch branding assets based on the account or URL parameter. Other templates like Partner Central or Tabs + Salesforce Tabs do not offer this capability natively.

D. An experience ID (expid) or placeholder parameter must be used in the URL to represent the brand.
Dynamic branding is triggered by adding an expid (experience ID) parameter or a custom placeholder in the Experience Cloud URL. This value maps to a specific brand configuration, enabling different logos, themes, and navigation menus. Without this parameter, the system cannot determine which brand to display.

Incorrect Options:

A. To use dynamic branding, the community must be built with the Audience + Salesforce Tabs template.
This template is designed for audience targeting and role-based content, not for dynamic branding. It does not support the expid parameter or brand switching. Dynamic branding is a feature of the Customer Account Portal template only, not the Audience template.

C. An external content management system (CMS) must be used for dynamic branding on Experience Cloud sites.
An external CMS is not required. Dynamic branding is handled natively within Experience Cloud using brand sets, themes, and the expid parameter. While an external CMS could theoretically be integrated, it is not a requirement and adds unnecessary complexity.

Reference:

Salesforce Help Article: "Add Dynamic Branding to Your Experience Cloud Site"

Trailhead: "Build Branded Experiences with Experience Cloud" – Unit on "Dynamic Branding"

Salesforce Architect Documentation: "Experience Cloud Dynamic Branding Implementation Guide"

Explanation:
For a mobile-first CIAM solution supporting email or mobile phone number as username, the primary license must cover external user authentication. Additionally, to verify mobile phone numbers during registration or login (e.g., one-time passcodes), SMS verification credits are required separately. Email verification is handled differently and does not require dedicated credits.

Correct Options:

A. External Identity Licenses
External Identity licenses are specifically designed for B2C/CIAM use cases. They allow external users to authenticate using Salesforce Identity features such as registration, login, social sign-on, and support for alternate usernames (email or phone number). These licenses do not include CRM or community access, making them cost-effective for pure authentication scenarios.

D. SMS Verification Credits
When users authenticate using a mobile phone number as username, one-time passcodes (OTP) via SMS are commonly used for verification. SMS Verification Credits are required to send these SMS messages through Salesforce's built-in verification service. Without these credits, SMS-based verification flows will fail.

Incorrect Options:

B. Email Verification Credits
Email verification is supported in Salesforce Identity without dedicated "credits." Email is sent using standard Salesforce email limits or External Identity license included email capabilities. There is no separate "Email Verification Credits" line item in Salesforce Identity pricing or architecture. This option does not exist as a required license.

C. Identity Connect Licenses
Identity Connect is used for Active Directory integration and provisioning between on-premises directories and Salesforce. It is irrelevant for pure cloud-based CIAM with email or phone as username. This license is for employee identity synchronization, not external consumer authentication.

Reference:

Salesforce Pricing Guide: "External Identity License – Includes SMS verification via credits"

Salesforce Help Article: "Set Up SMS Verification for External Users"

Trailhead: "Identity for Consumers (CIAM)" – Unit on "Verification Methods"

Explanation:
To enable self-registration using Person Accounts on an Experience Cloud B2C portal, Person Accounts must first be enabled org-wide. The self-registration flow must be configured to create Person Accounts instead of business accounts with separate contacts. This requires correct settings in Login & Registration and proper record type access for unauthenticated users.

Correct Options:

B. Enable person accounts in the Setup page.
Person Accounts are not enabled by default in Salesforce. The administrator must first enable Person Accounts under Company Information Settings. This is a prerequisite for any solution using Person Accounts, including B2C self-registration portals.

C. Under Login and Registration settings, ensure that the default account field is empty.
In Experience Cloud Login & Registration settings, the "Default Account" field must be empty when using Person Accounts. If a default business account is specified, the self-registration flow will create a Contact under that business account instead of a Person Account. Leaving it empty triggers Person Account creation.

D. Enable access to person and business account record types under Public Access Settings.
The Guest User profile (public access) needs access to both Person Account and Business Account record types. If Person Account record type is not enabled for the guest user, self-registration will fail because the flow cannot create a Person Account. Business account access is also required for potential mixed scenarios.

Incorrect Options:

A. Enable business accounts in the Setup page.
Business Accounts are always enabled in Salesforce by default. There is no specific "enable business accounts" step. This option is irrelevant and incorrect because enabling Person Accounts does not require toggling anything for business accounts.

E. Set organization-wide default sharing for Contact to Public Read Only.
Organization-wide sharing defaults for Contact are not directly related to Person Account self-registration. Person Accounts have their own sharing rules (Account object with Person Account flag). Setting Contact OWD to Public Read Only does not enable or disable registration flows.

Reference:

Salesforce Help Article: "Enable Person Accounts for Experience Cloud Self-Registration"

Trailhead: "Person Accounts for B2C Sites" – Unit on "Self-Registration Configuration"

Salesforce Architect Documentation: "Experience Cloud Registration with Person Accounts"