The Salesforce Certified Platform Developer II ( Plat-Dev-301 ) (PDII)

Asynchronous methods, such as those annotated with @future, do not run immediately when called in Apex. Instead, they are added to a queue to be processed when system resources become available. In a unit test, if you call a future method and immediately query the database for the result, the future method likely hasn ' t executed yet, resulting in the " 0 " value observed in the assertion.

To test asynchronous code, you must wrap the call within Test.startTest() and Test.stopTest() (Option D) . When the code reaches Test.stopTest(), the execution of the test script pauses, and the system forces all queued asynchronous jobs (future methods, batch jobs, queueable jobs) to run to completion synchronously.

By placing the AuditUtil.incrementViewed(acct.Id) call inside this block, you ensure that by the time the next line of code (the SOQL query) runs, the increment logic has finished and the database reflects the new value. Option B is incorrect because inserting the account is a synchronous operation that doesn ' t require the stopTest wait. Option A and C avoid the problem rather than testing the logic correctly. Option D is the standard platform-required pattern for testing asynchronous side effects.

67

Salesforce uses Database.Savepoint objects to manage transaction integrity, allowing developers to roll back the database state to a specific point in time without aborting the entire transaction. However, savepoints follow a strict " stack " logic. 8 When you create savepoints in sequence (SP1, then SP2, then SP3), they exist in a linear timeline. 91011

When a developer executes a Database.rollback(SP1), the system reverts the database state to exactly how it was when SP1 was created. A critical side effect of this operation is that any savepoints created after the target savepoint are immediately destroyed and invalidated. Because SP3 was created after SP1, 12 rolling back to SP1 clear 13 s SP3 from the transaction ' s memory. Therefore, any subsequent attempt to call Database.rollback(SP3) will result in a runtime error because SP3 no longer exists.

To fix this logic, once the code rolls back to SP1 and addresses the condition, it would need to proceed forward through the logic again and potentially set new savepoints if needed. You cannot " jump back forward " to a later savepoint once an earlier one has been invoked, as the rollback has effectively erased the timeline that led to the later savepoints. Understanding this linear invalidation is essential for managing complex nested transactions in Apex.

==========

To achieve a responsive layout in Salesforce Aura components, the lightning:layout and lightning:layoutItem components utilize a 12-column grid system . The size attribute defines the default behavior, which targets the smallest devices (mobile). In the original code, size= " 12 " is applied to all three items. Since each item occupies the full 12 columns, they stack vertically in three rows.

To meet Requirement 2 (displaying in a single row for tablets and desktops), the three items must share the 12-column horizontal space. Mathematically, $12 \div 3 = 4$. Therefore, each item must be assigned a size of 4 for larger screen breakpoints.

Option D is the correct implementation. It maintains size= " 12 " for mobile (Requirement 1) and sets mediumDeviceSize (tablets) and largeDeviceSize (desktops) to 4 . This ensures that on any screen larger than a phone, the three items will sit side-by-side in a single row.

Option A is incorrect because mediumDeviceSize= " 6 " would only allow two items per row ($6 + 6 = 12$), forcing the third item to a second row. Option C is incomplete as it only specifies the largeDeviceSize, potentially leaving tablets in a stacked configuration. Option D follows the best practice of explicitly defining the span for all relevant device categories to ensure a consistent user experience.

The " SOQL query not selective enough " error occurs when a query on an object with a large volume of records (typically over 200,000) does not use a filtered index to narrow down the result set effectively. In Sales 1 force, 2 the query optimizer must be able to use an index to scan a small enough percentage of the total records to maintain performance. When a query filters on a non-indexed field, the system is forced to perform a full table scan, which triggers this exception to prevent performance degradation.

To resolve this, the developer must ensure that the field used in the WHERE clause is indexed. Marking a custom field as an " External ID " or " Unique " automatically creates a custom index on that field. By marking ERP_Number__c as an External ID, the platform generates a underlying database index, allowing the query optimizer to quickly locate matching records without scanning the entire table. While the LIKE operator with a trailing wildcard (e.g., ' Text% ' ) can utilize an index, it will only be considered " selective " if the filter narrow the results below the platform ' s selectivity thresholds (typically 10% of the first million records). Making the field an External ID is the standard programmatic solution to provide the necessary indexing for selectivity. Option A is incorrect because moving a non-selective query to an asynchronous process does not change the fact that it is non-selective; it will still fail.

