SF-PD2 Advanced Developer Fundamentals Practice Question
A developer needs to prevent a recursive trigger execution when updating parent records. What is the most robust way to handle this in Apex?
⚠ Common exam trap
Candidates mistakenly rely on trigger execution context variables alone without realizing they do not persist across multiple levels of cascading updates within the same transaction.
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
✓
Use a static Boolean variable in a utility class to flag execution.
Recursion control is a critical design pattern in Apex to prevent 'Maximum trigger depth exceeded' errors. By utilizing a static Boolean variable in a utility class, the developer can track the state of the execution across the current transaction. This allows the trigger logic to bypass subsequent executions, ensuring that the business logic only fires when necessary, maintaining data integrity and system stability.
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 static Boolean variable in a utility class to flag execution.
Why this is correct
Static variables in an Apex class maintain their state throughout the duration of a single transaction. By checking this flag, the trigger can detect if it has already executed and terminate immediately, effectively preventing the infinite loop that occurs when a trigger updates a record that fires the same trigger.
- ✗
Use an instance variable in the Trigger Handler class.
Why it's wrong here
Instance variables are reset every time the class is instantiated. Since trigger handlers are typically instantiated for each trigger event, an instance variable would not persist across recursive calls, making it incapable of tracking whether the code has already been executed in the current transaction's scope.
- ✗
Check the context of the transaction using the 'Limits.getTriggerDepth()' method.
Why it's wrong here
Salesforce does not provide a built-in 'Limits.getTriggerDepth()' method. While triggers have a maximum recursion depth, trying to rely on platform limits is an anti-pattern. Developers must manage their own state control via code to ensure logic is predictable and does not hit the platform's hard limits.
- ✗
Wrap all trigger logic in a try-catch block to suppress errors.
Why it's wrong here
Suppressing errors via try-catch does not resolve the underlying issue of infinite recursion. If the logic is still firing, it will continue to consume CPU and DML limits until the transaction fails, regardless of whether the exception is caught. Proper state management is required, not exception handling.
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.