Plat-Dev-201 Practice Questions

Lightning Web Components use static resources for custom SVGs. First, upload the SVG as a static resource (B). In the component’s JavaScript, import it using the @salesforce/resourceUrl directive and expose it via a property (A). Finally, reference that imported variable in the HTML template—for example, —to render the image (C).

D. Content assets are for CMS and aren’t required for LWC static-resource usage.

E. The template refers directly to the imported variable; no additional property beyond that created in step A is needed, so it is redundant.

1. Lightning Web Components Dev Guide, “Use SVG Resources—Import a Static Resource,” Winter ’24 release, para. 1-3.

2. Lightning Web Components Dev Guide, “Static Resources in LWC,” Winter ’24, Example code block showing upload-import-reference workflow.

@testSetup methods run once per test class, inserting common test data that every test method can access, saving governor limits. They cannot be used in a class annotated with @isTest(SeeAllData=true); that combination is explicitly unsupported.

A. Records can be updated inside a test method; updates are isolated to that method.

C. testSetup executes only once per class, so its DML counts once, not once per test method.

1. Apex Developer Guide, “Test Setup Methods” (v59.0) – runs once, data shared, cannot be used with SeeAllData=true.

2. Apex Developer Guide, “Isolation of Test Data” (v59.0) – explains visibility and mutability of setup records within individual test methods.

To prevent the deletion of a record based on a condition, the logic must execute before the database delete operation. An Apex trigger on the before delete event is the standard programmatic solution. The trigger can inspect the Statusc field of the records in the Trigger.old context variable and use the addError() method on the specific record to prevent its deletion if the status is not "Decommissioned". A validation rule is also a declarative way to enforce this. By creating a validation rule with a formula like AND(ISCHANGED(Statusc), TEXT(PRIORVALUE(Statusc)) 'Decommissioned'), you can prevent the status from being changed from anything other than 'Decommissioned' before deletion.

Before record-triggered flaw: While a before-delete flow could work, the question asks for two approaches, and the provided answer options are B and D. Between a flow and a trigger, the trigger is a more direct programmatic approach.

After record-triggered flow: This flow runs after the record has been deleted from the database but before the transaction is committed. It is too late to prevent the deletion at this stage.

Validation rule: A validation rule with the formula NOT(ISPICKVAL(Statusc, "Decommissioned")) in the context of a delete operation would prevent deletion. Validation rules fire on DML operations and can be used to prevent deletion based on criteria.

Editor's Note: There is a common misconception that Validation Rules do not fire on delete. However, they can be used to prevent deletion. The most direct and common methods are an Apex Trigger or a before-delete Flow. Given the options, the combination of an Apex Trigger and a Validation Rule represents both a programmatic and a declarative approach to solving the requirement.

Salesforce Apex Developer Guide, "Triggers", Section: "Trigger Context Variables". This section explains the use of Trigger.old and the addError() method in before triggers to prevent DML operations.

Salesforce Help, "Validation Rules", Section: "Validation Rule Formulas". This documentation details how to create formulas that evaluate record data to enforce business rules before a record is saved or deleted.

Salesforce Order of Execution documentation, which shows that validation rules execute before triggers on save operations. For delete operations, custom validation logic is typically handled in a before delete trigger.

The StandardSetController is a built-in Visualforce controller that is specifically designed to manage sets of records. It provides out-of-the-box functionality for pagination, such as next(), previous(), first(), and last() methods. By using a StandardSetController, the page will only load one page of records at a time into the view state, effectively resolving the "view state limit" error when dealing with thousands of records. This is the most direct and standard solution for this common Visualforce problem.

A. OffsetController is not a standard Salesforce class. While pagination is the correct approach, this is not the correct implementation class name.

C. JavaScript remoting avoids view state entirely but requires significant client-side code to build the table and manage state, making it more complex than the standard server-side solution.

D. A transient list variable is not stored in the view state, but it becomes null on postback, requiring it to be re-queried. It doesn't solve pagination on its own.

