SF-PD2 Performance Practice Question
A developer is troubleshooting a Lightning Web Component that calls an Apex method returning many records and notices the component re-fetches the same data every time the user navigates back to the tab. The developer wants to avoid redundant server calls for read-only data. Which change should be made?
⚠ Common exam trap
The trap here is assuming an Apex static variable caches data across requests, when static state only survives within a single 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
✓
Annotate the Apex method with @AuraEnabled(cacheable=true) and call it through a @wire adapter or wired property.
Client-side caching for read-only Apex is provided by marking the method cacheable and consuming it through @wire, which routes through Lightning Data Service. That lets the framework reuse previously fetched data instead of issuing a new server call each time the component loads, directly eliminating the redundant fetches described.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store the Apex results in a static variable in the controller so subsequent calls return the cached list.
Why it's wrong here
Static variables in Apex persist only for the duration of a single transaction, so each new server request starts with an empty static variable and re-queries. They cannot provide cross-request caching. This option confuses transaction-scoped state with the client-side cache that Lightning Data Service provides.
- ✓
Annotate the Apex method with @AuraEnabled(cacheable=true) and call it through a @wire adapter or wired property.
Why this is correct
Marking a read-only Apex method cacheable and consuming it through @wire lets Lightning Data Service cache the response on the client. When the user returns to the tab, the cached data can be reused instead of issuing a new server call, which reduces redundant round trips. Cacheable methods must not perform DML, which fits the read-only requirement.
- ✗
Move the Apex logic into a Flow and invoke the Flow from the component on each render.
Why it's wrong here
Invoking a Flow on each render still performs a server round trip every time and adds Flow execution overhead on top. It does not provide client-side caching for read-only data and does not address the repeated fetch behavior described. This option changes the technology without solving the caching problem.
- ✗
Add @AuraEnabled(cacheable=false) and call the method imperatively on every connectedCallback.
Why it's wrong here
cacheable=false explicitly disables client-side caching, and calling the method imperatively in connectedCallback fires a fresh server request every time the component initializes. That is exactly the redundant behavior the developer wants to eliminate, so this option worsens the problem rather than fixing it.
About these practice questions
This SF-PD2 question is part of Courseiva's 226-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.