SF-PD2 Advanced Developer Fundamentals Practice Question
A developer is designing a Queueable Apex job that must process a large set of records and then enqueue additional work. The developer wants the job to be robust and to observe platform limits. Which two statements about Queueable Apex are correct? (Choose two.)
⚠ Common exam trap
The trap here is assuming Queueable chaining is unlimited and that jobs share the caller's governor limits, when both assumptions are false.
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
✓
A Queueable class can accept complex data types as constructor parameters, including sObject records, and retain them when the job executes.
Queueable Apex supports chaining by enqueuing another job from the execute method and allows complex constructor parameters such as sObjects to be serialized and carried into the asynchronous execution. These two properties make it well suited to multi-step processing with state. Chaining is bounded, jobs run in their own transaction with fresh limits, and callouts are permitted subject to the normal ordering rule, so the remaining statements misstate how the feature behaves.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A Queueable job can be chained indefinitely with no depth limit, so the developer never needs to plan for chain termination.
Why it's wrong here
Chaining is bounded by a platform limit on the number of jobs in a chain, and exceeding it throws a limit exception that terminates the remaining work. Developers must design chains to terminate or hand off to another mechanism such as a scheduled job or batch process. Treating chaining as unlimited leads to runtime failures in production when data volume grows beyond what a single chain can handle.
- ✓
A Queueable class can accept complex data types as constructor parameters, including sObject records, and retain them when the job executes.
Why this is correct
Unlike future methods, Queueable Apex permits non-primitive constructor parameters such as sObjects and collections, because the job state is serialized and stored until execution. This lets a developer pass a list of records or a custom wrapper into the job without re-querying. The serialized state must remain within size limits, but the ability to carry complex types is a defining advantage over future methods.
- ✓
A Queueable class can be chained by enqueuing another Queueable job from within the execute method, allowing multi-step processing.
Why this is correct
Chaining is a core capability of Queueable Apex: from inside the execute method, the job can enqueue another Queueable job, which continues processing in a new transaction with fresh governor limits. This makes Queueable suitable for multi-step or staged processing where one step depends on the result of the previous step. The chain depth is bounded by platform limits, so developers should plan for that ceiling.
- ✗
A Queueable job cannot perform a callout under any circumstances, so external integrations must use future methods instead.
Why it's wrong here
Queueable Apex does support callouts, and in fact it is often preferred for integrations because it can carry complex state and chain follow-up work. The restriction that applies is the general callout-after-DML ordering rule, not a blanket prohibition. Claiming Queueable cannot call out at all is incorrect and would steer the developer away from a capable and commonly used integration pattern.
- ✗
A Queueable job runs synchronously within the transaction that enqueued it, so its governor limits are shared with the caller.
Why it's wrong here
Queueable jobs run asynchronously in their own transaction, not inside the caller's transaction. They receive a fresh set of governor limits, which is one reason developers choose Queueable over synchronous processing for heavy work. Sharing limits with the caller would defeat the purpose of asynchronous execution and would also make the caller wait for completion, which is not how the platform schedules these jobs.
About these practice questions
One of 226 original SF-PD2 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.