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

Answer : A, D

To expose an Apex method to a Lightning Web Component (LWC) and specifically use the @wire service, the method must meet two strict criteria: it must be public or global, and it must be annotated with @AuraEnabled(cacheable=true).

In the provided snippet, line 04 defines the method as static but lacks an access modifier. In Apex, the default access modifier is private, which prevents the LWC framework from accessing the method. Changing line 04 to public static List<Contact> (Option A) makes the method visible to the component.

Additionally, the @wire service requires the method to be 'cacheable' to optimize performance by storing results on the client-side. This is achieved by adding the @AuraEnabled(cacheable=true) annotation. Placing this on line 03 (Option D) ensures the method is registered with the Lightning Data Service as an invokable, cacheable action. Modifying line 08 (Option B) is incorrect because that is a private helper method that the component does not call directly. By making the primary method public and cacheable, the LWC can successfully bind its property to the data returned by the Apex controller.

==========

Answer : D

Salesforce enforces a strict restriction: Actual network callouts are prohibited during unit tests. This is to ensure that tests are deterministic, fast, and do not rely on the availability or state of external third-party systems. When the testing engine encounters a System.Http.send() or a web service call without a mock, it throws the error: 'Methods defined as TestMethod do no1t support Web servi2ce callouts.'34

To resolve this, the developer must provide a Mock Implementation. By using Test.setMock() (Option D), the developer instructs the Apex runtime to intercept any callouts and return a pre-defined response instead of attempting a real connection. The mock class5 must implement either the HttpCalloutMock interface (for REST) or the WebServiceMock interface (for SOAP).

Furthermore, the call to the mock and the callout method should be wrapped in Test.startTest() and Test.stopTest().6

Test.startTest(): Resets governor limits, providing a fresh context for the specific logic being tested.7

Test.stopTest(): Forces any asynchronous processing (often used in cal8louts, such as @future or Queueable) to complete before the next line of code executes.

In the provided code, Test.setMock must be called before CalloutUtil.sendAccountUpdate for the platform to know which mock to use. Once Test.stopTest() is reached, the mock response is processed, the checkbox is updated, and the subsequent SOQL query and assertion will correctly see the updated data. Option A is a poor practice because it skips the logic entirely, resulting in 0% code coverage for the integration logic.

Answer : C

For storing application configurations and integration settings that need to be easily modified by administrators and deployed across environments, Custom Metadata Types are the preferred solution. Unlike Custom Settings (Options A and D), records within a Custom Metadata Type are considered metadata rather than data. This is a critical distinction for the development lifecycle because these records can be included in Change Sets or deployment packages. This eliminates the manual overhead and risk associated with re-creating configuration records in production after a sandbox deployment.

In this scenario, UC needs to manage settings for two different payment processors. A Custom Metadata Type can be created with fields for API endpoints, merchant IDs, and security keys. An administrator can then create and edit the specific records for the 'Individual' and 'Corporate' processors directly in the Setup menu. Furthermore, Custom Metadata queries are efficient and do not count against standard SOQL governor limits in many contexts. While Custom Labels (Option B) are useful for translating text, they are not intended for complex, structured configuration data. Hierarchy Custom Settings are designed for user-specific overrides, which is not applicable here. Therefore, Custom Metadata provides the most robust, deployable, and administrator-friendly way to manage external service configurations.

==========

Answer : D

This requirement specifies two critical constraints: the operations take a long time (likely exceeding synchronous CPU and timeout limits) and they must be performed sequentially.

Queueable Apex (Option D) is the optimal solution because it supports job chaining. Chaining allows one Queueable job to enqueue another Queueable job from its execute() method. This effectively creates a sequence where Job B only starts after Job A has successfully finished. Each job in the chain starts with a fresh set of governor limits, which is essential for 'extensive database operations' and long-running callouts.

Option C (@future) is unsuitable because future methods cannot be chained; you cannot call one future method from another. Furthermore, the order in which multiple future methods execute is not guaranteed by the platform, violating the 'sequential' requirement. Option A (Apex Scheduler) is intended for delayed or recurring tasks and is not designed for managing immediate sequential dependencies. Option B is a defensive coding practice but does not solve the underlying need to complete the work. Queueable Apex provides the programmatic control needed to manage complex, multi-step asynchronous workflows safely.

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.

Answer : A

When you need to retrieve the total count of records in a large dataset (millions of records), a SOQL aggregate query using COUNT() (Option A) is the most efficient and performant method. Salesforce optimizes aggregate functions at the database 13level. Unlike a standard query that returns in14dividual records and counts against the '50,000 SOQL rows' limit, a COUNT() query returns a single integ15er result and counts as only one row to16ward the governor limits.17

This allows a developer to count millions of records in a single synchronous transactio18n without hitting row limits or causing significant CPU time issues. Option D (SOQL for loop) is the worst approach, as it would attempt to load every individual record into memory, hitting the 50,000-row limit almost immediately and likely causing a LimitException or Request Timeout.

Option B (Batch Apex) is unnecessary for a simple count and is much slower because it runs asynchronously. Option C (SUM) is used for adding up values in numeric fields, not for counting the number of records. For high-volume record counting, SELECT COUNT(Id) FROM Opportunity is the platform-standard approach to provide data to a Lightning component efficiently.

Answer : B, C

This scenario presents two distinct requirements: processing a large volume of data (50,000 records) and running the process at a specific time (once a day after business hours).

Database.Batchable (Option B): Processing 50,000 records in a single synchronous transaction will exceed Apex Governor Limits (specifically the CPU time limit or the heap size limit). Batch Apex allows the system to process these records in smaller chunks (batches), ensuring that the calculation completes without hitting limits.

Schedulable (Option C): To ensure the job runs 'once a day after business hours,' the Schedulable interface is required. The developer allows the class to be scheduled via the Apex Scheduler or the UI.

The standard pattern for this use case is to create a class that implements Schedulable, and inside its execute method, instantiate and execute the Batch class (Database.executeBatch). This combines precise timing with bulk processing capabilities.