Explanation:

To create a form that:

Lets users input data for a Contact record (including a custom Salary__c field),
Automatically renders currency formatting for a Currency field, and
Respects field-level security (FLS) (so only users with access can view or edit it),
You should use the component inside a .

Why C is correct:

automatically determines the field type (like Currency for Salary__c) and renders the appropriate input UI.
It also respects FLS — users without view or edit permission won’t see or be able to change the field.
It’s the recommended way to include fields in lightning-record-edit-form.

The other options (A, B, D):

Likely involve either manual input fields like or custom logic, which:

Do not automatically respect FLS, and
Require extra work to validate and submit data properly.

Explanation:

When multiple objects use the same picklist values (e.g., 'High', 'Medium', 'Low'), the best practice is to:

Define the values once in a Global Picklist Value Set, and
Reference it when creating picklist fields on different objects.
This makes it easier to manage and update values centrally, while also restricting entries to just the predefined list.

Why the other options are incorrect:

B. Alphabetical display setting – Only affects the order of display, not maintenance or restrictions.
C. "Restrict picklist to values defined in value set" – This is good practice, but without using a Global Value Set, you’d have to maintain values separately on each object.
D. Validation rule to ensure data integrity – Not efficient or scalable; better handled with restricted picklists and value sets.

Explanation:

When inserting records in Apex, using Database.insert(records, false) with allOrNone=false allows partial success:

Successful records are committed,
Failed records are skipped,
No unhandled exceptions are thrown.

This prevents the entire transaction from failing, which helps ensure that external integrations (like the one reading Task records) aren’t disrupted by rare insert failures in the trigger.

Explanation:

Salesforce operates in a multitenant architecture, meaning multiple organizations share the same infrastructure. To ensure fair resource distribution and prevent individual tenants from monopolizing system resources, Salesforce imposes governor limits, including constraints on database queries.

Governor Limit on SOQL Queries: Apex allows a maximum of 50,000 records to be retrieved per transaction.
If a query exceeds this limit, it throws an exception, preventing excessive database resource consumption.

Explanation:

The current code performs a SOQL query inside a loop, which can easily exceed the governor limit of 100 queries per transaction. This is a common anti-pattern in Apex.

Refactor to use a single SOQL query
The best practice is to bulkify the code by querying all OpportunityLineItems in one SOQL statement using the IN keyword:

public class without sharing OpportunityService {
public static List getOpportunityProducts(Set opportunityIds) {
return [SELECT Id FROM OpportunityLineItem WHERE OpportunityId IN :opportunityIds];
}
}

This approach uses 1 SOQL query, regardless of how many Opportunity IDs are passed in.
It ensures governor limits are not exceeded, even in bulk operations.

Why the other options are incorrect:

A. Use System.Limits.getQueries()
This checks how many queries have been used, but doesn't prevent the issue—just monitors it.

B. Use System.Limits.getLimitQueries()
This gives the total limit (typically 100), but again, doesn’t avoid SOQL-in-loop problems.

C. Limit logic to Sets with <100 IDs
This doesn't help. Even with <100 IDs, if you run 1 SOQL per ID, you still risk hitting the limit in other parts of the transaction.