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.

• ✗

  Use Database.query with a bind variable inside the loop to dynamically build the query.

  Why it's wrong here

  Using Database.query inside the loop still executes a query for each iteration, which counts against the governor limit. Dynamic SOQL does not inherently reduce the number of queries; it only changes how the query is constructed. The fundamental issue of querying inside a loop remains, so the error will still occur.

• ✗

  Use a SOQL query with a LIMIT clause inside the loop to reduce the number of records returned.

  Why it's wrong here

  Adding a LIMIT clause inside the loop does not reduce the number of queries executed; it only limits the number of records returned per query. The governor limit counts the number of queries, not the number of records. This approach still results in one query per loop iteration, so the error persists.

• ✗

  Enable deferred sharing on the trigger to reduce the number of SOQL queries.

  Why it's wrong here

  Deferred sharing (with sharing or without sharing) affects record-level access and query performance but does not reduce the number of SOQL queries executed. It controls whether the trigger runs in system or user mode, which can impact which records are returned, but it does not address the governor limit for the number of queries.

• ✓

  Move the SOQL query outside the loop and use a Map to store the results for lookup.

  Why this is correct

  Moving the SOQL query outside the loop and storing results in a Map is a best practice for bulkification. It reduces the number of queries to one, regardless of the number of records processed. The Map allows efficient lookup of existing records by a key, such as a unique field, avoiding repeated database calls within the loop.