Exam Certified Platform Developer II topic 1 question 62 discussion

B Explanation "Takes a snapshot of accounts as they are" - this is all accounts - cannot be process builder for that reason, can not be future either, has to be queueable so you can queue each account one after the other.

A. @future Explanation: When you need to perform a callout from within Apex—especially from a trigger—it must be done asynchronously. Using the @future annotation with the callout=true parameter enables callouts from asynchronous methods. In this scenario, each Account record's snapshot is sent to an external RESTful web service, and since the web service accepts only one record per call, the @future method can handle each Account individually in an asynchronous context. Why not B. Queueable: Queueable Apex offers additional features like job chaining and improved job handling, but these benefits are generally more useful in scenarios requiring complex processing or managing multiple related jobs. In this case, the processing is simple—making a single callout per record—so the added complexity of Queueable is unnecessary.

B is correct: The requirement states that a snapshot of Account records must be taken as they are saved and then sent to an external system. Since Apex triggers execute synchronously, a callout cannot be made directly. However, a Queueable class allows asynchronous processing with callouts using System.enqueueJob(). Since the external system can only receive one record per call, a Queueable job is a good fit because it allows each record to be processed individually. Why C is not correct: Process Builders cannot make HTTP callouts, making them unsuitable for this requirement.

i think it is C because if you use queueable either you make a for loop through the account list but it is limited to 50 queueable Or you chain the queueable but you should find a way to know which account you have processed, it means pass the list of account throught each queueable and remove the one that is processed before pass it to the next queueable you risk to be limited without a querylocator system and i am not sur it is possible due to then depth of the queueable that is limited

I go with B for the same reason as @Dev_Bond_ZA

correct ans is B

I go with B for the same reason as @Dev_Bond_ZA

C is correct. Call the invocable method from process builder and from invocable method call the @future method and write your callout logic there in @future method.

C is right. Queustion says "The web service can only receive, at most, one record per call.". A,B can call multiple record.

For me it is A. You need to write APEX code even if you use Process Builder. So I would directly code a APEX trigger and an @future method. If Process Builder would be aber to do direct API calls, like Flow it would be fine for me. If Flow would be a choice, then I would take Flow

This is correct as Salesforce prefers declarative first, so although @future would be used if it was a trigger, since PB is declarative, it would use this with an @InvocableMethod instead. Today, this would be done with a flow based trigger.

Process Builder + InvocableMethod marked with (callout=true)

C should be correct ,like Call the invocable method from process builder and from invocable method call the @future method and write your callout logic there in @future method.

It should be A, as it will call Restful web service and it is a slow process