Plat-Dev-301 Practice Questions

Salesforce prohibits making synchronous web service callouts directly from an Apex trigger. This restriction is in place to prevent long-running callouts from blocking database operations. To perform a callout after a DML event, the logic must be executed asynchronously. This is achieved by invoking a method annotated with @future(callout=true) or by enqueuing a Queueable Apex job from the trigger. These asynchronous processes run in a separate transaction, allowing the callout to be made without violating governor limits or platform constraints.

A. Querying large datasets can be done synchronously using a SOQL For Loop, which efficiently handles large result sets by batching records and avoiding heap limit errors.

B. Scheduling a future batch process using System.scheduleBatch is an action that can be initiated from a synchronous context, such as an anonymous Apex window or a Visualforce controller.

D. Updating a related record after an insert is a standard use case for an after insert trigger, which operates synchronously within the same transaction as the initial DML operation.

1. Apex Developer Guide, "Triggers and Callouts". This section explicitly states, "You can’t make a callout from a trigger." It then recommends using an asynchronous method (e.g., a future method) to perform the callout.

2. Apex Developer Guide, "Future Methods". The documentation details the use of the @future(callout=true) annotation, which is the primary mechanism for making callouts from trigger logic.

The provided code is highly inefficient because it queries for every User in the org and then uses a nested loop to compare them against the incoming Accounts. This can easily exceed CPU time limits. The most significant optimization is to make the SOQL query selective. By first collecting the AuditCodec values from the incoming accounts into a Set, a developer can add a WHERE AuditCodec IN :codeSet clause to the SOQL query. This drastically reduces the number of records returned and processed, directly addressing the primary performance bottleneck.

B. Building this map is a useful step in an optimized solution, but it doesn't fix the core problem of the non-selective SOQL query that fetches all users.

C. This map structure is not logical for solving the problem of assigning an auditor based on an audit code.

D. This is part of the correct pattern, but option A is more direct and describes the most critical optimization: filtering the SOQL query itself.

1. Apex Developer Guide, "Best Practices for Triggers", Section: "Bulkify Your Code". The guide emphasizes writing queries that are selective.

2. Apex Developer Guide, "Writing SOQL Queries", Section: "Filtering Query Results with the WHERE Clause".

3. Salesforce Architects, "Record-Triggered Automation", Section: "Apex Trigger Best Practices", Guideline: "One Trigger Per Object" and "Bulkify your Helper Methods" which includes writing selective SOQL.

To test a Visualforce controller that depends on a record ID from the URL, the test method must simulate this context. The correct procedure is to first create and insert the necessary test data (the Account). Then, instantiate a PageReference and use ApexPages.currentPage().getParameters().put('id', testAccount.Id) to add the record's ID as a URL parameter. Finally, instantiate the controller. This setup ensures the controller operates on the specific record created within the test, isolating the test from org data and making it predictable.

A. System.setParentRecordId() is not a valid Apex method. The correct approach involves setting URL parameters on a PageReference.

C. Using seeAllData=true is a poor practice that makes tests dependent on org data and non-repeatable. It does not set the specific record context for the controller.

D. System.setParentRecordId() is not a valid Apex method. This option incorrectly identifies the method for setting the controller's context.

1. Visualforce Developer Guide, "Testing Custom Controllers and Controller Extensions," Section: "Setting Page Parameters in a Test". It provides an example: PageReference pageRef = Page.myVFPage; Test.setCurrentPage(pageRef); ApexPages.currentPage().getParameters().put('id', '001D000000IRt53');

2. Apex Developer Guide, "Testing Best Practices," Section: "Isolating Test Data from Organization Data in Tests". This section emphasizes creating test data and avoiding (SeeAllData=true).

The scenario describes two related problems: slow performance and exceeding the view state size limit (135 KB). Both issues stem from querying and attempting to manage too large a record set in the controller's memory. A StandardSetController is the idiomatic Visualforce solution for handling large data sets, as it provides built-in pagination and manages record retrieval in batches, keeping the view state small. Alternatively, manually adding a LIMIT clause to the SOQL query in a custom controller achieves a similar outcome by restricting the number of records returned, thus reducing both query time and view state size.

