SF-PD2 Performance Practice Question
A developer is building an Apex trigger on a high-volume custom object that must update a related child record whenever a parent record's Status__c changes. The trigger runs for both single-record UI edits and bulk API loads of 200 records. The developer wants to avoid a per-record SOQL query inside the trigger loop. Which approach is the most performant and scalable?
⚠ Common exam trap
The trap here is assuming that moving a query into a helper method or using dynamic SOQL changes the governor limit, when any query executed once per loop iteration still consumes one SOQL query per record.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Move the child query outside the loop and use a Map keyed by the parent Id, then iterate the trigger records against that Map.
Collecting the related children in a single query before the loop and indexing them by parent Id in a Map eliminates per-record SOQL, keeping the trigger within governor limits and bulk-safe. This pattern is the standard bulkification technique for parent-to-child updates and scales correctly for both single-record and 200-record API transactions.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Rely on a formula field on the child that references the parent's Status__c so no query is required in the trigger.
Why it's wrong here
A cross-object formula field can display a parent value on the child, but it cannot be used to perform a DML update on the child when the parent changes, and it cannot store a value that other logic can write. It also does not solve updating a persisted field, so it does not meet the stated requirement.
- ✗
Use Database.query() inside the loop with a dynamically built WHERE clause for each parent record.
Why it's wrong here
Database.query() still consumes one SOQL query per loop iteration, so it hits the same 100-query governor limit as an inline SOQL statement. Dynamic SOQL adds string-building overhead and loses compile-time validation without fixing the underlying per-record query problem, making it worse rather than more scalable for bulk trigger execution.
- ✓
Move the child query outside the loop and use a Map keyed by the parent Id, then iterate the trigger records against that Map.
Why this is correct
Querying the related child records once before the loop, storing them in a Map keyed by the parent relationship Id, and then iterating Trigger.new against that Map removes the per-record query from the loop. This keeps the code bulk-safe, avoids hitting the 100 SOQL query governor limit, and scales to 200-record batches without additional DML or query overhead.
- ✗
Add a SOQL query inside the loop that filters on the current record's Id to fetch the matching child.
Why it's wrong here
A SOQL query inside a trigger loop executes once per record, so a 200-record bulk load issues 200 queries. Apex allows only 100 synchronous SOQL queries per transaction, so the trigger fails with a System.LimitException on bulk loads. Even at low volume it is a governor-limit and performance anti-pattern that Salesforce explicitly warns against.
About these practice questions
Courseiva writes every SF-PD2 question from scratch — 226 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Salesforce exam blueprint
This SF-PD2 practice question is part of Courseiva's free Salesforce certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SF-PD2 exam.