Free Salesforce Certified Platform Developer II Plat-Dev-301 Exam Questions

Asynchronous methods, such as those annotated with @future, do not run immediately when called in Apex. Instead, they are added to a queue to be processed when system resources become available. In a unit test, if you call a future method and immediately query the database for the result, the future method likely hasn't executed yet, resulting in the '0' value observed in the assertion.

To test asynchronous code, you must wrap the call within Test.startTest() and Test.stopTest() (Option D). When the code reaches Test.stopTest(), the execution of the test script pauses, and the system forces all queued asynchronous jobs (future methods, batch jobs, queueable jobs) to run to completion synchronously.

By placing the AuditUtil.incrementViewed(acct.Id) call inside this block, you ensure that by the time the next line of code (the SOQL query) runs, the increment logic has finished and the database reflects the new value. Option B is incorrect because inserting the account is a synchronous operation that doesn't require the stopTest wait. Option A and C avoid the problem rather than testing the logic correctly. Option D is the standard platform-required pattern for testing asynchronous side effects.

In Visualforce, the component is specifically designed to provide user feedback during asynchronous (AJAX) operations. When an or initiates a request to the server, there is a delay while the server processes the logic and returns the updated data. To prevent users from clicking the button multiple times or to simply inform them that the system is working, developers use .

This tag allows you to define two facets: startText (or a start facet) and stopText (or a stop facet). By linking the status attribute of the to the id of the , the page will automatically toggle between these states. For example, while the button is processing, the status can display 'Processing...' or a loading spinner, and once the action is complete, it can return to being hidden or display a 'Completed' message.

Option B is used for timed, repeated requests. Option C is for displaying validation or system errors. Option D is used to add AJAX support to other components (like a picklist) but doesn't manage the display state of the request itself. Therefore, is the standard tool for managing UI state during the request-response lifecycle in Visualforce.

1920

Source-driven development shifts th21e 'source of truth' from the Salesforce Org to a Version Control System (like Git). To b22ridge the gap between local source code and the Salesforce platform, Salesforce CLI with Salesforce DX (Option C) is the required mechanism.

Salesforce DX (Developer Experience) introduced a source-centric metadata format that is more granular and easier to track in version control than the traditional Metadata API. The Salesforce CLI provides the command-line tools necessary to automate the deployment process, create scratch orgs for isolated testing, and perform 'source tracking' to identify exactly which files have changed. This is the foundation of modern CI/CD (Continuous Integration/Continuous Delivery) pipelines in the Salesforce ecosystem.

In contrast, Change Sets (Option B) are org-centric and manual, making them incompatible with automated version control. Data Loader (Option A) is for record data, not metadata. Unmanaged Packages (Option D) are used for distribution but do not support the iterative, source-controlled deployment workflow required for professional project management.

7

The provided code uses hard-coded strings for the URL and authe8ntication headers, which is a security risk and makes maintenance difficult. To add flexibility and security, Salesforce provides Named Credentials (Option D). A Named Credential acts as a single definition that encapsulates both the endpoint URL and the required authentication (Basic, OAuth, etc.) in a single Setup record.

By using the callout: protocol in the setEndpoint method (Option B), the developer instructs the Apex runtime to look up the configuration stored in the Named Credential named endPoint_NC. This approach provides several key benefits:

Security: Credentials like passwords are encrypted and stored safely in the platform's metadata, not in the code.

Simplified Code: The logic for building the Authorization header and base64 encoding (as seen in the original snippet) is handled automatically by the platform.

Maintainability: If the endpoint URL or the password changes, an administrator can update the Named Credential record via the UI without requiring any code deployment.

Custom Labels (Option A and C) can store URLs, but they cannot securely handle authentication logic or headers. Therefore, the combination of a Named Credential and the callout: syntax is the optimal platform-native solution for flexible and secure integrations.

Loading 'thousands' of records at once into a Visualforce page causes performance issues primarily due to the heavy DOM processing required to render thousands of table rows and the large View State generated.

The most effective way to improve performance and user experience in this scenario is pagination. Instead of rendering all records simultaneously, pagination displays a subset (e.g., 20 records) at a time. Using the StandardSetController (which is implied by 'standard Account List controller' in the context of lists) allows for efficient server-side pagination. It queries and retrieves only the records needed for the current page view, drastically reducing the View State size and the DOM elements the browser must render. While JavaScript Remoting (Option D) is fast for data retrieval, pagination is the fundamental pattern required to solve the 'render time' issue for large lists.

To create a responsive design in Salesforce Aura components, the lightning:layout and lightning:layoutItem components utilize a 12-column grid system based on the Salesforce Lightning Design System (SLDS). The issue in the original code is that size='6' is hardcoded, which forces each item to occupy 50% of the container width regardless of the screen size. On small mobile screens, 50% width is often insufficient for text content, leading to horizontal scrolling or overlapping.

