Explanation:

Salesforce allows developers to override standard buttons like Edit with custom user interfaces, but the technology used depends on the UI experience:

✔️ For Salesforce Classic:

You can only override buttons using Visualforce pages.
Lightning components do not run in Classic.

✔️ For Lightning Experience:

You can override buttons with Lightning components (Aura or LWC).
This allows for modern, responsive UI.

🔧 Override Configuration:

When overriding the Edit button on the Contact object, Salesforce lets you specify:

A Visualforce Page for Classic
A Lightning Component for Lightning Experience

❌ Why other options are incorrect:

B. Lightning component in both Classic and Lightning
❌ Lightning components cannot run in Classic.

C. Visualforce page and Lightning page
❌ Lightning pages (App Builder pages) are not valid for button overrides.

D. Lightning page in Classic and Visualforce in Lightning
❌ Lightning pages don’t work in Classic, and Visualforce in Lightning defeats the purpose of a native Lightning experience.

Explanation:

The @TestSetup annotation is used in Apex test classes to define a method that creates test data that is shared across all test methods in the class.

Benefits:

Runs once before any @isTest methods in the class
Helps keep tests efficient and consistent
Prevents the need to duplicate record creation in each test method

🔍 Example:

@isTest
private class MyTestClass {

@testSetup
static void setupData() {
Account acc = new Account(Name='Test Account');
insert acc;
}

@isTest
static void testLogic() {
// Access shared data created in @TestSetup
Account acc = [SELECT Id FROM Account LIMIT 1];
// Assertions and logic testing
}
}

❌ Why other options are incorrect:

A. @BeforeTest
❌ Not a valid Apex annotation (confused with other languages like JUnit).

B. @isTest(SeeAllData=True)
❌ Allows access to real org data (not recommended)
Does not create test data or share it across test methods.

D. @PreTest
❌ Not a valid annotation in Apex.

Explanation:

To search across multiple objects (Lead, Account, Contact) where the name or company contains "Universal Containers", you should use SOSL (Salesforce Object Search Language), not SOQL.

✅ Why SOSL is appropriate:

SOSL allows searching across multiple objects in one query
It's ideal when you want to search text fields like Name or Company
Returns a list of lists, one per object

🔍 Breakdown of the correct syntax:

FIND 'Universal Containers'
IN Name Fields
RETURNING
Lead(Id, Name),
Account(Id, Name),
Contact(Id, Name)

FIND 'Universal Containers' — searches for this term
IN Name Fields — limits search to Name fields
RETURNING — specifies which objects and fields to return

❌ Why the other options are incorrect:

B. IN CompanyName Fields
❌ CompanyName is not a searchable field group in SOSL — use Name Fields.

C. SELECT FROM multiple objects in one SOQL
❌ SOQL does not support querying multiple unrelated objects in a single SELECT.

D. Invalid SOQL syntax with multiple objects and misused WHERE clause
❌ Mixing unrelated objects and incorrect field references.

Explanation:

When writing test classes in Apex, the goal is to ensure that all required test data is created or made available during the test execution. Let’s look at the two valid options:

✔️ A. Use a Test Data Factory class

✅ Recommended best practice

A Test Data Factory is a reusable class designed to create test data (e.g., 500 Pricing_Structure__c records).
It improves test reliability, readability, and maintainability.
Keeps test methods clean by separating data setup from test logic.

✔️ B. Use the @isTest(seeAllData=true) annotation

✅ Allows access to actual org data during test execution.
Can be used if 500+ Pricing_Structure__c records already exist and are too complex to replicate.
⚠️ Not recommended for managed packages or long-term maintainability, as it's not future-proof (data may change or be deleted).

❌ Incorrect Options:

C. Use the Test.loadData() method
❌ This option is not listed, but if you meant Test.loadData(), that could work only if a static .csv file is available.
However, Test.leadtear{} is not a valid Apex method — possibly a typo.

D. Use without sharing on the class declaration
❌ This affects record visibility, not data availability.
It allows access to records the running user doesn't own or have access to, but doesn't create or load data for tests.

Explanation:

To prevent editing Opportunities once they reach the "Closed" stage, the best solution is:

✅ Create a validation rule that prevents updates when StageName = 'Closed'
Validation rules allow you to enforce business logic and prevent specific changes based on field values or other conditions.

🔍 Example Validation Rule:

AND(
ISCHANGED(StageName),
ISPICKVAL(StageName, "Closed")
)

Or to prevent any edits once the Opportunity is closed:

You can also add exceptions if needed (e.g., allow system admins).

❌ Why other options are incorrect:

A. Use the Process Automation setting
❌ Not a valid Salesforce setting for field/edit restrictions.

B. Mark fields as read-only on the page layout
❌ Only affects the UI and can be bypassed via API or integration tools.

C. Use Flow Builder
❌ Flows are good for automation but not ideal for enforcing edit restrictions. You’d still need a validation rule or Apex.

