Explanation:

Salesforce imposes strict governor limits to ensure efficient resource usage. In an environment with more than 2,000 lead records, an Apex transaction is likely to exceed the total number of records retrieved by SOQL queries, which is capped at 50,000 records per transaction.

Why Option C is Correct?

✅ SOQL queries in bulk transactions retrieve large data sets, potentially surpassing the record retrieval limit.
✅ If the query is not optimized, it might fetch more than the allowed number of records, triggering a limit error.
✅ Using pagination techniques or selective filters can help manage the retrieved record count efficiently.

Explanation:

Salesforce requires that triggers must have at least 1% code coverage to be deployed to a production environment. Even if a related class has high coverage, the trigger itself must be explicitly executed by a test method for deployment to succeed.

Why other options are incorrect:

B: Assertions are best practice but not required for deployment.

C: The overall code coverage of 75% is necessary, but every individual trigger must have at least 1% coverage.

D: Deployment includes both trigger and class, but lack of trigger coverage still causes failure.

To fix this, you must create a test method that actually causes the trigger to fire (e.g., inserting a Contact record).

Explanation:

Even though the test method directly calls MyClass.myStartMethod() and achieves 81% overall code coverage, the Apex trigger itself has no explicit coverage, meaning the deployment will fail.

Key Considerations for Deployment:

✅ Salesforce requires at least 75% code coverage for Apex classes and triggers.
✅ Triggers must have their own coverage—calling a method indirectly does not cover the trigger execution.
✅ Test methods must explicitly invoke the trigger logic to count toward the trigger's coverage.

Explanation:

Salesforce provides two ways to perform DML operations:

✅ DML statements (insert records) → If one record fails, the entire operation is rolled back.
✅ Database methods (Database.insert(records, false)) → Allows partial success, meaning successful records are inserted, while failed ones are skipped without rolling back the whole operation.

Why Database.insert(records, false) Works Best?

The second parameter (false) specifies that the operation should allow partial success.
Records that pass validation are inserted, while failing ones do not prevent other inserts.
The method returns a Database.SaveResult array, allowing developers to identify failed records and handle errors gracefully.

Explanation:

An Apex REST class allows real-time integration with external systems via HTTP callouts. In this case, the flow needs to dynamically retrieve order data from an external Order Management System at runtime, which is precisely what Apex REST classes enable. The class can make the callout, parse the response, and return the data to the flow.