Explanation:

- Validation Rules enforce business logic by ensuring data integrity before records are saved. They allow declarative enforcement of conditions without requiring code.
- Record-Triggered Flows automate business processes by executing logic when records are created, updated, or deleted. They provide a powerful declarative way to implement complex workflows without Apex.

❌ Why the other options are incorrect:
B. Remote Actions

❌ Imperative Apex code used for invoking controller methods from Visualforce
Not declarative

D. Batch Jobs

❌ Built using Apex code
Used for processing large volumes of data asynchronously
Not a declarative solution

Key Takeaways:

✅ Validation Rules (A) + Record-Triggered Flows (C) = 100% declarative business logic.
🚫 Remote Actions (B) and Batch Jobs (D) require code.

Explanation:

To enable a Lightning Web Component custom event to bubble up the containment hierarchy and cross the Shadow DOM boundary, the event's bubbles and composed properties must be set correctly.

bubbles: true: This property allows the event to bubble up through the DOM tree. If bubbles is false (the default), the event will not propagate beyond the component that dispatched it.
composed: true: This property allows the event to cross the Shadow DOM boundary. If composed is false (the default), the event will not pass outside the Shadow DOM of the component that dispatched it.
Therefore, to achieve both requirements (bubble up the containment hierarchy and cross the Shadow DOM boundary), both bubbles and composed must be set to true.

Explanation:

Correct Answer: C. A roll-up summary field on the Opportunity object
The requirement is to create a field, Total_Hours__c, on the Opportunity object that sums the Number_of_Hours__c values from all related Sales_Help_Request__c records, which have a lookup relationship to Opportunity. Option C is the most appropriate solution for the following reasons:

Roll-Up Summary Field Suitability: A roll-up summary field is a declarative feature in Salesforce designed to aggregate data (e.g., sum, count, min, max) from child records in a master-detail or lookup relationship to a parent record. Since Sales_Help_Request__c has a lookup relationship to Opportunity, a roll-up summary field on Opportunity can calculate the sum of Number_of_Hours__c from related Sales_Help_Request__c records.

Declarative Advantage: Using a roll-up summary field avoids custom code, reducing complexity and maintenance. It automatically updates the Total_Hours__c field whenever related Sales_Help_Request__c records are created, updated, or deleted.

Lookup Relationship Support: Salesforce supports roll-up summary fields for lookup relationships (in addition to master-detail relationships) for certain standard objects like Opportunity, making this a viable solution.

Why Other Options Are Incorrect:

Option A (Roll-up summary field on the Sales_Help_Request__c object):
A roll-up summary field is defined on the parent object (here, Opportunity), not the child object (Sales_Help_Request__c). Placing it on the child object would not allow aggregation of data to the parent.

Option B (Trigger on the Opportunity object):
A trigger could achieve the requirement by querying and summing Number_of_Hours__c from related Sales_Help_Request__c records, but it requires custom code and maintenance. A roll-up summary field is a simpler, declarative alternative.

Option D (Record-triggered flow on the Sales_Help_Request__c object):
A flow could update the Total_Hours__c field by calculating the sum, but it is more complex than a roll-up summary field and requires additional configuration, such as looping through related records and updating the parent.

Reference:
Salesforce documentation on Roll-Up Summary Fields confirms their use for aggregating data from child records in lookup relationships for objects like Opportunity.

Explanation:

To make a Lightning Web Component (statusComponent) available to be inserted into the Account record page, the developer needs to configure its statusComponent.js-meta.xml metadata file correctly.

The two things a developer should do are:

A. Add true to the statusComponent.js-meta.xml file.
The tag controls whether the component appears in the Lightning App Builder and other tools where it can be added to a page. It must be set to true for the component to be visible and usable.

B. Add lightning__RecordPage to the statusComponent.js-meta.xml file.
The element within the .js-meta.xml file specifies where the component can be used. To make it available on a record page (like the Account record page), you must include lightning__RecordPage as one of the targets. (Note: The option has a typo "lighting" instead of "lightning", but this is the intended correct target).

Explanation:

Option C: String.escapeSingleQuotes()

String query = 'SELECT Id FROM Account WHERE Name LIKE \'%' + String.escapeSingleQuotes(name) + '%\'';
List results = Database.query(query);

Why Safe?

String.escapeSingleQuotes() sanitizes the input by escaping single quotes (' → \').
Prevents attackers from breaking the query with malicious input (e.g., name = "test' OR Name != ''").

Option D: Bind Variable

String query = '%' + name + '%';
List results = [SELECT Id FROM Account WHERE Name LIKE :query];

Why Safe?
Bind variables (:query) are automatically escaped by Salesforce.
No string concatenation = no injection risk.

Why Not the Others?

Option A: Unsafe Concatenation

String query = 'SELECT Id FROM Account WHERE Name LIKE \'%' + name + '%\'';

Risk: Direct concatenation allows SOQL injection (e.g., if name = "test' OR Name != ''").

Option B: noQuotes() (Invalid Method)
String query = 'SELECT Id FROM Account WHERE Name LIKE \'%' + name.noQuotes() + '%\'';

Risk: noQuotes() doesn’t exist in Apex. Even if it did, it wouldn’t escape quotes.