Explanation:

Salesforce Deployment Requirements:

75% Test Coverage: Applies to all Apex code (including triggers, classes, and controllers) when deploying to production.
Triggers Are Apex Code: Triggers are not exempt; they must individually meet the 75% coverage threshold.

Why Not the Others?

A. 1% Trigger Coverage: False (Salesforce requires 75%).
D. Combined 75% Coverage: False (Each trigger and class must meet 75% individually).

Explanation:

To make an Apex method available for use in a Flow, it must be annotated with:

@InvocableMethod

This annotation exposes an Apex method to Flow Builder, allowing it to be called from record-triggered, screen, or autolaunched flows.

🔍 Example:

public class FlowValidationHelper {
@InvocableMethod
public static List validateData(List input) {
// Your complex validation logic here
}
}

❌ Why the other options are incorrect:

A. @future
❌ Used for asynchronous processing, not for exposing methods to flows.

B. @RemoteAction
❌ Used to expose methods to Visualforce and JavaScript, not flows.

D. @AuraEnabled
❌ Used to expose methods to Lightning components (Aura/LWC), not flows.

Explanation:

Salesforce provides several ways for developers to execute tests in an org. Here's a breakdown:

✔️ B. Tooling API

✅ True

The Tooling API supports running tests programmatically, often used by IDEs and CI tools.
You can execute specific test classes or methods and retrieve code coverage results.

✔️ C. Setup Menu

✅ True

Developers and admins can run Apex tests directly from Setup by navigating to:
Setup → Apex Test Execution

✔️ D. Salesforce DX (SFDX CLI)

✅ True

Salesforce DX provides the sfdx force:apex:test:run command to run tests from the command line.
Widely used in automated CI/CD pipelines.

❌ Incorrect Options:

A. Bulk API
❌ Not used for running Apex tests
Designed for importing, exporting, and deleting large volumes of data.

E. Metadata API
❌ Used for deploying and retrieving metadata
Cannot run tests directly, though tests are run as part of deployments.

Explanation:

A trace flag in Salesforce is used to enable debug logging for specific items. Here’s how the correct answers apply:

✔️ C. Apex Class

✅ True
You can set a trace flag for a specific Apex Class to debug its behavior and execution.

✔️ D. Apex Trigger

✅ True
You can enable a trace flag on a specific Apex Trigger to log its execution.

✔️ E. User

✅ True
This is the most common use — enabling a trace flag for a user captures all code run in their context (e.g., when testing something in the UI or running a flow).

❌ Incorrect Options:

A. Process Builder
❌ False
You cannot configure trace flags directly for Process Builder. However, if it triggers Apex code, that can be traced.

B. Visualforce
❌ False
You cannot directly set a trace flag for a Visualforce page. You would trace the user or Apex class involved.

Explanation:

In Salesforce, when you build custom Apex code (like a search tool), the Apex class by default does not enforce sharing rules unless explicitly stated. To ensure that users only see records they are allowed to see based on the org's sharing model (e.g., private sharing for Account), you need to declare the class with:

with sharing

This ensures the code respects record-level sharing rules for the currently logged-in user.

🛑 Why the other options are incorrect:

A. Use the schema describe calls to determine access to the Account object
❌ This checks object-level permissions, not record-level sharing.

B. Use the without sharing keyword
❌ This explicitly ignores sharing rules, which is the opposite of what's needed here.

C. Use the UserInfo class to filter queries
❌ Manually filtering by owner is not sufficient — users may have access to records via sharing rules, roles, or teams, not just ownership.

Explanation:

Given this custom exception declaration:

public class ParityException extends Exception {}

There are two valid ways to throw (fire) this exception in Apex:

✔️ B. throw new ParityException("parity does not match");

✅ Correct
You can pass a custom message to the exception constructor.
This message will be available via get Message().

✔️ D. throw new ParityException();

✅ Correct
You can throw the exception without passing any arguments.
This uses the default constructor.

❌ Incorrect Options:

A. new ParityException();
❌ Just instantiates the exception but does not throw it.

C. new ParityException('parity does not match');
❌ Similar to A — it creates the exception but does not throw it.

Explanation:

Here are the two correct use cases for executing Anonymous Apex:

Scheduling an Apex Class (B):

Anonymous Apex can schedule jobs using System.schedule().

Example:

System.schedule('Daily Update', '0 0 12 * * ?', new MyScheduledClass());

Running Batch Apex (C):

Anonymous Apex can launch batch jobs with Database.executeBatch().

Example:

Database.executeBatch(new UpdateContactsBatch(), 200);

Why Not the Others?

A. Deleting 15,000 Accounts in a single transaction:
Governor limit violation: Anonymous Apex has a 10,000-record DML limit. Use Batch Apex instead.

D. Adding unit test coverage:
Tests must be in test classes (@isTest). Anonymous Apex doesn’t count toward coverage.