Explanation:
The requirement describes a many-to-many relationship between Contacts and Solar Projects (a Contact can relate to multiple Projects, and a Project can relate to multiple Contacts). In Salesforce, a many-to-many relationship is implemented using a Junction Object with two Master-Detail relationships—one to each parent object. This creates the intermediate "Contract" object (the text says "Contracts" but likely means "Contacts" based on context) to link the two.

Correct Option:

C. Two master-detail relationship on a new custom object
A new custom object (often called a Junction Object) with two Master-Detail relationships is the correct data modeling approach for a many-to-many relationship. One Master-Detail would point to the Contact object, and the other would point to the Solar Project object. This allows a Contact to be linked to multiple Projects (through multiple Junction records) and a Project to be linked to multiple Contacts. Additionally, this configuration enables roll-up summaries and cascade delete behavior.

Incorrect Option:

A. One Lookup relationship on Contact and one Lookup relationship on Solar Project
Placing separate Lookup fields directly on both objects does not properly model a many-to-many relationship. If you put a Lookup to Project on Contact, each Contact can only link to one Project. Similarly, a Lookup to Contact on Project only links to one Contact. This enforces a one-to-many relationship from each side, not the many-to-many requirement.

B. One Lookup relationship on a new custom object
A single Lookup relationship on a new object would only create a one-to-many relationship between that new object and either the Contact or the Project, but not both. To link both parents, you need two relationships (one to each parent). A single relationship does not establish the necessary connections to both objects for a many-to-many configuration.

D. One Master-Detail relationship on Contact and one Master-Detail relationship on Solar Project
This option is incorrectly phrased and conceptually flawed. You cannot place Master-Detail relationship fields directly on the Contact and Solar Project objects pointing to each other simultaneously. Master-Detail fields must reside on the child object (the Junction Object), not on the parent objects. This configuration would create a circular dependency and is not supported.

Reference:
Salesforce Help: "Create a Junction Object" – Trailhead Module: "Data Modeling" (Unit: "Create a Junction Object to Support a Many-to-Many Relationship"). Refer to the documentation on Master-Detail relationships and Junction Objects for implementing many-to-many data models.

Explanation:

This question tests understanding of Salesforce report types and report chart requirements. The requirement is to display a chart showing related Opportunities grouped by stage on the Account detail page. To generate charts with grouped data, Salesforce requires a summary or matrix report rather than a tabular report.

The key concept is that chart components rely on summarized report data, and the report must be based on the object containing the records being analyzed—in this case, Opportunities.

🟢 Correct Option:

C. A summary report on the Opportunity object
A summary report allows Opportunities to be grouped by Stage, enabling Salesforce to generate a meaningful chart for display on the Account record page. Since the chart needs to show Opportunity pipeline data by stage, the report must use the Opportunity object as its source and include grouped summary data compatible with report charts.

🔴 Incorrect Options:

A. A tabular report on the Opportunity object
Tabular reports display simple row-based data without grouping. Standard Salesforce report charts require grouped data, so a tabular Opportunity report cannot properly support a chart showing Opportunities by stage.

B. A tabular report on the Account object
This option uses the wrong report structure and focuses on the wrong object. The requirement is to analyze Opportunities by stage, which requires Opportunity-based grouped reporting rather than a basic Account tabular report.

D. A summary report on the Account object
Although summary reports support charts, the report should be built on the Opportunity object because the chart analyzes Opportunity stages. An Account-based report would not provide the most direct structure for Opportunity stage reporting.

🔧 Reference:
⇒ Salesforce Report Types Documentation
Explains differences between tabular and summary reports and when grouped reports are required.

⇒ Salesforce Report Charts Documentation
Confirms that report charts require grouped report data such as summary reports.

Explanation:

This question tests knowledge of where Lightning components (custom or from AppExchange) can be deployed and used in Salesforce. Lightning components are reusable building blocks. The Lightning App Builder is the primary tool for placing components on Record Pages, Home Pages, and App Pages. Additionally, Lightning components can be used in Quick Actions to provide custom modal interfaces for record creation or updates.

✔️ Correct Option (A): Lightning App Builder
The Lightning App Builder is the drag-and-drop interface used to design Lightning Pages (Record Pages, Home Pages, App Pages, and Utility Bar). AppExchange Lightning components can be added to any of these page types. This is the most common and primary area where Lightning components are used.

✔️ Correct Option (D): Quick Action
Lightning components can be used as custom Quick Action components. When a user clicks a Quick Action on a record, a Lightning component can launch in a modal window. This allows for custom data entry interfaces, screen flows, or complex interactions beyond standard actions.

