PDII Practice Test Questions

Explanation:

When dealing with a large volume of records—around 100,000 Opportunities in this case—Batch Apex is specifically designed to handle such heavy data processing while staying within Salesforce governor limits. By implementing a class that implements the Database.Batchable interface, the developer can process the Opportunities in manageable chunks. This approach allows for complex logic to be applied on each batch, ensuring that Revenue records are created and populated efficiently.

Using Database.executeBatch() to run the batch class is the optimal solution since it allows:

Efficient processing: Processes records in batches, thereby avoiding hitting governor limits.
Scalability: Handles large datasets that might cause issues in a synchronous process.
Flexibility: Batch classes can include complex business logic required for the seeding process.

Other options, like using Queueable Apex, are not ideal for processing such a large volume of records due to limitations in chaining and processing in a single asynchronous context. Likewise, scheduling via a Schedulable class is not directly designed for high-volume data processing compared to Batch Apex.

Explanation:

Native Error Event Handling

Salesforce automatically publishes the BatchApexErrorEvent standard Platform Event when an unhandled exception occurs in a batch job.
No custom code is needed to fire this event—it’s built into Salesforce.

External System Integration

The external system can subscribe to BatchApexErrorEvent via:

CometD (Streaming API).
Change Data Capture (CDC). Middleware (e.g., MuleSoft).

The event payload includes:

AsyncApexJobId (failed batch job ID).
ExceptionType (e.g., NullPointerException).
Message (error details).

Implementation Steps

No Apex Required: The batch job needs no modifications.
External System: Configures a subscription to the standard BatchApexErrorEvent.

Explanation:

Why this is likely correct:

In Apex test classes, Test.startTest() and Test.stopTest() are used to:
Reset governor limits so you get a clean slate for measuring execution.
Ensure any asynchronous processes (like future methods, queueables, batch jobs) are executed during Test.stopTest().
If Line 18 is where a trigger or async logic is being tested (e.g., inserting a record that fires a trigger), this is where you want the limits reset and async execution completed.

Why the other options are likely incorrect:

A. Add Test.startTest() / stopTest() around Line 7 and 20
❌ You can only call startTest() and stopTest() once per test method. Doing it more than once throws an error.

C. Use Limits.getLimitQueries()
❌ This method retrieves limits, but does not solve errors. It's diagnostic, not a fix.

D. Change DataFactory to create fewer Accounts
❌ This is a workaround, not a fix. Also, test data volume should match realistic use cases.
Reducing records just to avoid hitting limits may mask real problems.

Explanation:

For a query to be considered selective on a large object (such as 200,000 Account records), at least one of the filters must leverage an indexed field and reduce the result set to less than a system-defined threshold (typically less than 10% of the total records).

Here’s why options C and D qualify:

Option C:

Name IN (List of Names) uses a filter on the Name field along with
Customer_Number__c = 'ValueA', an equality filter on a custom field. If the custom field is indexed (for example, if it is configured as an External ID, Unique, or via a custom index), then filtering by it with an exact match is selective. Combined with the IN clause on the Name field, this query can effectively narrow the data set even in a large table.

Option D:

WHERE Id IN (List of Account Ids) uses the Account Id field, which is the primary key and inherently indexed. When the IN list contains a limited number of values relative to the full dataset, this query is highly selective.

Comparatively, the other options are problematic:

Option A: Using a condition like Name LIKE '!-NULL' is ambiguous and does not clearly reflect a selective filter, especially if it would return a very large result set.

Option B: The condition WHERE Name != '' is non-selective as it likely returns nearly all records in the object, making it unsuitable for a large dataset.

Explanation:

When a trigger updates a record, such as the Opportunity trigger updating the custom Last Sold Date on its related Account, those changes occur in the database. In test methods, if you don't re-query the Account record after the Opportunity update, you're still holding a stale instance of that Account in memory. As a result, your assertions will be checking the old data rather than the updated values. Therefore, re-querying the Account record ensures that you assert against the current database state, reflecting the updates made by the trigger.