==========

This requirement calls for " Transactional Atomicity, " meaning either both database operations (Account creation and Contact creation) succeed, or neither is committed to the database. In Apex, each DML statement normally acts as its own individual transaction unless managed by Savepoints .

The correct approach is to use Database.setSavepoint() and Database.rollback() within a try-catch block (Option A) . The developer sets a savepoint immediately before the Account is inserted. If the Account is created successfully but the subsequent Contact insertion fails (due to a validation rule, trigger error, or system exception), the code enters the catch block. Within the catch block, the developer executes Database.rollback(sp), which reverts the database to the state it was in before the Account was ever inserted.

Option B is technically similar but " A " provides the standard programmatic pattern name. Option C (allOrNone=false) only applies to a single list of records in one DML call and cannot link the success of an Account to a Contact. Option D (manual deletion) is an unreliable " cleanup " strategy that fails if the system crashes or if there are secondary side effects from the initial insertion. Using Savepoints ensures the platform handles the rollback safely and completely.

Comprehensive and Detailed Explanation:

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.

1

The " Maximum trigger depth exceeded " error occurs when a recursive loop is created, causing triggers to fire repeatedly until the platform ' s limit of 16 recursive cal 2 ls is reached. This often happens when an after update trigger performs a DML operation on the same record that initiated the trigger, or when two different objects have triggers that update each other in a circular fashion.

To resolve this, developers use a static Boolean variable within a helper class to manage the execution state. Because static variables in Apex persist for the duration of a single transaction, the trigger can check the value of this Boolean before executing its logic. When the trigger runs for the first time, it checks if the Boolean is FALSE, sets it to TRUE, and then proceeds. If the trigger is re-invoked within the same transaction (recursion), the Boolean check will fail, and the logic will be skipped. This " recursion guard " ensures the logic only runs once per transaction.

Splitting the logic into two triggers (A) would not help, as both triggers would still be part of the same recursive cycle. There is no isMultiThread annotation (B), and while @future (C) can break the immediate execution chain, it does not address the underlying logic flaw and can lead to unmanageable asynchronous overhead. The static variable approach is the industry-standard " best practice " for recursion control.

==========

Platform Events follow an event-driven architecture that allows for seamless integration between internal Salesforce processes and external applications. Once an event is defined, it must be " published " to the event bus to be seen by subscribers.

External Applications (Option C) publish platform events by using the Salesforce REST, SOAP, or Pub/Sub APIs. Essentially, an external app " inserts " a record into the event object (e.g., Order_Event__e). Since platform events are treated as a special type of Salesforce object, the standard API create call acts as the publishing mechanism.

Option A is incorrect because the Streaming API is used for subscribing to events, not for publishing them. Option B is incorrect because Outbound Messages are a legacy SOAP-based notification tool and do not publish platform events. Option D is incorrect because Entitlement Processes are service-level management tools and are not part of the event-driven architecture.

For internal apps, platform events can also be published via Apex (using EventBus.publish()) or declaratively using Flow Builder. The key takeaway for external integration is that publishing is handled via standard Salesforce APIs, making it accessible to any system capable of making an HTTP request.

Testing asynchronous Apex (such as @future methods, Batchable, or Queueable classes) requires a specific mechanism to ensure that background tasks complete before the test verifies the results. In a standard execution, asynchronous jobs are queued and run whenever system resources are available, which means a test ' s assertion statements might execute before the background job has even started. To address this, Salesforce provides the Test.startTest() and Test.stopTest() methods. 78

When t 9 he code that initiates an asynchronous process is placed between Test.startTest() and Test.stopTest(), the platform behaves di 10 fferently. All asynchronous calls made within this block are collected and held by the system. As soon as the 11 code reaches Test.stopTest(), the test execution pauses, and the system forces all queued asynchronous jobs to ru 12 n immediately and synchronously within the same thread. Once Test.stopTest() finishes, the execution continues to the next line. By placing assertions immediately after Test.stopTest(), the developer is guaranteed that the asynchronous logic has finished its work. This is the only supported way to reliably test the side effects of background processes. Other options, like using System.runAs() or seeAllData=true, do not affect the timing of asynchronous execution and will likely result in failed assertions.