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

Explanation:

📌 Requirements Recap:
Mobile devices: Show three rows (i.e., each item spans full width: size="12").

Desktops and tablets: Show a single row (i.e., each item should span 4 columns out of 12, so 3 items side-by-side).

✅ Why Option A Is Correct:

In Option A, each includes:

lightning:layoutitem size="12" mediumdevicesize="4" largedevicesize="4"

size="12" → Full width on mobile (3 rows ✅)

mediumDeviceSize="4" and largeDeviceSize="4" → One-third width on tablets/desktops (3 items in 1 row ✅)
This meets both requirements perfectly.

❌ Why the Others Are Incorrect:

Option B: Uses size="12" for all devices → All items show as full-width on all screen sizes (3 rows everywhere ❌)

Option C: Only sets largeDeviceSize="4" and omits mediumDeviceSize → Works on desktop, but not tablets (tablets still show 3 rows ❌)

Option D: Has incorrect nesting and inconsistent sizing logic — it's also not semantically clean and fails to guarantee both requirements ❌

Reference:
Salesforce Lightning Layout Documentation

Explanation:

Universal Containers has set the organization-wide defaults (OWD) for the custom Candidate object to Private, meaning only the record owner and users with higher access (e.g., via roles, sharing rules, or manual sharing) can view the records. A lookup field on the Candidate object links to an Employee (assumed to be a User record) as an Interviewer. The requirement is to automatically grant Read access to the Candidate record when the Interviewer lookup field is set to a specific user. Let’s evaluate the options:

Option A: The record can be shared using an Apex class. While Apex can be used to create sharing records (e.g., via the CandidateShare object for a custom object), this approach requires custom code to detect when the Interviewer lookup field is updated and programmatically insert a sharing record. This is not an automatic, declarative solution and involves manual development, testing, and maintenance. It is less efficient than using built-in Salesforce features like sharing rules.

Option B: The record can be shared using a permission set. Permission sets grant additional permissions to users, such as object-level access (e.g., Read, Create) or field-level access. However, permission sets do not dynamically share individual records based on field values (e.g., the Interviewer lookup). They provide broad access to all records of an object for users assigned the permission set, which does not meet the requirement of automatically sharing a specific Candidate record with the Interviewer user.

Option C: The record can be shared using a sharing rule. Sharing rules are a declarative way to extend access to records based on criteria or ownership. A criteria-based sharing rule can be created for the Candidate object to grant Read access to users specified in the Interviewer lookup field. For example, the rule can be configured to share the record with the user whose ID matches the Interviewer field value whenever it is populated. This automates the sharing process without requiring code, making it the most appropriate solution given the Private OWD and the need for dynamic access.

Option D: The record cannot be shared with the current setup. This is incorrect because Salesforce provides mechanisms like sharing rules to extend access beyond the Private OWD. The lookup field to the Interviewer (User) allows for criteria-based sharing, enabling automatic Read access when the field is set.

Why Option C is Best:
With OWD set to Private, sharing rules are the standard Salesforce feature to automatically grant access to records based on field values or other criteria. A criteria-based sharing rule can evaluate the Interviewer lookup field and share the Candidate record with that user, ensuring Read access is granted dynamically. This aligns with Salesforce’s security model and avoids the complexity of custom Apex code.

Implementation Notes:
Create a criteria-based sharing rule on the Candidate object.
Set the criteria to match records where the Interviewer field is not null.
Grant Read access to the users specified in the Interviewer field.
Ensure the rule is active and tested to confirm access is applied correctly.

References:
1. Salesforce Documentation - Sharing Rules:
Explains how to use criteria-based sharing rules to extend access based on field values.

2. Salesforce Documentation - Organization-Wide Defaults:
Details how OWD interacts with sharing rules to control record access.

3. Salesforce Platform Developer II Study Guide:
Covers security and sharing models, including the use of sharing rules for dynamic access control.

Explanation:

📌 Scenario Summary:
The Visualforce page worked in a developer sandbox but is causing view state errors in production.
This points to issues with too much data being stored in the view state, which exceeds Salesforce’s view state size limit (170 KB).

✅ Why Option C Is Correct:
"Ensure variables are marked as transient."
In Visualforce controllers, non-transient instance variables are automatically included in the view state, even if they are large or not needed after the initial page load.
By using the transient keyword, the developer can prevent temporary or large variables from being serialized into the view state.

💡 Example:
public class MyController {
public String name; // Stored in view state
transient public List accList; // NOT stored in view state
}

This reduces the view state size and prevents view state errors.

❌ Why the Other Options Are Incorrect:

A. Ensure queries do not exceed governor limits
Important for Apex performance, but unrelated to view state issues.
View state errors are about data size, not SOQL execution limits.

