Master Salesforce Plat-Dev-301: Platform Developer II Exam Prep

Correct : D

To display new data in a lightning-datatable, changes are required at both the Data Retrieval (Apex) layer and the UI Definition (JavaScript) layer.

First, the SOQL query in the Apex controller must be updated to include the address fields. While MailingAddress is a compound field in Salesforce, in a SOQL query intended for a datatable, it is often best to retrieve the individual components (e.g., MailingStreet, MailingCity, MailingState).

Second, the JavaScript controller for the LWC must be updated. The columns array in the JS file defines which data properties the lightning-datatable looks for. Even if the Apex method returns the address data, the datatable will not render it unless there is a corresponding column definition with the correct fieldName property.

Option D correctly identifies this two-step process. Option B is incomplete because the UI wouldn't know to show the new data. Option C is incorrect because you don't 'extend' the component to add columns; you simply pass a configuration array. Option A is inefficient as it creates extra server round-trips for data that should be fetched in a single query. By aligning the SOQL fields with the datatable column definitions, the mailing address can be displayed seamlessly.

Correct : D

When a data table experiences slow performance during filtering, the root cause is often 'non-selective' queries that result in full table scans. In Salesforce, a query is selective when it uses an indexed field in the WHERE clause and filters down to a small percentage of the total records (typically 10% of the first million).

Option D is the correct strategy. By ensuring that the filter fields (such as a Status or Category) are either standard indexed fields or custom fields marked as 'External ID' or 'Unique' (which creates a custom index), the Query Optimizer can quickly locate the relevant rows. This significantly reduces the database processing time and the 'Time to First Byte' (TTFB) returned to the Lightning component.

Option C might seem attractive for small datasets, but it is not scalable; if the org has 50,000 records, returning all of them to the client will crash the browser's heap memory. Option B (setStorable) is an Aura-specific concept and is replaced by @AuraEnabled(cacheable=true) in LWC, but even caching doesn't help if the initial query itself is slow. Option A (SOSL) is for text searching across multiple objects and is generally less efficient than a targeted SOQL query for specific field filtering. Using a selective SOQL query ensures the component remains fast as data volume grows.

Correct : B, D

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.

==========

Correct : A

Comprehensive and Detailed

In SOQL, using the OR operator often prevents the Query Optimizer from using indexes effectively, especially if the fields involve different types of data. This is known as a 'non-selective' query structure in LDV environments.

By breaking the query into two separate SOQL statements (Option A), the developer allows each query to be evaluated independently.

SELECT ... FROM Account WHERE CreatedDate = :thisDate (Uses the standard index on CreatedDate).

SELECT ... FROM Account WHERE RecordTypeId = :goldenRT (Uses the standard index on RecordTypeId).

The developer can then combine the results into a Map<Id, Account> to ensure uniqueness (preventing duplicates if a record meets both criteria). This approach ensures both queries are 'selective' and run much faster than a single query with an OR filter.

Option D is a common anti-pattern because formulas are generally not indexed unless they are 'deterministic' and a custom index is requested from Salesforce support; even then, filtering on formulas is often slower than direct field filters. Option B and C do not address the underlying database performance issue.

Correct : B, C

3233

When a requirement specifies a 'non-linear' or highl34y customized layout, the high-35level lightning-record-form (A) is unsuitable because it automatically renders fields in a standard grid or based on a page layout. To achieve a custom UI---such as overlaying fields on a product image---the developer needs more granular control.

The lightning-record-edit-form (B) is the ideal container for this scenario. It provides the heavy lifting for data communication (loading and saving records) without imposing a strict visual structure. Within this form, the developer uses lightning-input-field (C) components for each Case field. These components are 'context-aware,' meaning they automatically inherit metadata like field labels, picklist values, and validation rules directly from the Salesforce object definition.

Because lightning-input-field components can be placed anywhere inside the lightning-record-edit-form tag, the developer can use custom CSS (absolute positioning or CSS Grid) to place them precisely over the product image as requested. Standard lightning-input (D) components could work but would require much more manual code to handle data binding, type conversion, and validation, making the combination of B and C the most efficient and platform-aligned approach.

==========