Free Plat-Dev-201 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

In Salesforce Apex, when a DML operation fails within a trigger context, it throws an unhandled exception that prevents the entire transaction from completing. The code appears to have an issue that would cause the DML operation to fail (such as missing required fields, validation rules, or governor limits). When such failures occur in triggers without proper exception handling, the system throws an exception and rolls back the entire transaction, preventing any records from being created.

B. Incorrect - Apex always reports errors when DML operations fail in triggers.

C. Incorrect - A failed DML operation prevents record creation entirely.

D. Incorrect - Debug logs alone don't allow failed transactions to complete.

- Salesforce Apex Developer Guide, "Trigger Exceptions and Rollbacks" section

- Salesforce Platform Developer I Certification Guide, "DML Operations and Error Handling"

- Salesforce Trailhead: "Apex Triggers" module, "Exception Handling in Triggers" unit

- Official Salesforce Documentation: "Understanding Execution Governors and Limits"

- Salesforce Developer Documentation: "Database Methods vs. DML Statements"

The @TestVisible annotation allows test methods to access private or protected members of another class, such as methods, member variables, and inner classes. This is the standard and recommended practice for unit testing private methods without altering the method's intended visibility for non-test contexts. It provides necessary access for testing while maintaining proper encapsulation in the production code.

A. Use the SeeAllData annotation: This annotation provides access to org data, not private methods, and is generally discouraged as it hinders test data isolation.

B. Add a test method in the Apex class: Test methods must reside in a separate class annotated with @isTest, not within the class being tested.

C. Mark the Apex class as global: This unnecessarily exposes the entire class and its methods to all Apex code, which is a poor security and design practice.

- Salesforce Apex Developer Guide, "Testing Private Methods," which states, "To enable this, add the @TestVisible annotation to the private or protected members."

- Salesforce Apex Developer Guide, "Access Modifiers," which details the scope of private, protected, and global access modifiers.

- Salesforce Apex Developer Guide, "Isolation of Test Data from Organization Data in Unit Tests," which explains the purpose and drawbacks of using (SeeAllData=true).

To ensure test data is available without depending on existing org data, developers should create records within the test context. For larger data sets, the Test.loadData() method is the most efficient and recommended approach. This method populates records in a test method by reading data from a comma-separated value (CSV) file stored as a static resource. This practice ensures that tests are self-contained, predictable, and do not modify or rely on production data, which is a critical best practice for unit testing in Apex.

A. Using SOQL to query existing org data makes tests dependent on the specific data in an environment, which is unreliable and not portable. Tests should create their own data.

C. Anonymous Apex is a tool for ad-hoc script execution and is not used within a test class to create data for a unit test.

D. The Test.loadData() method specifically requires a CSV file as its source format, not a JSON file. It also references static resources, not Documents.

1. Salesforce Apex Developer Guide, "Test Data," section "Creating Test Data." It states, "To test your code, you often need to create test data first... For some complex test scenarios, it’s better to load test data from a static resource."

2. Salesforce Apex Developer Guide, "Test Class," section "Using Test.loadData." It specifies, "The Test.loadData method enables you to populate data in your test methods from a static resource... The static resource must be a CSV file."

When testing a custom controller for a Visualforce wizard, you need to: (A) Test navigation between pages by calling controller methods that return PageReference objects and verifying the URL; (B) Set URL parameters that the controller expects using ApexPages.currentPage().getParameters().put(); and (E) Set the current page context in the test using Test.setCurrentPage() to establish the proper testing environment for Visualforce controllers.

C. "insert pageret;" is syntactically incorrect and PageReference objects are not DML-capable.

D. This shows a constructor for an extension controller, not relevant for testing a custom controller.

3. References:

1. Salesforce Developer Guide - Testing Custom Controllers: "Unit Testing Visualforce Controllers" section, specifically pages on Test.setCurrentPage() usage

2. Apex Developer Guide - "Testing Visualforce Controllers and Extensions" chapter, sections on PageReference testing

3. Salesforce Documentation - "ApexPages Methods" reference, getParameters() method documentation

4. Trailhead Module - "Visualforce Controllers" unit on testing controllers with URL parameters

5. Salesforce Developer Documentation - "Test Class Methods" reference, Test.setCurrentPage() method specification

1. Apex Developer Guide, “Testing Controllers”, Example 2 – setting page context, Summer ’24, p. 423.