Explanation:

In Salesforce SOQL, to query all fields of a sObject, you use the special FIELDS(ALL) syntax. This works only in sandbox and developer orgs, and is particularly useful for debugging or exploratory queries.

SELECT FIELDS(ALL) FROM Account WHERE Name = 'Acme' LIMIT 1

FIELDS(ALL): Includes all standard and custom fields of the Account object.
LIMIT 1: Best practice to limit the result to a single record when querying by a unique or semi-unique field like Name.

Why the other options are incorrect:

A. SELECT FIELDS FAOM Account
❌ Typo in FAOM — should be FROM. Also missing (ALL).

C. SELECT ALL FROM Account
❌ SELECT ALL is not valid SOQL syntax.

D. SELECT * FROM Recount
❌ SELECT * is SQL, not SOQL.
❌ Recount is likely a typo for Account.

Explanation:

Why Asynchronous Apex is Required?

Trigger Context Limitations
Apex triggers run synchronously and cannot make direct callouts (HTTP/SOAP) due to Salesforce’s transaction rules.
Solution: Use @future(callout=true) or Queueable Apex to decouple the callout from the trigger.

Implementation Example

trigger OpportunityTrigger on Opportunity (after update) {
if (Trigger.isAfter && Trigger.isUpdate) {
// Queueable or @future for callouts
System.enqueueJob(new CalloutAsync(Trigger.newMap.keySet()));
}
}
public class CalloutAsync implements Queueable, Database.AllowsCallouts {
Set oppIds;
public CalloutAsync(Set oppIds) { this.oppIds = oppIds; }
public void execute(QueueableContext ctx) {
HttpRequest req = new HttpRequest();
req.setEndpoint('https://api.example.com');
new Http().send(req); // Callout allowed here
}
}


Why Not the Other Options?

A. Querying records
Can be done synchronously (e.g., [SELECT ... LIMIT 50000]).

B. Scheduling a batch
System.scheduleBatch() is synchronous (though the batch itself runs async).

D. Post-insert updates
Can use synchronous triggers or Process Builder.

Explanation:

In Aura, when you need to allow loosely coupled components that are not in a parent-child relationship to communicate, you should use an Application Event. In this scenario, the guest self-registration component and the utility tray component are independent, and the utility tray needs to react whenever a guest is registered. An Application Event can be fired by the registration component and broadcast across the entire Lightning application, so the utility tray component can subscribe to it and display the appropriate alert.

Example:

Why Batch Apex?

Governor Limit Solution

Batch Apex processes records in smaller chunks (default 200 records per batch), avoiding:
DML row limits (10,000 per transaction).
CPU timeout (10 minutes per transaction).
Automatically handles large data volumes (e.g., 10,000+ records).

Implementation Example

global class ScheduledBatch implements Database.Batchable, Schedulable {
global Database.QueryLocator start(Database.BatchableContext bc) {
return Database.getQueryLocator([SELECT Id FROM Account WHERE Needs_Processing__c = true]);
}
global void execute(Database.BatchableContext bc, List scope) {
// Process 200 records at a time
update scope;
}
global void finish(Database.BatchableContext bc) {
// Optional: Notify admin or chain another job
}
global void execute(SchedulableContext sc) {
// Invoke the batch from the scheduler
Database.executeBatch(this);
}
}

Schedule the Batch:

System.schedule('Daily Batch', '0 0 12 * * ?', new ScheduledBatch());

Explanation:

When a Visualforce page (or any Apex logic) updates a record, the changes are saved in the database, but any in-memory instances already queried before the update will not reflect those changes. In this case, after the page reassigns the Account ownership to the queue, the test method needs to re-query the Account record to retrieve the latest field values from the database. Failing to do so will result in an assertion failure, as the test is still holding an outdated version of the Account record.