SF-PD2 Advanced Developer Fundamentals 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.

• ✗

  Using the @future annotation for each record update.

  Why it's wrong here

  Using @future for individual updates is highly inefficient and will hit the limit on the number of asynchronous requests allowed per 24-hour period. It also makes it difficult to manage dependencies between jobs and offers no mechanism for job chaining, unlike the more modern Queueable interface.

• ✓

  Implementing the Queueable interface.

  Why this is correct

  Queueable Apex is the modern standard for asynchronous work. It allows for complex logic, supports stateful variables, and enables job chaining (calling one job from another). This makes it vastly more flexible and scalable than older patterns, while also providing a higher governor limit for processing large volumes of data.

• ✗

  Using Database.executeBatch with a scope of 1.

  Why it's wrong here

  A scope of 1 is extremely inefficient. While Batch Apex is good for huge datasets, using a tiny scope size increases the total number of transactions significantly, which wastes system resources. Queueable Apex is generally better for dynamic, smaller-to-medium-sized asynchronous tasks that don't require the full Batch processing lifecycle.

• ✗

  Wrapping all updates in a single @ReadOnly transaction.

  Why it's wrong here

  @ReadOnly is used to increase the SOQL limit for read-only operations. It does not allow DML operations to be performed. Attempting to execute DML in a read-only context will cause a runtime exception, as the primary goal of this annotation is to strictly enforce read-only database interactions.