B. Ensure properties are marked as private
Private vs. public properties affect accessibility but not view state inclusion.
Even private properties can be included in view state if they are non-transient.

D. Ensure profiles have access to the Visualforce page
This would result in authorization errors, not view state errors.
Completely unrelated to the error described.

📚 Reference:
Salesforce Developer - Introducing Visualforce
Using Transient Keyword

Explanation:

The developer has built an Aura component for guests to self-register at a front desk kiosk and now needs to create a utility tray component to alert users (e.g., front desk staff) whenever a guest arrives. This requires communication between components, likely across different parts of the application, to notify users of the guest registration event. Let’s evaluate the options:

Option A: DML Operation A Data Manipulation Language (DML) operation (e.g., insert, update) is used to modify data in Salesforce, such as saving a guest’s registration details. While DML might be part of the self-registration process, it is not a mechanism for alerting or notifying users via a utility tray component. This option is incorrect for the purpose of event notification.

Option B: Changelog A changelog typically refers to tracking changes to records (e.g., via Field History Tracking or a custom solution), but it is not designed for real-time notifications or communication between components. It serves as a historical record rather than an active alerting mechanism, making this option unsuitable.

Option C: Application Event In the Aura framework, an application event is used to communicate between components across the entire application, regardless of their position in the component hierarchy. When a guest self-registers, the registration component can fire an application event to signal the arrival. The utility tray component, designed to alert users, can be configured to handle this event and display the alert. This is the appropriate choice for broadcasting the guest arrival notification to all relevant parts of the application, including the utility tray.

Option D: Component Event A component event is used for communication between components that have a parent-child relationship within the same hierarchy. Since the utility tray (likely a global component) and the self-registration component (likely a specific page component) may not be directly related in the component tree, a component event is not suitable. Application events are better suited for cross-application notifications.

Why Option C is Best:
The requirement involves alerting users via a utility tray component whenever a guest arrives, which implies a need for a global notification mechanism. An application event allows the self-registration component to broadcast the guest arrival event, and the utility tray component can listen for and respond to this event by displaying an alert. This aligns with Aura’s event-driven architecture for inter-component communication across the application.

Implementation Notes:
Define an application event (e.g., guestArrivalEvent) in the Aura framework.
Fire the event from the self-registration component when a guest registers.
Register the utility tray component to handle the event and trigger the alert (e.g., show a toast or update the UI).

References:
1. Salesforce Documentation - Application Events in Aura:
Application Events
Explains how application events enable communication across the application.

2. Salesforce Documentation - Component Events in Aura:
Component Events
Contrasts component events with application events, highlighting their use cases.

Explanation:

📌 Scenario Summary:

Trigger Point: When Account records are saved
Requirement: Send each Account to an external RESTful web service
Constraint: Web service only accepts one record per call
Consideration: Must perform a callout (HTTP request) from Apex

✅ Why Option D is Correct:

"Create a future method."
Future methods are designed for asynchronous processing and are one of the few ways you can make callouts from triggers.
Since callouts cannot be performed directly inside a trigger, you must defer them using @future(callout=true).
Because the external system can only accept one record at a time, you can invoke the future method once per record.

💡 Example:

public class AccountCalloutService {
@future(callout=true)
public static void sendToBackup(String accountId) {
Account acc = [SELECT Id, Name FROM Account WHERE Id = :accountId];
HttpRequest req = new HttpRequest();
req.setEndpoint('https://externalapi.com/backup');
req.setMethod('POST');
req.setBody(JSON.serialize(acc));
// add headers, auth, etc.
Http http = new Http();
HttpResponse res = http.send(req);
}
}

Trigger:

trigger AccountTrigger on Account (after insert, after update) {
for (Account acc : Trigger.new) {
AccountCalloutService.sendToBackup(acc.Id);
}
}

❌ Why Other Options Are Incorrect:

A. Implement the Queueable interface
Queueable Apex can perform callouts, but you cannot enqueue one job per record from a trigger without hitting limits.
Not suitable for 1-record-per-call from within a trigger, unless you batch them — which contradicts the 1-per-call requirement.

B. Implement platform events
Platform events are good for asynchronous integration, but they are not designed for immediate HTTP callouts and would require a separate subscriber system.

C. Expose an Apex class as a web service
This makes your org receivable (you host the endpoint), but in this case, you need to send data externally, not receive it.

📚 References:
Apex Developer Guide – Future Methods
Making Callouts from Triggers Best Practices

Explanation:

The Visualforce page correctly assigns Account ownership to a queue upon save, but the test class’s assertion fails. This suggests a discrepancy between the expected and actual state during testing.

Option A: The test class does not retrieve the updated value from the database. In Apex tests, changes made during execution (e.g., ownership assignment) are not automatically reflected in memory unless explicitly queried from the database. The test class must use a SOQL query (e.g., [SELECT OwnerId FROM Account WHERE Id = :accountId]) after the save to retrieve the updated ownership and assert against it. Without this, the test may check the in-memory state, which retains the original owner.