Option B resolves this by using device-specific size attributes. By setting smallDeviceSize='12', each item is instructed to take up the full width (12 out of 12 columns) on mobile devices. This causes the items to stack vertically instead of sitting side-by-side. The mediumDeviceSize='6' and largeDeviceSize='6' attributes ensure that on tablets and desktop screens, the items return to a side-by-side layout (50% width each).

For this stacking to occur, the parent lightning:layout must have the multipleRows='true' attribute enabled. This allows the layout to wrap items to a new line once the total column count in a single row exceeds 12. Without multipleRows='true', the items would try to squeeze into a single line regardless of their individual size settings, which would not solve the horizontal scrolling problem. Option B is the only choice that correctly applies the grid logic to handle multiple breakpoints effectively.

When a Visualforce page is slow because it attempts to load a massive dataset all at once, the bottleneck is often the time taken by the controller constructor to query and process those records before the page can even begin to render. Lazy Loading (Option B) is a strategy where the developer avoids loading all data during the initial page initialization.

Instead of querying 10,000 records in the constructor, the developer can load only the structural elements of the page first. Then, using an action method (triggered by or a window.onload script), the data is fetched in the background. This allows the user to see the page layout immediately while the data 'populates' shortly after. This significantly improves the Time to First Byte (TTFB) and the perceived performance of the page.

Option A (transient) is excellent for reducing the View State size and speeding up postbacks (button clicks), but it does not inherently speed up the initial load time of a large dataset. Option C (JavaScript processing) can help but doesn't solve the data retrieval bottleneck. Option D (actionPoller) is used for periodic updates and is not an efficient way to load an initial large dataset. Lazy loading ensures that the 'heavy lifting' is decoupled from the initial page load, providing a more responsive experience.

The lightning-record-edit-form i7s a powerful LWC component that automates record creation and editing. 8It handles field-level security, metadata retrieval, and data persistence automatically. However, for a complete user experience, it requires specific sub-components to handle feedback. While lightning-input-field handles inline validation (like a missing required field), it does not automatically display 'top-level' error messages, such as validation rule failures or system errors returned from the server.

To display these errors, the developer must include the lightning-messages (Option A) component inside the lightning-record-edit-form tags. When a form submission fails, the lightning-messages component automatically catches the error payload returned by the Lightning Data Service and renders it in a user-friendly format at the top of the form (or wherever it is placed).

Option B is not a standard Base Lightning Component name. Options C and D belong to the Visualforce and Aura frameworks, respectively, and cannot be used within a Lightning Web Component template. Including lightning-messages is a required step for any robust implementation of lightning-record-edit-form to ensure users are informed of why a record could not be saved.

In Salesforce, a callout cannot be made directly from an Apex trigger (Option C). This is a fundamental architectural restriction of the platform. Triggers execute as part of a database transaction. If a trigger were allowed to make a synchronous callout, the database transaction---along with all its associated row locks---would remain open while waiting for a response from the external system. This could lead to severe performance bottlenecks and transaction timeouts.

To perform a callout based on a trigger event, the developer must move the callout logic into an asynchronous context, such as a @future(callout=true) method, a Queueable class, or by publishing a Platform Event.

