SF-PD2 Performance 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.

• ✗

  Increase the batch size to the maximum so fewer total transactions are needed.

  Why it's wrong here

  Larger batch sizes increase the records processed per execute transaction, which raises heap and CPU usage and makes governor-limit failures more likely. While fewer transactions can reduce overhead, the per-transaction limits are the binding constraint for millions of records, so maximizing batch size is the wrong direction for a limits-bound job.

• ✗

  Call Database.executeBatch from within the execute method to parallelize the work.

  Why it's wrong here

  Starting a batch job from inside another batch job's execute method is not allowed and throws a runtime error because batch jobs cannot be chained from within a running batch context. Parallelism must be configured through the batch size and the optional scope, not by nesting executeBatch calls. This option would fail outright.

• ✗

  Perform all DML inside the start method so the execute method only reads data.

  Why it's wrong here

  The start method runs once and should only return the query locator; performing DML there is not supported for batch processing and would run outside the per-chunk transaction model. DML belongs in the execute method, where it is chunked and governed per batch. This option inverts the intended batch lifecycle and would break the job.

• ✓

  Reduce the batch size so each execute method handles fewer records, lowering heap and CPU usage per transaction.

  Why this is correct

  Smaller batch sizes reduce the number of records processed per execute transaction, which lowers heap consumption and CPU time per chunk and makes it less likely that an individual transaction exceeds limits. It also lets the job recover more gracefully because only one batch fails if an error occurs, rather than the entire chunk. The trade-off is more transactions, but for heap-bound jobs this is often the right lever.

• ✓

  Use Database.QueryLocator in the start method so the query can iterate over large result sets without hitting the 50,000-row SOQL limit.

  Why this is correct

  Database.QueryLocator lets Batch Apex process up to 50 million records because the platform streams the query results rather than materializing them under the standard 50,000-row SOQL limit. It is the recommended start-method return type for large-volume batch jobs and keeps memory usage bounded while the framework chunks records for each execute call.