Option B: The test class does not use the Bulk API for loading test data. The Bulk API is for large data loads outside of test execution and is unrelated to validating ownership changes in a test class. This option is irrelevant.

Option C: The test class does not use the seeAllData=true annotation. seeAllData=true allows access to org data but is not required for testing ownership changes, which can be validated with test data created in the test class. This is not the cause of the assertion failure.

Option D: The test class does not implement the Queueable interface. The Queueable interface is for asynchronous processing and is not relevant to a synchronous ownership assignment via a Visualforce page. This option is incorrect.

Why Option A is Best:
Failing to requery the database after the save means the test checks an outdated in-memory state, causing the assertion to fail. A SOQL query ensures the test reflects the actual database state.

References:
Salesforce Developer Guide: Testing Apex

Explanation:

The company needs to delete nearly a million records daily after seven years, requiring a scalable, governor-limit-aware solution.

Option A: Schedule an @future process to query records older than seven years, and then recursively invoke itself in 1,000 record batches to delete them. Future methods have governor limits (e.g., 50 callouts per transaction) and cannot handle recursive invocation effectively for large datasets. This approach is not scalable for nearly a million records daily.

Option B: Use aggregate functions to query for records older than seven years, and then delete the aggregateResults objects. Aggregate functions (e.g., COUNT) return summarized data, not the records themselves, and cannot be deleted directly. This option is invalid.

Option C: Schedule a batch Apex process to run every day that queries and deletes records older than seven years. Batch Apex (Database.Batchable) is designed for processing large datasets by breaking them into batches (default 200 records, adjustable up to 2,000). Scheduling it daily with a query for records older than seven years ensures efficient deletion of nearly a million records within governor limits.

Option D: Perform a SOSL statement to find records older than 7 years, and then delete the entire result set. SOSL is for text-based searches across multiple objects and is not suitable for querying by date fields (e.g., created date). It also lacks the batching capability needed for large deletions.

Why Option C is Best:
Batch Apex handles large-scale deletions efficiently with its batch processing, making it ideal for deleting nearly a million records daily while respecting governor limits.

References:
Salesforce Developer Guide: Batch Apex

Explanation:

The Catalog object has a master-detail relationship with Catalog Item, and a change in Catalog’s CurrencyIsoCode should update the CurrencyIsoCode of up to 100,000 related Catalog Items.

Option A: A Database.Schedulable and Database.Batchable class that queries the Catalog Item object and updates the Catalog Items if the Catalog CurrencyIsoCode is different A Batch Apex class with Database.Batchable can process the 100,000 Catalog Items in batches, updating their CurrencyIsoCode based on the parent Catalog’s value. Scheduling it with Database.Schedulable allows it to run after detecting a Catalog change (e.g., via a trigger). This handles the large volume efficiently.

Option B: An after insert trigger on Catalog that updates the Catalog Items if the Catalog CurrencyIsoCode is different An after insert trigger on Catalog fires only on new records, not updates, and cannot handle 100,000 records in a single transaction due to governor limits (e.g., 10,000 DML rows). This is insufficient.

Option C: An after insert trigger on Catalog Item that updates the Catalog Items if the Catalog’s CurrencyIsoCode is different This trigger fires on Catalog Item inserts, not Catalog updates, and cannot propagate changes upward to update other Catalog Items. It’s the wrong direction and context.

Option D: A Database.Schedulable and Database.Batchable class that queries the Catalog object and updates the Catalog Items if the Catalog CurrencyIsoCode is different Querying the Catalog object alone misses the need to process all related Catalog Items. The batch should query Catalog Items and filter by the parent Catalog’s CurrencyIsoCode.

Why Option A is Best:
Batch Apex with scheduling handles the large volume of Catalog Items (up to 100,000) efficiently, updating their CurrencyIsoCode based on the Catalog’s value after a change.

References:
Salesforce Developer Guide: Batch Apex

Explanation:

❌ Option A: Add if (!accountList.isEmpty()) before updating accountList
Adding a condition like if (!accountList.isEmpty()) before updating accountList is a precautionary step to ensure the list contains records before processing. This practice helps avoid null pointer exceptions or unnecessary operations if the list were unexpectedly empty. In the context of this trigger, accountList is initialized as new List() and populated from trigger.new, which is always non-empty in a before trigger execution. Therefore, this check is technically redundant here since the trigger will not fire without records. While it’s a good habit in scenarios where lists are dynamically built or modified outside the trigger context, it does not address the primary performance or logic concerns, such as the query inside the loop or the unnecessary DML operation. Thus, it’s not a critical change for this specific case, making it less relevant to the best practices focus here.