Option A is incorrect because while asynchronous methods allow for higher CPU time, they do not extend the maximum individual callout timeout (120 seconds). Option B is incorrect because REST is simply a protocol and does not dictate synchronicity. Option D is incorrect because the limit for callouts in a single transaction is 100, so 10 callouts would still be permissible in a synchronous context (assuming they aren't in a trigger). Consequently, the presence of a trigger is the only factor listed that programmatically mandates an asynchronous approach.

To build a maintainable and scalable solution, a developer must separate business logic from trigger execution and avoid hard-coding threshold values.

First, the $1,000,000 threshold should be stored in Custom Metadata (Option B). Custom Metadata is superior to hard-coding or even Custom Settings in this context because the records are deployable and can be queried efficiently without counting against standard SOQL limits. If the business decides to lower the 'high value' threshold to $500,000, an administrator can simply update the Custom Metadata record without requiring any code changes or redeployments.

Second, the logic to identify these opportunities should be moved to a Helper Class (Option D). This follows the 'Separation of Concerns' principle. Instead of writing the SOQL query and logic inside the trigger, the trigger calls a method in the helper class. Similarly, the Lightning Web Component's Apex controller can call the exact same method in the helper class. This ensures that the definition of a 'high value opportunity' is managed in one single place in the codebase. If the logic becomes more complex (e.g., adding Industry filters), the developer only needs to update the helper class once to satisfy both the trigger and the UI component. Option A leads to 'spaghetti code,' and Option C is impossible as triggers cannot be called directly from JavaScript or other Apex classes.

To query history records for a standard object like Account, the developer must use the correct API name, which is AccountHistory (not Account_History). When filtering for a range of dates, SOQL provides the BETWEEN operator, which makes the query cleaner and more readable. Option C uses both the correct object name and the BETWEEN syntax, making it the most efficient solution.

In SOQL, CreatedDate BETWEEN :initialDate AND :endDate is shorthand for CreatedDate >= :initialDate AND CreatedDate <= :endDate. In the provided code, initialDate is 12 months ago (the older date) and endDate is 6 months ago (the more recent date). Therefore, the range correctly captures records between those two timestamps.

Option A and B use an incorrect object name (Account_History). Option D uses the incorrect comparison operator => (the correct operator is >=). Furthermore, Option C follows the best practice for date range queries in Apex by using bind variables with the standard AccountHistory object, ensuring the 'Auditors' profile can retrieve the necessary historical data within the platform's audit and security constraints.

24

The Visualforc25e View State holds the state of the page (including controller variables) between server requests. It has a strict limit of 135KB. When a page handles large sets of data, like a grid of Opportunities, the view state can easily exceed this limit.

Transient Keyword (Option A): This is the most effective programmatic way to reduce view state. Marking a variable as transient prevents it from being serialized into the view state. This should be used for any data that is only needed for the current request and does not need to be maintained during a postback (e.g., large lists of records retrieved for a single display).

Filters and Pagination (Option D): By using a StandardSetController or custom offset logic, the developer can limit the number of records held in memory at any given time. Instead of loading 5,000 Opportunities, the page can load and store only 20 records per page.

Refine SOQL Queries (Option E): Developers often query 'all' fields (e.g., SELECT * equivalent) or include large text areas that aren't displayed. By selecting only the specific fields required for the grid, the size of each object in the collection is reduced, directly lowering the view state.

Option B and C (private and final) affect variable visibility and immutability but do not prevent the variables from being serialized into the view state.

In Salesforce, a critical restriction is that synchronous callouts cannot be made from within an Apex trigger. This architectural limitation is in place because triggers execute as part of a database transaction. Allowing a synchronous callout---which waits for a response from an external system---would keep the database connection and transaction locks open for an indeterminate amount of time. This could lead to severe performance bottlenecks and row-locking issues across the entire organization. Therefore, if a developer needs to initiate an external integration based on a record change (trigger), the logic must be handed off to an asynchronous process, such as a @future(callout=true) method, a Queueable class, or a Platform Event.

Regarding the other options: A callout that takes longer than the maximum timeout (120 seconds) will fail regardless of whether it is synchronous or asynchronous, though async is often preferred for longer-running tasks to avoid blocking the user UI. Salesforce allows up to 100 callouts in a single transaction, so making more than 10 (Option C) does not inherently force an asynchronous approach unless the 100-callout limit is exceeded. Finally, the use of the REST API (Option D) is simply a protocol choice and does not dictate the execution context. Consequently, the presence of an Apex trigger is the only scenario listed that programmatically mandates the use of asynchronous execution to perform a callout.

1

The 'Maximum trigger depth exceeded' error occurs when a recursive loop is created, causing triggers to fire repeatedly until the platform's limit of 16 recursive cal2ls is reached. This often happens when an after update trigger performs a DML operation on the same record that initiated the trigger, or when two different objects have triggers that update each other in a circular fashion.

To resolve this, developers use a static Boolean variable within a helper class to manage the execution state. Because static variables in Apex persist for the duration of a single transaction, the trigger can check the value of this Boolean before executing its logic. When the trigger runs for the first time, it checks if the Boolean is FALSE, sets it to TRUE, and then proceeds. If the trigger is re-invoked within the same transaction (recursion), the Boolean check will fail, and the logic will be skipped. This 'recursion guard' ensures the logic only runs once per transaction.

Splitting the logic into two triggers (A) would not help, as both triggers would still be part of the same recursive cycle. There is no isMultiThread annotation (B), and while @future (C) can break the immediate execution chain, it does not address the underlying logic flaw and can lead to unmanageable asynchronous overhead. The static variable approach is the industry-standard 'best practice' for recursion control.

Comprehensive and 19Detailed 150 to 250 words of 20

This integration requiremen21t involves two specific needs: sending a custom JSON payload and handling a response that involves updating data in Salesforce. Outbound Messaging (Option C) is a declarative tool, but it is limited to XML/SOAP protocols and cannot send JSON. Therefore, a custom programmatic solution using Apex is required to construct and send the JSON payload to the external REST service.

Since the integration must be triggered by an event in Salesforce (likely the upload or update of a product record), an Apex trigger is the most direct starting point. However, as noted in previous questions, callouts cannot be performed directly within a trigger's execution context because they would block the database transaction. The developer must use asynchronous processing to handle the callout. An @future(callout=true) method is the standard way to achieve this. The trigger captures the necessary data, passes it to the future method, and the future method then performs the HTTP request to the external application.

Once the external application resizes the image, it can use the Salesforce REST API to send the resized file back to Salesforce. While Platform Events (Option D) are a modern alternative for event-driven architectures, they would still require an asynchronous subscriber (like a trigger or a flow) to actually perform the callout, making the Trigger + Future method combination the most straightforward and traditional answer for this PDII scenario.