Salesforce Apex Developer Guide, "Using Standard Set Controllers," Section: "StandardSetController Class." This section details how StandardSetController enables pagination for displaying large record sets.

Salesforce Visualforce Developer Guide, "Best Practices for Improving Visualforce Performance," Section: "Minimize View State." This guide explicitly recommends using StandardSetController for pagination to manage large data volumes.

The most appropriate and powerful approach for troubleshooting complex logic issues like record duplication in a trigger is using the Apex Interactive Debugger. This tool allows a developer to set breakpoints and step through the code line-by-line in a sandbox. It provides real-time visibility into variable states, the call stack, and heap size, enabling direct identification of the faulty logic causing the duplication, such as incorrect map usage or recursive execution, which can be difficult to trace with static logs alone.

Review the Historical Event logs to identify the source of the issue.: Event Monitoring and Setup Audit Trail logs are for tracking user actions and metadata changes, not for debugging Apex code logic execution.

Add system.debug statements to the code to track the execution flow and identify the issue.: While useful, this is a less direct method. It requires modifying code and analyzing text logs, which is less efficient than real-time debugging for complex logic flaws.

Disable the trigger in production and test to see if the issue still occurs.: This only confirms the trigger is the source of the problem but does not help in debugging the actual code to find the root cause of the issue.

Salesforce Apex Developer Guide, "Apex Interactive Debugger", Section: "Debug Your Code with the Apex Interactive Debugger". (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apexdebugginginteractivedebugger.htm)

Salesforce Platform Developer I Certification Guide, "Debugging and Deployment", Objective: "Describe the tools available for debugging and deploying Apex." The guide highlights the capabilities of the Apex Interactive Debugger for in-depth code analysis.

A trigger can be fired multiple times in a single transaction if a record update occurs after the initial DML operation. A roll-up summary field on a parent object is recalculated and updated when a child record is modified. This update on the parent is a DML operation that fires the parent object's triggers. Similarly, an after-save record-triggered flow can be configured to perform a field update on the same record that initiated the flow. This action is a subsequent DML update that will cause the triggers on that object to run again.

A. Criteria-based sharing rule calculations run after the save but do not perform a DML update on the record itself, so they do not re-fire triggers.

B. Sending an email is an action that does not cause a DML update on the record, and therefore does not cause triggers to fire again.

1. Salesforce Developer Documentation, Apex Developer Guide, "Triggers and Order of Execution". Step 14 (for after triggers) and Step 8 (for before triggers) mention that roll-up summary field updates can cause the entire save procedure to be repeated.

2. Salesforce Help, Salesforce Order of Execution. This document explicitly lists "Executes record-triggered flows that are configured to run after the record is saved" as a step that can cause the entire save process, including triggers, to restart.

3. Salesforce Architects, Record-Triggered Automation Decision Guide. This guide details how different automation tools interact, noting that after-save flows can re-trigger the save order. Section: "Order of Execution".

Scratch orgs are the ideal environment for a source-driven project with multiple developers working independently. They are temporary, source-driven Salesforce orgs that are created quickly from a source control repository and a definition file. This allows each developer to have their own clean, configurable, and disposable environment for a specific feature or task. This model supports modern, agile development practices, continuous integration, and ensures that developers are working with consistent, reproducible org shapes, which is crucial when many different configurations are involved.

Developer sandboxes.: These are persistent orgs tied to a production org's metadata. They are not easily disposable or built from source, making them less suitable for modern, independent, source-driven development.

Full Copy sandboxes: These are intended for user acceptance testing and staging, not development. They are large, expensive, and have long refresh intervals, making them unsuitable for rapid development cycles.

Developer orgs: These are standalone, free orgs (DE Orgs) not linked to a production environment. They are not designed for team-based, source-driven development where environments need to be synchronized with a central repository.