A. Standard picklists are indexed. Assuming the filter uses non-indexed fields is a premature conclusion; the core issue is the volume of data returned, not necessarily the filter field type.

B. The transient keyword reduces view state by excluding a variable from serialization. Removing it would worsen the "Maximum view state size limit exceeded" error.

C. Splitting the page does not solve the underlying problem. The controller would still fetch a large dataset, causing the same performance and view state issues on the results page.

1. Salesforce Apex Developer Guide, "Working with Large Sets of Data," section on StandardSetController. It explicitly states, "Standard set controllers... allow you to create list controllers that can display and act on a set of records, such as in a list page with pagination."

2. Salesforce Visualforce Developer Guide, "Best Practices for Improving Visualforce Performance," section "Reduce View State". It recommends using StandardSetController or limiting data to reduce view state.

3. Salesforce SOQL and SOSL Reference, "LIMIT Clause". The documentation describes how LIMIT restricts the number of rows returned, which is a direct way to control data volume.

A "View State" error occurs when the data stored in a Visualforce page's state exceeds the 170KB limit. This state includes controller properties and component trees needed to maintain the page's state between server requests. The transient keyword is the specific Apex feature designed to solve this. By declaring a variable as transient, a developer instructs the platform to exclude it from the view state, thus reducing its size. This is appropriate for variables that are not needed across postbacks or can be easily reconstructed.

A. Profile access issues would result in an "Insufficient Privileges" error, not a View State error.

B. The private access modifier controls code visibility, but does not prevent a variable from being included in the view state if it's accessed by the page.

D. Exceeding governor limits, such as the number of SOQL queries, results in a LimitException, which is a different error from a View State size error.

1. Visualforce Developer Guide, "Understanding Visualforce View State", Section: "Best Practices for Reducing View State". The guide explicitly states, "Use the transient keyword for variables that are not essential for maintaining the page’s state and can be reconstructed."

2. Apex Developer Guide, "Using the transient Keyword". This section details how the keyword prevents fields from being saved as part of the view state.

The Lightning Web Component passes a JavaScript object { firstName: 'someValue' } to the Apex method. The Apex method signature must correctly map to this structure.

1. The parameter type should be String, and the parameter name must match the key in the JavaScript object (firstName). Therefore, the signature must be changed from serverEcho(sObject firstName) to serverEcho(String firstName).

2. With the corrected signature, the firstName parameter directly holds the string value. The line String firstNameStr = (String)firstName.get('firstName'); is now incorrect and unnecessary, as a String variable has no .get() method. This line must be removed, and the firstName parameter should be used directly in the return statement.

A. Annotating the entire class with @AuraEnabled is a valid alternative to annotating each method, but it is not a required change for the existing code to work.

D. The public access modifier is sufficient for a method to be called from a Lightning component in the same namespace. global is not required.

1. Salesforce Developers Documentation, Lightning Web Components Dev Guide, "Call Apex Methods", Section: "Pass Parameters to Apex Methods". This guide shows that when passing a JavaScript object, the properties map to the named parameters in the Apex method.

2. Salesforce Developers Documentation, Apex Developer Guide, "AuraEnabled Annotation", Section: "Using the @AuraEnabled Annotation". This documentation confirms that @AuraEnabled can be used on static methods and that public or global access modifiers are required. It does not mandate global.

3. Salesforce Developers Documentation, Apex Developer Guide, "Data Types". This reference details the methods available for primitive types like String, confirming it does not have a .get() method, unlike sObject.

The force:hasSObjectName interface is a marker interface specifically designed for this use case. By adding it to the component's implements attribute, the Lightning Framework automatically provides the API name of the current sObject in a component attribute named sObjectName. This approach retrieves the page context declaratively without requiring any Apex controller code. Since no Apex is involved, no additional test coverage is needed, directly satisfying all requirements of the question.

