SF-PD2 Process Automation, Logic, and Integration Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use a single Schedulable class that implements both Schedulable and Queueable interfaces, and invoke it directly from the trigger with Database.executeBatch.

  Why it's wrong here

  A class cannot meaningfully serve as both the scheduled entry point and the on-demand asynchronous worker without still duplicating invocation logic, and Database.executeBatch expects a Database.Batchable implementation, not a Queueable. The trigger would fail to compile or throw at runtime because the batch interface methods are absent.

• ✓

  Create a Schedulable class that enqueues HealthScoreQueueable, and from an Account trigger call System.enqueueJob with the same Queueable after checking that no matching job is already queued.

  Why this is correct

  Reusing the same Queueable from both entry points keeps the calculation logic in one place. The Schedulable wrapper satisfies the nightly schedule, while the trigger enqueues the identical class on demand; guarding with a check such as AsyncInfo or a custom flag prevents duplicate queued jobs from stacking up during rapid updates.

• ✗

  Implement the calculation directly inside the Account trigger using synchronous Apex, and schedule a separate Schedulable class that duplicates the same calculation logic for the nightly run.

  Why it's wrong here

  Duplicating the calculation in two places violates the least-duplication requirement and creates a maintenance hazard where the two copies drift apart. Synchronous trigger logic also consumes the same governor limits as the user's transaction, so bulk Account updates could hit CPU or SOQL limits that an asynchronous Queueable would avoid.

• ✗

  Configure two separate scheduled jobs in Setup, one for nightly execution and one that runs every minute during business hours to detect Account changes and enqueue the Queueable.

  Why it's wrong here

  Polling every minute to detect changes is wasteful and introduces up to sixty seconds of latency, so the immediate recalculation requirement is not truly met. It also consumes scheduled job slots and asynchronous executions unnecessarily, and detecting changes by querying LastModifiedDate can miss rapid successive updates within the polling window.