2. Visualforce Developer Guide, “Testing Custom Controllers and Extensions”, § Passing Parameters, p. 209.

3. Apex Developer Guide, “PageReference Class”, § getUrl(), p. 501.

In Visualforce, messages added to the page context in a controller using ApexPages.addMessage() are not automatically displayed. The component must be included in the Visualforce page markup. This component is specifically designed to render all messages that have been generated for the page, including those added via the controller, standard validation rules, or trigger errors. Without this component, the messages remain in the background and are not visible to the user.

A. is a structural component used to group related items on a page, but it does not render controller messages on its own.

C. is a generic container component that can be used to group other components or refresh areas of a page via AJAX, but it does not display page messages.

D. is a necessary container for any input components that submit data, but it is not responsible for displaying messages added via addMessage().

1. Salesforce Visualforce Developer Guide, "Standard Controller Actions," section "Displaying Messages." It explicitly states, "To display any messages that are generated... your Visualforce page must include the tag."

2. Salesforce Visualforce Developer Guide, . The component reference describes its purpose as "A component that displays all messages that were generated for all components on the current page, presented using the Salesforce styling."

The original code contains a SOQL query inside a for loop, which is a common cause of exceeding governor limits in Apex. The best practice is to "bulkify" the code by avoiding queries inside loops. The correct approach is to first iterate through the trigger context variable (newContacts) to collect all necessary AccountIds into a collection (like a Set). Then, perform a single SOQL query outside the loop to retrieve all required parent Account records. These records should be placed into a Map for efficient lookup. Finally, iterate through the contacts again to perform the logic, retrieving the corresponding Account from the Map.

Option B: This option still performs a SOQL query inside the for loop, failing to resolve the core issue of hitting governor limits in bulk scenarios.

Option C: This option uses a parent-to-child subquery, which retrieves contacts related to an account, the opposite of what is needed. The goal is to get the parent account for a contact.

Option D: This option is not provided in the question's source material.

1. Salesforce Developer Documentation, Apex Developer Guide, "Best Practices for Triggers," section "Bulkify Your Code." This section explicitly states, "you should not place any SOQL or DML inside of a for loop."

2. Salesforce Developer Documentation, Apex Developer Guide, "SOQL For Loops." This guide explains how to process records in bulk and warns against SOQL queries inside a standard for loop, recommending collecting IDs for a single query.

3. Trailhead, "Apex Triggers" module, "Bulk Apex Triggers" unit. This unit provides examples of bulkifying trigger code by querying once and using a Map to associate related records.

The Dev Hub is the main Salesforce org that you and your team use to create and manage your scratch orgs. A scratch org is a temporary, source-driven Salesforce environment used for development and testing. To use Salesforce DX features like creating scratch orgs, you must first enable the Dev Hub feature in a production, developer, or trial org. This org then acts as the central control point for all associated scratch orgs.

A. A Sandbox is a copy of a production org for development, but it cannot be used to create or manage scratch orgs.

B. The Environment Hub is used by partners to manage multiple customer orgs for consulting and development, but it is not the feature that enables scratch org creation.

C. While the Dev Hub feature is enabled in a production or developer org, simply having a production org is not sufficient; the feature must be explicitly enabled.

1. Salesforce Developer Documentation, Salesforce DX Developer Guide, "Enable Dev Hub Features in Your Org". This section explicitly states, "Your Dev Hub is the main Salesforce org that you and your team use to create and manage your scratch orgs... To get started with Salesforce DX, you enable a Dev Hub in any paid org, or a Developer Edition org or trial org."

2. Trailhead, Salesforce DX Quick Start, "Set Up Your Salesforce DX Environment". This module guides the user through the process of enabling a Dev Hub in their Trailhead Playground or Developer Edition org as the first step.

Marking the field as "Required" in its field definition is the most optimal and robust solution. This enforces the requirement at the database level, ensuring that a value must be provided for this field whenever a record is created or updated, regardless of the entry point—be it the user interface, an API call, or an Apex DML operation. This declarative approach is more efficient and maintainable than custom code and more comprehensive than UI-level settings.

A. Set "Use the first value in the list as the default value" to True: This only applies a default on record creation and does not prevent a user from clearing the value during an update.

