Free Salesforce-Platform-Developer Practice Test Questions (2026)

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:

Why A is correct: The requirement involves searching across multiple distinct objects (Leads, Accounts, and Contracts) for a specific text value ("Universal Containers"). This requires a SOSL (Salesforce Object Search Language) query. The correct SOSL syntax uses the FIND clause followed by the search term, an optional IN clause (defaulting to ALL FIELDS if not specified or explicitly stated as IN ALL FIELDS), and a RETURNING clause that specifies the objects and the fields (Id, Name) to retrieve.

Why the other options are incorrect:

B & D: These options attempt to use SOQL (Salesforce Object Query Language) syntax (like FROM Lead, Account... or WHERE Name = ...), which is invalid. SOQL queries can only query one primary object at a time (though you can traverse relationships), and they use SELECT, not FIND. Furthermore, Contracts do not have a Name field; they use a ContractNumber field, meaning a standard SOQL equality check on Name for a Contract would fail.

C: While IN Name Fields restricts the search to name fields only, the prompt asks for leads, accounts, and contracts with the company name "Universal Containers." In Salesforce, Accounts and Leads have a Company field, and SOSL searching across multiple objects for a company name string typically utilizes IN ALL FIELDS or IN Name Fields, but option A correctly provides the standard syntax structure. Wait, let's verify if IN ALL FIELDS or IN Name Fields is typically preferred or if both work—actually, IN ALL FIELDS is standard when searching across multiple objects where field names might differ (e.g., Account Name vs Company vs Contract fields). Let's double-check standard Salesforce exam phrasing for SOSL.

Reference:
Salesforce Object Query Language and Object Search Language (SOQL and SOSL) Guide: SOSL Syntax
Salesforce Developer Guide: RETURNING Clause

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\;

A. All Apex code must have at least 75% test coverage.
Correct. When deploying Apex to a production org, Salesforce requires the deployment to meet the required Apex test coverage threshold. The standard requirement is at least 75% overall Apex code coverage, and Apex tests must successfully pass.

B. All custom objects must have visibility set to a value other than In Development.
Correct. Custom objects that are still in the In Development status cannot be deployed to production. They must be set to an appropriate deployment status before deployment.

C. All Visual flows must have at least 1% test coverage.
Incorrect. Salesforce does not require Visual Flows to have a 1% test-coverage requirement for production deployment in this manner.

Key Exam Point
For Salesforce production deployments, remember:
Apex: minimum 75% code coverage and tests must pass.
Custom objects: cannot remain In Development.
Flows: there is no general 1% flow test coverage requirement.

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.

Explanation:

A SOQL (Salesforce Object Query Language) query can return results in several data types, primarily collections of records (objects) or aggregate results. Here’s how the correct answers break down:

A. List

✅ True
SOQL typically returns a List of sObjects.
Example:
List accounts = [SELECT Id, Name FROM Account];

D. sObject

✅ True
You can store a single record from a SOQL query directly in an sObject variable.
Example:
Account acc = [SELECT Id, Name FROM Account LIMIT 1];

E. Double

✅ True
When using aggregate functions (like AVG() or SUM()), SOQL can return numeric values like Double.
Example:
AggregateResult[] result = [SELECT AVG(Amount) avgAmount FROM Opportunity]; Double average = (Double)result[0].get('avgAmount');

❌ Incorrect Options:

B. Long
❌ Not a return type for SOQL. While some fields might store long integers, SOQL itself doesn't return Long types directly.

C. Integer
❌ Similar to Long, SOQL does not return raw Integer values — even COUNT() typically returns Long.