✅ Option B: Move the Region__c query outside the loop
Moving the Region__c query outside the loop is a crucial best practice to enhance performance and scalability. Currently, the trigger queries Region__c for each Account in trigger.new using anAccount.Region__Name__c, which can lead to multiple SOQL queries and potentially exceed the 100 SOQL query governor limit if more than 100 Accounts are processed. By collecting all unique Region__Name__c values into a Set and performing a single query (e.g., SELECT Name, Region_Manager__c FROM Region__c WHERE Name IN :regionNames), the trigger becomes bulkified. This approach reduces resource usage, avoids governor limit exceptions, and handles bulk operations like Data Loader imports efficiently. It also allows for better error handling, such as managing null Region__Name__c values, making it a fundamental improvement for large datasets and a key reason this option is selected.

❌ Option C: Use a Map to cache the results of the Region__c query by Id
Using a Map to cache the results of the Region__c query by Id is an optimization technique to improve performance by storing query results for quick access. This approach is particularly useful when the same data might be queried multiple times or when relating records by a unique identifier like Id. However, in this trigger, the query is based on Name (from anAccount.Region__Name__c) rather than Id, so caching by Id isn’t directly applicable unless the relationship changes to a lookup field. A Map keyed by Name could be used after moving the query outside the loop, enhancing lookup efficiency. While this is a valuable secondary improvement, it depends on Option B being implemented first and isn’t one of the two most critical changes needed to address the immediate performance and DML issues, thus it’s not selected here.

✅ Option D: Remove the last line that updates accountList because it is not needed
Removing the last line update accountList; is essential because it’s unnecessary in a before trigger context. In before triggers, any modifications to trigger.new—such as setting anAccount.OwnerId—are automatically persisted to the database when the trigger completes, eliminating the need for an explicit DML operation. Keeping this line can lead to runtime errors, such as recursion or constraint violations, and consumes governor limits (e.g., 150 DML statements), though it’s unlikely to hit the limit here. This change simplifies the code, reduces overhead, and aligns with best practices for leveraging the implicit save behavior of before triggers. If the trigger were an after trigger, an update would be required, but given the current design, removing it is a clear improvement, making it a selected option.

Why Options B and D?
Option B addresses the critical performance issue of querying inside a loop, bulkifying the trigger to handle large datasets within governor limits, a core Salesforce best practice. Option D eliminates redundant DML, simplifying the code and preventing potential errors, aligning with efficient trigger design. Together, these changes optimize performance and correctness, ensuring the trigger is robust for production use.

References:
Trigger Best Practices
Governor Limits

Explanation

This question tests understanding of metadata deployment risks when multiple administrators deploy Change Sets independently from separate sandboxes into the same production org. It examines how overlapping deployments can overwrite shared components and the proper governance approach to prevent such conflicts.

✅ D. The administrators are deploying their own Change Sets over each other, thus replacing entire Page Layouts in production.
When multiple administrators deploy from separate sandboxes, each Change Set contains a snapshot of components as they existed in that specific sandbox. If Admin A adds a field to a Page Layout and deploys, then Admin B deploys a Change Set containing an older version of that same Page Layout from their sandbox, Admin B's deployment overwrites Admin A's changes. This causes the field to disappear from the layout in production, exactly matching the reported symptoms.

✅ B. A sandbox should be created to use as a unified testing environment instead of deploying Change Sets directly to production.
The root cause is isolated development without coordination. A unified testing environment—such as a Full or Partial Copy sandbox that serves as a staging area—allows all administrators to integrate their changes before production deployment. This ensures conflicts are caught during testing rather than affecting live users, and prevents Change Sets from overwriting each other's work in production.

❌ A. The administrators are deploying their own Change Sets, thus deleting each other's fields from the objects in production.
Change Sets cannot delete metadata from the target org unless the deployment explicitly includes a destructive changes manifest. Simply deploying a Change Set over an existing component replaces the component's definition but does not delete it. Fields are removed from Page Layouts, not deleted from the object itself.

❌ C. Page Layouts should never be deployed via Change Sets, as this causes Field-Level Security to be reset and fields to disappear.
Page Layouts can be safely deployed via Change Sets. Field-Level Security is a profile-level setting that is independent of Page Layouts. While a Profile deployment can reset FLS if not scoped properly, deploying a Page Layout alone does not affect Field-Level Security settings. This statement mischaracterizes how Salesforce metadata deployment works.

Reference
🔗 Salesforce Help – Change Sets Best Practices
→ confirms that multiple administrators deploying from separate sandboxes risk overwriting shared components, and recommends a unified deployment strategy.

🔗 Salesforce Help – Page Layouts and Field-Level Security
→ confirms that Page Layouts control field visibility on record pages and are separate from Field-Level Security, which controls actual field access.