Salesforce DX Developer Guide, "Scratch Orgs". The introduction states, "Scratch orgs are source-driven and disposable, and you can create them quickly... This workflow is ideal for developers who want to build and test in a clean environment." (https://developer.salesforce.com/docs/atlas.en-us.sfdxdev.meta/sfdxdev/sfdxdevscratchorgs.htm)

Salesforce Trailhead, "Salesforce DX Development Model" module, Unit: "Develop in Scratch Orgs". This unit explicitly details the use case for scratch orgs in source-driven, team-based projects.

Apex tests run with data isolation and, by default, do not have access to existing data in the Salesforce organization (a concept known as seeAllData=false). The Execute Anonymous window, however, runs in the current user's context and can access all data they have permission to see. If the code logic depends on pre-existing records, it will succeed in Execute Anonymous but fail in the test context unless the test method first creates the necessary data.

A. System.runAs is for testing user permissions and sharing, not for providing data access. The test would still fail if the required data doesn't exist.

B. Calling an @future method requires Test.startTest() and Test.stopTest() but doesn't inherently cause failure if the underlying logic is sound and data is present.

D. A syntax error would prevent the code from being saved or compiled, meaning it could not be run in either the Test Runner or the Execute Anonymous window.

- Salesforce Developers, Apex Developer Guide, "Isolation of Test Data from Organization Data in Unit Tests": "By default, Apex tests don’t have access to pre-existing data in the organization... You must create test data."

- Salesforce Developers, Apex Developer Guide, "Executing Anonymous Apex Code": "The code runs as the current user and can fail to compile if the code violates the user's object- and field-level security settings."

To make an Apex method available to a Lightning Web Component's @wire service, it must be annotated with @AuraEnabled(cacheable=true). The @AuraEnabled annotation exposes the method to Lightning components. The cacheable=true attribute is a specific requirement for the wire service, as it indicates the method only reads data (it is idempotent) and can be safely cached on the client to improve performance and manage data provisioning reactively.

B. @RemoteAction is a legacy annotation used for Visualforce JavaScript remoting and is not applicable to Lightning Web Components.

C. @RemoteAction is the incorrect annotation for Lightning components; it is used for Visualforce pages to call Apex methods from JavaScript.

D. Using only @AuraEnabled exposes the method, but it can only be called imperatively from a component. The cacheable=true attribute is required for it to be used with the @wire service.

1. Salesforce Developer Documentation, Lightning Web Components Dev Guide, "Call Apex Methods". Under the section "Wire an Apex Method to a Property or Function", it states: "To wire an Apex method to a property, the Apex method must be cacheable. Set cacheable=true."

2. Salesforce Developer Documentation, Apex Developer Guide, "AuraEnabled Annotation". This section describes the (cacheable=true) parameter, specifying its use for methods that retrieve data and its requirement for being wired to a Lightning component property.

To search for a text phrase across fields in multiple objects like Lead and Contact, Salesforce Object Search Language (SOSL) is required. The correct syntax is FIND 'searchterm' IN searchgroup RETURNING sObjectlist. Option C correctly uses FIND 'ACME', specifies searching IN ALL FIELDS, and lists the objects to RETURNING. The return type for a multi-object search is List<List>.

A. The IN FIELDS clause is not a valid search group in SOSL syntax. Valid options include ALL FIELDS, NAME FIELDS, EMAIL FIELDS, or PHONE FIELDS.

B. This is invalid SOQL syntax. A single SOQL query cannot have multiple sObjects in the FROM clause in this manner.

D. The return type is incorrect. When a SOSL query returns more than one sObject type, the result is a list of lists (List<List>), not a flat list (List).

1. Apex Developer Guide, "Introduction to SOQL and SOSL", section "SOSL Syntax". It details the structure: FIND 'searchQuery' [IN searchGroup] [RETURNING ObjectsAndFields].

2. Apex Developer Guide, "Executing a SOSL Query". This section clarifies the return type: "The result of a SOSL query is a list of lists of sObjects... Each list contains the search results for a particular sObject type."

3. SOQL and SOSL Reference, "FIND (SOSL)". This document provides examples and defines the valid searchGroup values, which do not include IN FIELDS.