❌ Incorrect Option (B): Time Failure
"Time Failure" is not a valid Salesforce feature, area, or component placement location. This appears to be a typo or a deliberately nonsensical distractor option. It has no relevance to Lightning component deployment.

❌ Incorrect Option (C): Validation Rule
Validation rules are text-based formulas written to enforce data quality (e.g., preventing a record save if a condition is met). They do not support Lightning components. Validation rules are purely logic statements, not UI elements or component containers.

🔧 Reference:
→ Salesforce Help: Add Components to Lightning Pages – Confirms that custom Lightning components (including AppExchange) can be added via Lightning App Builder.
→ Salesforce Help: Custom Quick Actions with Lightning Components – Confirms that Lightning components can be used in Quick Actions.

Explanation:

This question tests knowledge of the impact of converting a Master-Detail relationship to a Lookup relationship in Salesforce. Roll-up summary fields are exclusively supported in Master-Detail relationships. Converting the relationship type fundamentally changes how child records relate to the parent, directly affecting roll-up summaries and any reports dependent on them.

✔️ Correct Option:

B. Existing roll-up summary fields will be deleted from the Sun__c object and from any reports where they were added.
Roll-up summary fields only exist in Master-Detail relationships. When the relationship is converted to Lookup, Salesforce permanently deletes all roll-up summary fields from the parent object Sun__c. Any reports that previously included these fields will also lose those fields entirely, making this a critical consideration before making the conversion.

❌ Incorrect Options:

A. Existing reports created under the Sun__c with Planet__c report type made by Salesforce will be unusable, but not deleted.
This is partially misleading. The reports themselves may still exist, but the primary concern is the deletion of roll-up summary fields, not report usability. The report type between Sun__c and Planet__c can still function after conversion, as Lookup relationships also support cross-object reporting.

C. Existing roll-up summary fields will remain on the Sun__c object and available for reporting, but will no longer update.
This is incorrect. Salesforce does not retain roll-up summary fields after a Master-Detail to Lookup conversion. They are permanently deleted — not frozen or paused. Assuming they remain on the object would give a false sense of data continuity, which could cause reporting errors.

D. Existing reports created under the Sun__c with Planet__c report type made by Salesforce will be deleted.
This is incorrect. Converting a relationship type does not delete existing custom report types or reports built on them. The report type between the two objects remains intact. What gets deleted are the roll-up summary fields, not the reports or report types themselves.

🔧 Reference:
→ Salesforce Help – Considerations for Object Relationships
Confirms that converting Master-Detail to Lookup permanently deletes all roll-up summary fields from the parent object.

→ Salesforce Help – Roll-Up Summary Fields
Confirms that roll-up summary fields are exclusively supported in Master-Detail relationships and are removed upon conversion.

Explanation:

This question tests understanding of limitations and considerations when using Salesforce Process Builder (or similar processes) to update record ownership. The issue is that users aren't getting expected access to accounts and contacts, indicating problems with how ownership changes propagate through the system.

✔️ Option A (Correct):
When a process updates record owners, it does not automatically transfer associated child records (contacts, opportunities, contracts, etc.). This means if you transfer an Account owner but don't explicitly add actions to update child Contacts, those child records remain with their original owner. This creates an access mismatch where users have access to the parent but not the children, explaining why users aren't getting expected access levels. You must add separate Update Records actions for each child record type.

✔️ Option C (Correct):
Processes will fail on records owned by inactive users. When Salesforce tries to execute a process action like transferring ownership on a record owned by an inactive user, the process cannot complete successfully. When a user is deactivated, their records should be transferred to an active user first to avoid failed processes. This failure would prevent ownership updates from occurring, causing users to not receive expected access.

❌ Option B (Incorrect):
Processes do not use the first value when the Owner field is updated multiple times. When multiple field updates occur in a process, Salesforce handles them sequentially and the final value is applied. The limitation about "first value" is not accurate—this is a fabricated limitation that doesn't exist in Process Builder or Flow behavior.

❌ Option D (Incorrect):
While it's true that only the most recent active version of a process runs, this is standard behavior and not a specific consideration that would cause ownership transfer issues. This is basic process versioning knowledge, not a limitation related to record ownership changes. The issue described is about access problems after ownership updates, not about process activation status.

🔧 Reference:
→ Considerations for Processes That Update Records – Salesforce Help
Confirms that processes updating owners don't automatically transfer child records and processes can't update records owned by inactive users, requiring separate Update Records actions and active user ownership.