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

Answer : C

14

In Sales15force, SOSL (Search) queries behave differently than SOQL (Database) queries during unit tests. Because the search index is not updated in real-time during a test transaction, a SOSL FIND statement will consistently return an empty list, even if records matching the criteria were just inserted within the same test method. This leads to the assertion failure seen in the developer's code.

To overcome this, Salesforce provides the Test.setFixedSearchResults() method (Option C). This method allows a developer to define exactly which record IDs should be returned by any SOSL query executed during the test. When Test.setFixedSearchResults(list_of_ids) is called, the platform bypasses the actual search engine and returns the specified records. This ensures that the test remains deterministic and can verify the logic that processes the search results.

Option A (SeeAllData=true) is a poor practice and doesn't guarantee the search index will be ready. Option B (Test.loadData) and Option D (@testSetup) are for data creation but do not solve the underlying SOSL indexing limitation. Using setFixedSearchResults is the standard, documented way to test SOSL functionality in the Apex environment.

==========

Answer : A

For application configurations that control behavior and styling across different environments, Custom Metadata Types (Option A) are the industry-standard choice. The primary advantage of Custom Metadata over Custom Settings or Custom Objects is tha1t the2 records themselves are treated as metadata. This means they can be deployed using Change Sets, Salesforce CLI, or packages. When a developer moves code from a Sandbox to Production, the associated configuration records are included in the deployment, ensuring that the Lightning Web Component behaves identically in both environments without manual data setup.

Furthermore, Custom Metadata is highly 'testable.' In Apex unit tests, you can query Custom Metadata records without needing the (SeeAllData=true) annotation. If your component's Apex controller logic depends on these variables, the tests will remain robust and environment-independent. Custom Settings (Option C) and Custom Objects (Option B) store records as data, which cannot be deployed via Change Sets and require manual entry or data loading in every new sandbox or production org, increasing the risk of configuration errors. Custom Metadata provides the most 'extendable' and deployable way to manage component-level constants and behavioral flags.

Answer : C

When building Apex controllers for Aura Components (or Lightning Web Components), any method annotated with @AuraEnabled must be defined as static. The snippet provided defines the method getStringArray() as an instance method (public List<String>...) rather than a static method (public static List<String>...).

The Lightning Component framework does not instantiate an object of the Apex class; instead, it calls the method statically. If the method is not static, the framework cannot locate or execute it, resulting in an error. While global was required in older versions or for managed packages, public is sufficient for code within the same namespace. Apex handles the serialization of standard types like Lists automatically, so manual JSON serialization is not required.

Answer : C

The Visualforce View State is a hidden form field that maintains the state of the page (including controller variables) between server requests. 9Salesforce imposes a strict 135KB limit on the View State. When a page handles large amounts of 10data---such as large lists of records or complex objects---the serialized size of the controller variables can easily exceed this limit, resulting in a runtime error for the user.

To correct these errors, the developer should use the transient keyword (Option C). Marking a variable as transient prevents it from being serialized into the View State. This is the standard best practice for any data that does not need to be maintained across 'postbacks' (actions that refresh the page or part of the page). Common candidates for the transient keyword include:

Large lists of records retrieved for display only.

Temporary variables used for calculations during a single request.

Summary data that can be easily re-queried if needed.

Option A relates to security, not performance. Option B (private variables) does not exclude variables from the View State; only static and transient variables are excluded. Option D relates to SOQL governor limits, which are independent of the View State size. By judiciously using transient, the developer keeps the page weight low and ensures a smooth user experience in production environments with real-world data volumes.

Answer : B

This requirement involves a complex, multi-step integration where an external system (PIM) drives data changes in Salesforce across multiple objects (Product2 and PricebookEntry) and requires a lookup to a specific configuration (Custom Setting). While the standard Salesforce REST API can create records, it would require the PIM to manage the sequencing and the lookup logic for the Pricebook.

A Custom Apex REST (Option B) service is the optimal solution because it allows the developer to expose a single endpoint to the PIM. The PIM can send a single JSON payload representing the product. The Apex code then takes over to:

Upsert the Product2 record based on an External ID.

Retrieve the Pricebook2 ID from the Custom Setting.

Query and upsert the corresponding PricebookEntry record.

This 'wraps' the entire business process into a single transaction, ensuring data integrity (either both records are updated, or neither is) and reducing the number of round-trips the external system must make. Option A is for creating trees of records but doesn't easily support the logic of checking custom settings or existing records for upserting. Option C is for Flow/Process Builder, and Option D is for security auditing. Custom Apex REST provides the necessary flexibility for complex cross-object integration logic.

==========

Answer : A, C

When multiple components on a single page all fail simultaneously (for example, due to a shared service failure), individual toast messages stack up, creating a poor user experience. To resolve this, developers should shift away from 'ephemeral' notifications like toasts toward more structured error handling.

Option A involves creating a dedicated error-handling component. This component can act as a listener or a central repository for errors across the page. Instead of each component firing its own toast, they can communicate their error state to this central component, which aggregates the messages into a single, clean display. This reduces visual clutter and allows the user to read all errors in one place.

Option C refers to 'in-place' error handling. Using conditional rendering (the lwc:if or template if:true directives), a component can hide its normal UI and display an error message exactly where the component would have been. This provides immediate context to the user about which specific part of the page failed without interrupting the overall flow with pop-ups.

Option B (window.alert) is considered a legacy practice that blocks the browser thread and is generally avoided in modern web development. Option D (public properties) is a mechanism for component communication but doesn't solve the display problem itself. Combining A and C provides a modern, professional, and less intrusive error-handling strategy.

==========

Answer : C

For AppExchange development, Custom Metadata Types (Option C) are the superior choice for application configurations. Unlike Custom Settings or Custom Objects, Custom Metadata records are treated as metadata, not data.

This provides three critical advantages for an AppExchange developer:

Packaging and Deployment: You can package the metadata records (the 'best practice settings') as part of your managed package. When a customer installs your app, these settings are automatically populated in their org.

Environment Consistency: Custom Metadata can be deployed across sandboxes and production using standard deployment tools (Change Sets, CLI), whereas Custom Settings require manual data migration or data loading in every new environment.

Unit Testing: Apex tests can access Custom Metadata without the need for (SeeAllData=true). This ensures that your package's logic remains testable and robust across all subscriber orgs regardless of their specific data setup.

Custom Labels (Option D) are intended for translated text, not complex logic triggers. Custom Objects (Option B) consume data storage and cannot be easily packaged with default records. Custom Metadata allows the app to be 'configurable' by the subscriber while providing a 'standard' baseline upon installation.