Explanation:

RBL rules allow administrators to calculate and display summary data (like total balances or counts) at the individual client or group/household level. The building blocks for these calculations are available for a specific set of industry objects:

Financial Accounts (B): This is the most common use case. RBLs calculate the "Total Bank Account Balance," "Investment Account Value," or "Total Outstanding Loans" by looking at all financial accounts related to a person or household.
Assets and Liabilities (C): RBLs can summarize non-financial account assets (like real estate or high-value collectibles) and liabilities (like external mortgages or credit card debt) to provide a complete picture of a client's net worth.
Claims (E): In the Insurance version of FSC, RBLs are used to aggregate data about insurance claims (e.g., total claim amount paid or count of open claims) to help agents understand a policyholder's history and risk profile.

Analysis of Incorrect Answers
A. Life Events:
Incorrect. Life Events (and Business Milestones) are used for visualization on a timeline. While they provide context, they do not hold numerical "balances" or "amounts" that typically require an RBL summary for financial aggregation.

D. Contacts:
Incorrect. In FSC, the Account (specifically the Person Account) is the "Parent" record where summary data is displayed. Contacts are part of the individual model, but the RBL logic pushes the calculated values to the Account object, not the Contact object.

References:
Salesforce Help: Rollup By Lookup Rules (Managed Package)
Salesforce Help: Financial Summary Rollup
Salesforce Ben: Data Processing Engine and RBL Rules

Explanation:

Why B is correct
In Financial Services Cloud, ownership and involvement in a Financial Account (for example, joint owner, beneficiary, or trustee) is modeled using Financial Account Roles. To support more than one joint owner, the recommended approach is to create additional Financial Account Role records, one per additional owner, and set the role appropriately (such as Joint Owner). This approach scales cleanly for any number of owners and aligns with Financial Services Cloud’s standard data model instead of customizing the Financial Account object with extra lookup fields.

Why the other options are incorrect

A ❌
This approach is incorrect because Financial Services Cloud is not intended to be hard-limited to only two owners in the way described. Even if the user interface highlights a Primary Owner and Joint Owner, the scalable and standard way to represent multiple involved parties is through Financial Account Roles rather than a fixed primary-plus-one pattern.

C ❌
The Actionable Relationship Center is primarily used for visualizing and navigating relationships, not for modeling account ownership. It does not replace the underlying data model objects used to store ownership and involvement relationships.

D ❌
Creating multiple lookup fields on the Financial Account for Owner 2, Owner 3, Owner 4, and so on is not recommended. This approach does not scale, complicates reporting and security, and deviates from Financial Services Cloud’s intended role-based relationship modeling using related records.

References:
Salesforce Help — Add a Financial Account Role (role examples include joint owner, beneficiary, and trustee; used to record a client’s involvement with a financial account)
Trailhead — Explore Financial Account Roles (financial accounts can have roles beyond a primary owner; roles define how involvement is tracked)

Explanation:

Option A (❌): Ask the business manager to review the file directly.
Incorrect. Business managers are not responsible for validating raw backup files. This is an admin responsibility to ensure data integrity and readiness for migration.

Option B (❌): Run manual backups for 2 weeks, then schedule weekly jobs.
Partially correct but not the best practice. Salesforce recommends daily backups initially to catch issues early, then moving to weekly cadence. Limiting to 2 weeks of manual runs is insufficient.

Option C (❌): Test via a data export request from sandbox to Sales Cloud UE org.
Incorrect. Data export requests are not performed from sandbox to production. Sandbox testing is useful for migration scripts, but this option misrepresents the process.

Option D (✅): Run daily backups for a week, then weekly until migration.
Correct. This aligns with Salesforce best practice:
Daily backups initially → ensures data consistency and catches anomalies.
Weekly backups thereafter → maintains fresh data snapshots until migration.
This cadence balances thoroughness with efficiency.

📚 Reference
Salesforce Help: Data Export Service
Salesforce Implementation Best Practices: Run daily exports initially, then weekly exports until migration to ensure data integrity.

Explanation:

Cumulus Bank wants to move away from manual spreadsheets and improve efficiency in gathering client data for mortgage applications. Financial Services Cloud provides industry-specific tools for mortgage processes in the Retail Banking Console.

The two recommended features are:

A. The standard mortgage flow templates to build a mortgage flow in Financial Services Cloud:
FSC includes prebuilt Mortgage Flow Templates (e.g., for New Mortgage Application, Mortgage Renewal, Refinance) that provide guided, step-by-step screen flows for collecting client financial data, property details, co-applicants, documents, etc. These templates are designed specifically for mortgage origination and can be customized or used out-of-the-box to replace spreadsheet-based data collection with a structured, compliant digital process.

B. Flow Builder to automate these business processes:
Using Flow Builder (specifically Screen Flows launched from the console), the bank can build or extend the mortgage flows to automate data gathering, validations, calculations (e.g., debt-to-income ratios), branching logic, and integration with subsequent steps (e.g., pre-approval, document requests). This directly improves efficiency by guiding bankers through the process and reducing manual entry/errors.

Together, these features enable a modern, automated mortgage application intake process within FSC.

Why not the others?

C: Creating a custom "Mortgage Application" object might be part of a fully custom solution, but FSC already provides standard objects (e.g., Financial Accounts with Mortgage record types, Loan Application custom object in some extensions) and prebuilt flows—reinventing this is not recommended.

D: Data Import Wizard helps with one-time uploads but does nothing to improve the ongoing efficiency of the data collection process—it perpetuates spreadsheet dependency.

References:
Salesforce Trailhead: "Mortgage Processes in Financial Services Cloud" (covers using standard mortgage flow templates and Flow Builder for guided application intake).
FSC Help Documentation: Retail Banking Console includes prebuilt Mortgage Flow Templates for application data collection.
Accredited Professional exam resources: Common scenario recommending standard mortgage flow templates + Flow Builder to replace manual/spreadsheet processes.

Explanation:

The scenario requires a standard industry solution for tracking deals securely and taking shareable, compliant notes.

A. Financial Deal Management: This is the core FSC feature built on top of the standard Salesforce Opportunity object. It provides industry-specific fields and deal team roles necessary for managing an investment banking pipeline and managing the associated team members.

C. Compliant Data Sharing (CDS): This feature is crucial for maintaining confidentiality in sensitive environments like investment banking, where data access must be tightly controlled (often implementing "Chinese Walls"). CDS allows administrators to easily manage complex sharing requirements based on explicit team membership or specific object relationships, ensuring only approved deal team members can view the confidential records, overriding standard organization-wide defaults if necessary.

E. Interaction Summaries: These are structured notes specific to FSC. They are designed for financial professionals to quickly capture client interactions (meetings, calls). Critically, they are easily shareable with other members of the deal team and are built with compliance tracking in mind, allowing the "taking and sharing notes directly within Salesforce with others on the team."

Why others are incorrect:
B. Sharing Rules: Standard sharing rules are a core Salesforce mechanism, but Compliant Data Sharing (C) is the FSC-specific abstraction built precisely for the complex, dynamic team-based sharing described in the scenario, making C the more precise FSC answer.

D. Profiles: Profiles define the base level of object access and user permissions (like "can a user edit any opportunity?"), but they don't dynamically manage the record-level visibility of confidential deals on a deal-by-deal basis among specific team members. This is managed by sharing mechanisms like CDS.

Reference
Financial Deal Management: Salesforce Help: Manage Commercial and Investment Banking Deals
Compliant Data Sharing: Salesforce Help: Understand Compliant Data Sharing
Interaction Summaries: Salesforce Help: Create an Interaction Summary