A. A design attribute requires manual configuration by an administrator in the App Builder for each instance of the component, making it less reusable and not context-aware.

B. This is not a mechanism for automatically getting context. It would require the developer using the component to manually pass the sObject type in the markup.

C. Using an Apex method like getSObjectType() requires a server-side call and, more importantly, any Apex code must have associated test coverage, which violates a key constraint.

Salesforce Lightning Aura Components Developer Guide, "Component-Level Interfaces", Section: "force:hasSObjectName". The documentation states, "Implement this interface to enable a component to be aware of the current record's object API name."

The Bulk API is specifically designed for asynchronously loading or deleting large sets of data, ranging from a few thousand to millions of records. Given the requirement to update "Millions of Accounts," the Bulk API is the optimal choice. It processes data in batches, operates asynchronously in the background, and is built to handle large data volumes efficiently without being constrained by the typical governor limits of synchronous APIs.

A. The Composite REST API is for executing a series of related API requests in a single call, not for processing millions of records. It has a limit on subrequests.

B. The SOAP API is a synchronous API best suited for real-time client applications that update a few records at a time, not for mass updates of millions of records.

D. An Apex REST Web Service is subject to Apex governor limits, such as CPU time and heap size, making it unsuitable and inefficient for processing millions of records.

1. Bulk API 2.0 and Bulk API Developer Guide, "Which API Should I Use?". The guide explicitly recommends Bulk API for "loading a large set of data into your Salesforce org for the first time" or for operations involving "more than 2,000 records."

2. Salesforce Architect - Record-Triggered Automation, "Choosing the Right Automation Tool". While focused on automation, the principles highlight using asynchronous, bulk-safe tools for large data volume operations, a category where the Bulk API is the primary integration tool.

The component's performance issue stems from unconditionally rendering the child component on initial load because showContactInfo defaults to true. Changing the default to false implements lazy loading. The child component and its associated data processing will not be initiated until the showContactInfo attribute is explicitly changed to true, for example, by a user action. This defers the rendering and improves the initial load time of the parent component.

A. Moving the contents of the child component into the parent would likely worsen performance by increasing the parent's complexity and initial payload, preventing lazy loading.

B. Changing the attribute type from Object to Map is a data structure change that would not have a significant impact on the component's rendering performance.

1. Salesforce Aura Components Developer Guide, "Performance Best Practices for Aura Components", section "Use Lazy Instantiation for Components". (Explicitly recommends using aura:if with a default false condition to defer component creation).

2. Salesforce Aura Components Developer Guide, "Conditionally Displaying Content with aura:if". (Explains how aura:if adds or removes components from the DOM, which is the mechanism for lazy loading).

A slow initial page load due to a large dataset is best solved by reducing the amount of data queried and transmitted at once. Lazy loading is a design pattern that defers the loading of data until it is needed. Instead of querying all records in the controller's constructor, an initial, smaller subset is loaded. More data is then fetched on-demand via user actions like clicking a "Next" button or scrolling, significantly improving the initial perceived performance of the page. This is often implemented using a StandardSetController or custom Apex with offset.

A. The transient keyword reduces view state size, which improves performance on subsequent requests (postbacks), but does not affect the initial query and page load time.

C. Moving data processing to the browser doesn't solve the core issue, which is the time taken to query and transfer a large dataset from the server initially.

D. An is used for periodic, automatic refreshes of data from the server. It is not an appropriate mechanism for an initial bulk data load.

Salesforce Visualforce Developer Guide, "Best Practices for Improving Visualforce Performance", Section: "Working with Large Data Volumes". This section recommends using pagination with a StandardSetController or custom controllers to lazy load data.

Salesforce Architects, "Designing Record-Centric Applications on Salesforce", Section: "Data Handling Patterns". This guide discusses patterns like lazy loading for handling large data volumes efficiently.