Explanation:

✅ Correct statements about the Actionable Relationship Center (ARC)

A. To enable users to see the ARC, you will need to add the component for ARC to the page layout. ✅
ARC is a Lightning component.
An admin must add the Actionable Relationship Center component to the appropriate Lightning Record Page (Account/Person Account) for users to access it.
Without placing the component on the page, users won’t see ARC even if they have permissions.

C. ARC is certified to work with Person Accounts and Individual Accounts. ✅
ARC fully supports Person Accounts, which are heavily used in FSC to represent individual clients.
This is critical for retail banking, wealth, and investment use cases.
This statement is explicitly called out in FSC documentation and Trailhead modules.

E. The Association Type picklist controls the account-account relationships that display in the ARC. ✅
Association Type defines how two accounts are related (for example, affiliate, subsidiary, peer).
ARC uses these Association Type values to determine:
Which relationships appear
How they are grouped and displayed
This makes Association Type configuration exam-relevant.

❌ Why the other options are incorrect
B. ARC displays up to 5 related lists that have a configured compact layout ❌
This description applies to Dynamic Related Lists or certain Lightning UI components.
ARC does not rely on compact layouts or a fixed number of related lists.

D. The Salesforce Admin has to create a permission set for granting access to the ARC ❌
ARC access is controlled through standard FSC permission sets provided by Salesforce.
Admins do not need to create a custom permission set just to enable ARC (though they may extend permissions if desired).

📌 Exam takeaway
Remember these ARC fundamentals:
ARC = Lightning component → must be added to the page
Works with Person Accounts
Uses Association Type to drive relationship visibility

Explanation:

The Actionable Relationship Center (ARC) provides a flexible visualization for showing how different types of accounts relate to each other in a client's network. The supported standard types for Account-to-Account mapping include:

A. Accounts & Businesses: This allows you to map how a client's primary account (usually a Person Account or Household Account) relates to a business account they own or are associated with (e.g., the client's household owns "Smith's Shoes" business account).

C. Accounts & Peers: This relationship type is used to map connections to other similar accounts within the network, such as a client's relationship with another individual client or business that serves a similar function (e.g., two different trust accounts that are related).

D. Accounts & Groups: This is primarily used to map an individual account (Person Account) to their primary Household group account. It visually demonstrates the hierarchical relationship within family structures.

Why the other options are incorrect:
B. Accounts & Members: While "Members" is a concept related to group membership, "Accounts & Members" is not a standard configuration option or label used within the ARC configuration wizard for defining relationship types. The functionality is covered by "Accounts & Groups" using the Group Members component.

Explanation:
Financial Services Cloud is delivered via a managed package (core features: custom objects like Financial Account and Group/Household Accounts, predefined list views, profiles, etc.) and several unmanaged extension packages (customizable components that can be modified).

C. Field sets that configure how fields display in the client and household profiles: Provided in the core unmanaged extension package to control field visibility and order on Lightning record pages for Individual (client) and Group (household) records.

B. The Commercial Banking dashboard: Included in the unmanaged Commercial Banking extension package for out-of-the-box analytics tailored to commercial banking users.

A is incorrect because core custom objects (Financial Account, etc.) and householding are in the managed package.
D is incorrect because predefined list views (e.g., All Clients, All Households) are part of the managed package.

References:
Salesforce Financial Services Cloud Installation Guide (Winter '26): Managed package includes custom objects and list views; unmanaged extension provides field sets for profiles. Separate unmanaged commercial banking extension provides the commercial banking dashboard.
FSC Admin Help: Install multiple unmanaged extension packages for full sector-specific features like dashboards.

Explanation
Option A (✅) Interaction Summary Participant
Correct. This object links an Interaction Summary to the participants (clients, advisors, specialists). It ensures that engagement notes are tied to the right people and can be shared across business lines.

Option B (❌) Financial Deal Participant
Incorrect. This object is used in Financial Deal Management (investment banking deals), not for Interaction Summaries.

Option C (✅) Participant Role
Correct. Defines the role of each participant in the interaction (e.g., client, banker, specialist). This is essential for clarifying responsibilities when sharing call logs.

Option D (✅) Interaction Participant
Correct. Represents the individuals involved in the interaction. Specialists from other lines of business can be added here to collaborate on deals.

Option E (❌) Opportunity Participant
Incorrect. Opportunity Participants are tied to Sales/Opportunity records, not Interaction Summaries.

📚 Reference
Salesforce Help: Interaction Summaries in Financial Services Cloud
FSC Data Model Guide: Interaction Summaries rely on Interaction Participant, Interaction Summary Participant, and Participant Role to track and share engagement details.

📝 Key Takeaway
For Interaction Summaries in FSC:
Use Interaction Summary Participant to link summaries to people.
Use Interaction Participant to represent individuals in the engagement.
Use Participant Role to define their role (advisor, specialist, client).

Explanation:

The requirement is to use Interaction Summaries to log engagements and share those summaries with various specialists via specific roles. The Interaction Summary functionality relies on a data model designed for compliant and structured engagement tracking.

A. Interaction Summary Participant: This is a key object in the FSC data model that links a User, Contact, or Person Account to the main Interaction Summary record. This fulfills the requirement to specify who attended the meeting or participated in the engagement.

C. Participant Role: This object works in conjunction with the participant objects (A and D). It defines what the person's role was during the engagement (e.g., "Internal Attendee," "Client," "Legal Counsel," "Specialist"). Defining these roles is crucial for filtering and determining who the notes apply to or should be shared with.

D. Interaction Participant: This object is often used interchangeably with (A) in the documentation, as both link individuals to the engagement. The Interaction Participant object specifically stores the details of internal and external people involved in the interaction event. When used with Compliant Data Sharing (CDS) features, it allows the bank to manage visibility of these sensitive notes to only those participants or related specialists.

Why the other options are incorrect
B. Financial Deal Participant: This is not a standard FSC object name for tracking general client engagements or interaction summaries. Participation in deals is usually tracked via standard Opportunity Contact Roles or custom objects related to specific deal management features.

E. Opportunity Participant: Similar to option B, participation roles might exist on the Opportunity object, but they are specific to the sales cycle (opportunity stages) and do not natively link to the general Interaction Summary object used for day-to-day call logging as described in the scenario.