SF-PD2 Process Automation, Logic, and Integration Practice Question
A company requires that an integration log all outbound API requests for auditing purposes, including the full request and response body. Given the potential for high volumes, which implementation is most efficient and compliant?
⚠ Common exam trap
Candidates often suggest synchronous logging or standard DML operations within the callout transaction, which risks hitting governor limits or causing performance degradation during heavy loads.
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 Platform Events to log the data asynchronously in a separate transaction.
Using a Platform Event to log integration data is the most efficient pattern. Because the logging happens asynchronously, it doesn't block the main business transaction. By publishing an event, a separate subscriber can handle the heavy lifting of storing the log in a custom object, ensuring the primary business operation remains performant while maintaining an audit trail for all outbound communications.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Insert a record into a custom 'Log' object synchronously within the integration class.
Why it's wrong here
Synchronous logging within the integration class adds significant overhead and consumes governor limits, especially during high-volume operations. If the logging process fails or times out, it could negatively impact the primary business transaction, leading to data inconsistencies or performance bottlenecks for the main integration process.
- ✓
Use Platform Events to log the data asynchronously in a separate transaction.
Why this is correct
Platform Events allow for asynchronous, decoupled logging. The integration publishes the event and finishes the transaction immediately. A background process then handles the persistence of the log data. This ensures high performance for the main process and provides a reliable way to capture audit data without stressing governor limits.
- ✗
Store the logs in a static variable and write to the database at the end of the day.
Why it's wrong here
Static variables are not persistent; they only last for the duration of a single transaction. If the integration is running in multiple transactions, data will be lost. Furthermore, relying on memory for logging is dangerous and violates the requirement for a reliable, permanent audit trail across the system.
- ✗
Write the logs to the Debug Log and parse them later using a log monitoring tool.
Why it's wrong here
Debug logs are meant for debugging and have strict limits. They are not designed for long-term audit storage or structured integration logging. Attempting to use them for audit purposes will lead to incomplete data and log truncation, which is not compliant with auditing requirements for integration monitoring.
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.