B. Write an Apex trigger to ensure a value is selected: This is a programmatic solution for a requirement that can be met declaratively. It adds unnecessary complexity and maintenance overhead.

C. Mark the field as Required on the object's page layout: This only enforces the rule in the user interface for that specific page layout and can be bypassed through other means like the API.

Salesforce Help, "Custom Field Attributes": "Required: Requires users to enter a value in the custom field. This setting is enforced at the data model level, applying to the API and all user interfaces."

Salesforce Object Manager Documentation, "Field-Level Security": "Making a field universally required ensures that no user can save a record without a value for that field."

To make Apex code, such as a class or method, accessible to another namespace (e.g., from a managed package to a subscriber's org), it must be declared with the global access modifier. The public access modifier only allows access within the same namespace. For the calculateBodyFat() method to be accessible outside the package, both the containing Bodyfat class and the method itself must be declared as global.

B. Declare the class and method using the public access modifier: The public modifier restricts visibility to within the package's namespace, making it inaccessible to the consumer's code.

C. Declare the class as public and use the global access modifier on the method: This is an invalid declaration. A method with global visibility must be contained within a global class.

D. Declare the class as global and use the public access modifier on the method: While the class would be visible, the public method would remain inaccessible outside the package's namespace.

1. Apex Developer Guide, "Access Modifiers". The documentation states, "The global access modifier declares that this class is known by all Apex code everywhere... If you declare a method or variable as global, you must also declare the class that contains it as global."

2. ISVforce Guide, "Apex Code in Packages". This guide details how access modifiers work in the context of managed packages, specifying that global is required for exposing an API.

In the Aura Component Framework, application events are handled using a publish-subscribe model. To broadcast an event to all components that have registered a handler for it, the fire() method is used on the event instance. A component first gets a reference to the event using $A.get("e.namespace:eventName"), optionally sets parameters on it, and then calls fire() to dispatch it. This method is fundamental to the event-driven architecture of Aura components.

B. SegdetesEvent(): This is not a valid method in the Aura framework. The name appears to be a typo or a fabricated function name.

C. FireEvent(): This is not a standard method in the Aura framework. Method names in JavaScript are case-sensitive, and the correct method is fire().

D. emit(): This method is used for dispatching events in Lightning Web Components (LWC), not in the Aura Component Framework.

- Salesforce Lightning Aura Components Developer Guide, "Firing Component Events", Section: Firing an Event. The guide explicitly shows the syntax: var appEvent = $A.get("e.c:appEvent"); ... appEvent.fire();.

- Salesforce Lightning Aura Components Developer Guide, "Application Event Example", This section provides a complete example demonstrating the use of event.fire() to publish an application event.

The AccountsController class is declared with sharing, which enforces the sharing rules of the current user. The test method fails because, without a specified user context, the test runs in system mode and the query returns all 30 accounts created in the @testSetup method. The assertion System.assertEquals(20, result.size()) expects only the 20 accounts owned by the Standard User. To fix this, the call to AccountsController.getAllAccounts() must be executed within a System.runAs(user) block, using the Standard User record (user2). This simulates the method being run by that user, correctly applying their sharing rules and returning only the 20 records they own.

A. Running the test as the System Administrator (user1) would still return all 30 records, as administrators can view all data, causing the assertion to fail.

C. Using @isTest(seeAllData=true) is irrelevant as the data is created within the test. It is also a bad practice that makes tests dependent on org data.

D. This option is syntactically incorrect. System.runAs() requires a block of code to be enclosed within its scope, not just a single line preceding the method call.

1. Salesforce Apex Developer Guide, "Testing," section "Using the runAs Method." It states, "The runAs method enables you to write test methods that change the user context to an existing user or a new user so that the user’s record sharing is enforced."

2. Salesforce Apex Developer Guide, "Using the with sharing, without sharing, and inherited sharing Keywords." This section explains that with sharing enforces the sharing rules of the user running the code, which is critical for testing user-specific data visibility.

The requirement is to test a trigger without changing the organization's data. Apex test classes are designed for this exact purpose. They run in a separate transaction that is rolled back at the end of the test run, meaning any data created, modified, or deleted during the test does not persist in the database. The Developer Console's Test menu is a standard tool for executing these test classes and verifying trigger logic safely.

A. Deploying a class does not execute or test any code; it only saves the class definition to the organization.

B. Creating a record via the UI will permanently save the new Contact to the database, violating the requirement not to change org data.

D. Execute Anonymous runs code that does commit DML operations to the database, permanently changing the organization's data.

1. Apex Developer Guide, Introduction to Apex Code Test Methods. "By default, Apex tests don’t commit any data to the database... This way, you aren’t left with test data in your organization after the test executes."

2. Apex Developer Guide, Run Apex Test Methods. This section describes using the Developer Console to run tests, stating, "You can run a single test method, the methods in one class, or all test methods in your org."

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.

Option B inserts an unescaped merge expression directly into a JavaScript block, enabling malicious data in Account.Name to break out of the string literal and execute arbitrary script (ref. Security Guide, “Protect Against XSS”). Expressions rendered inside <script> tags must be wrapped with JSENCODE/HTMLENCODE or assigned through apex:outputText with escape=”true”; failing to do so is a documented XSS vulnerability.

A Apex outputText escapes HTML by default, so Account.Name is encoded—no XSS risk.

C Explicit HTMLENCODE() guarantees the value is safely rendered, removing injection vectors.

D JSENCODE() correctly escapes characters for JavaScript contexts, blocking script-breaking characters.

1. Salesforce Security Implementation Guide, “Visualforce and XSS”, §“Escape Output in JavaScript”, Winter ’24, p.167–169.

2. Visualforce Developer Guide, “escape attribute of ”, p.487.

In the Aura Component Framework, application events are broadcast to all components. The propagation follows a defined sequence with three phases: capture, bubble, and default. The capture phase proceeds from the application root down to the source component. The bubble phase follows, propagating from the source component back up to the root. The default phase is for the source component itself. The options 'bubble' and 'default' correctly identify two of these three phases.

A. Control: 'Control' is not a standard, documented phase in the Aura event propagation lifecycle.

D. Emit: 'Emit' describes the action of dispatching an event (e.g., using event.fire()), but it is not a propagation phase.

1. Salesforce Aura Components Developer Guide, "Application Event Propagation". The guide states, "Application event propagation has three phases: capture, bubble, and default."

The query needs to retrieve Contact records based on a field on the parent Account object and also retrieve related child JobApplicationc records. The correct syntax to filter on a parent object's field is Account.Industry. To retrieve child records in a subquery, the relationship name must be used, which is the plural of the child object's name followed by r. For the JobApplicationc object, the standard relationship name is JobApplicationsr. Therefore, the correct and most efficient query combines these elements.

A. [SELECT Id, (SELECT Id FROM JobApplicationsr) FROM Contact WHERE Accounts.Industry = 'Technology']: The relationship to the Account object is singular (Account), not plural (Accounts). The query would fail.

B. [SELECT Id, (SELECT Id FROM JobApplicationc) FROM Contact WHERE Accounts.Industry = 'Technology']: This uses the incorrect plural Accounts relationship and incorrectly uses the object API name (JobApplicationc) in the subquery instead of the relationship name.

C. [SELECT Id, (SELECT Id FROM JobApplicationc) FROM Contact WHERE Account.Industry = 'Technology']: This incorrectly uses the object API name (JobApplicationc) in the subquery instead of the child relationship name (JobApplicationsr).

Salesforce SOQL and SOSL Reference, "Relationship Queries." This documentation specifies using the r notation for relationship queries. Specifically, the section "Querying Parent-to-Child Relationships" shows the syntax (SELECT ... FROM ChildRelationshipName).

Salesforce Apex Developer Guide, "Working with SOQL," section "Writing SOQL Queries." This guide provides examples of traversing relationships, showing the Parent.Field syntax for parent fields and the subquery syntax for child records.

Salesforce Object Reference Guide, "Standard Objects," Contact. The guide details the standard lookup relationship from Contact to Account, named Account.

The provided code executes a SOQL query inside a for loop. This is a common anti-pattern in Apex that leads to exceeding governor limits, specifically the limit of 100 SOQL queries per synchronous transaction. In a multi-tenant environment, such limits are crucial for ensuring shared resources are not monopolized. The best practice is to "bulkify" the code by collecting all leadIds and performing a single SOQL query outside the loop (e.g., [SELECT FIELDS(ALL) FROM Lead WHERE Id IN :leadIds]) to retrieve all records at once.

A. Avoid using variables as query filters.

This is incorrect. Using bind variables (e.g., :leadId) is a best practice to prevent SOQL injection vulnerabilities.

C. Avoid executing queries without a limit clause.

While using a LIMIT clause is good practice for large data sets, it does not solve the issue of executing too many queries.

D. Avoid returning an empty List of records.

Returning an empty list is standard and safe practice. It correctly indicates no records were found and helps prevent null pointer exceptions.

1. Salesforce Apex Developer Guide, "Best Practices for Trigger and Bulk Requests," section "Performing DML on a List of sObjects." This section emphasizes processing records in bulk, which includes querying them in bulk.

2. Salesforce Apex Developer Guide, "Execution Governors and Limits," section "Per-Transaction Apex Limits." This table lists the "Total number of SOQL queries issued" as 100 for synchronous Apex.

3. Salesforce Trailhead, "Apex Triggers" module, "Bulk Apex Triggers" unit. This unit explicitly states, "you should never place a SOQL query inside a for loop."

A record-triggered flow is the recommended declarative tool to meet this requirement. A flow can be configured to trigger when a Contact's MailingState is changed. This flow can then query for all related Applicationc records. For each application, it can retrieve the PreferredLocationsc from the parent Jobc record and use a formula or decision element to check if the Contact's new state is included in the multi-select picklist values. The flow can then update a checkbox or text field on the Applicationc record accordingly, ensuring the data remains synchronized with minimal code maintenance.

A. Apex trigger: While an Apex trigger could accomplish this, it requires custom code, which increases maintenance overhead. Salesforce recommends using declarative tools like Flow first.

B. Roll-up summary field: Roll-up summary fields aggregate data from a detail record to a master record. They cannot be used here to pull data from two different related objects (Contact, Jobc) onto the Applicationc record.

1. Salesforce Architects, "Record-Triggered Automation Decision Guide". This guide recommends using Flow for most record-triggered automation scenarios that can be handled declaratively, reserving Apex for highly complex logic.

2. Salesforce Help, "Flow Builder". The documentation details how flows can get records, loop through them, and update related records, which is the pattern required by the scenario.

3. Salesforce Help, "Considerations for Record-Triggered Flows". This document outlines the capabilities of flows to handle cross-object updates based on record changes.

To automate deployments via a script, a command-line tool is required. The Salesforce CLI (SFDX CLI) is the modern tool for this purpose, allowing developers to script deployments, test runs, and other development tasks from a terminal or in a CI/CD pipeline. The Ant Migration Tool is a Java/Ant-based command-line utility that also allows for scripted retrieval and deployment of metadata. Both tools are designed for automation and can target any Salesforce org, including sandboxes, for deployment.

B. Developer Console: The Developer Console is a browser-based, interactive IDE. It lacks scripting or command-line capabilities for automating deployments.

C. Change Sets: Change Sets are a point-and-click feature within the Salesforce UI for manual deployments between connected orgs. They cannot be automated or called from a script.

1. Salesforce Developer Documentation, Salesforce DX Developer Guide, "Deploy Your Changes". This guide details using SFDX CLI commands like sf project deploy start for scripted deployments.

2. Salesforce Developer Documentation, Ant Migration Tool Guide, "Introduction". "You can use the Ant Migration Tool to...build scripted deployments that can be repeated."

In Apex, if a primitive data type variable like a Boolean is declared but not initialized, its value is null. The code initializes isOK without a value, so isOK is null. The if-else if block is evaluated sequentially. The first two conditions, isOK == false and isOK == true, both evaluate to false. The third condition, isOK == null, evaluates to true. Since theString == 'Hello' is also true, the entire third condition is met, and the code inside its block, x = 3;, is executed.

A. 1: This would be the result if the uninitialized Boolean isOK defaulted to false, which is incorrect in Apex; it defaults to null.

B. 2: This would be the result if isOK were explicitly initialized to true. It was not initialized, so its value is null.

D. 4: This would be the result if none of the preceding if or else if conditions were met, which is not the case here.

- Apex Developer Guide, "Data Types", Section: "Primitive Data Types". The documentation states, "If you declare a variable and don’t initialize it with a value, it will be null."

- Apex Developer Guide, "Expressions", Section: "Comparison Operators". The guide details how == works, including comparisons with null. The expression isOK == null will evaluate to true when isOK has not been assigned a value.