SF-Data-Arch Salesforce Data Management Practice Question
A data architect is designing a data retention policy for a custom object Event_Log__c that stores 20 million records per year. The business requires that records older than 2 years be archived but still accessible for occasional reporting. What is the most appropriate approach?
⚠ Common exam trap
The trap here is assuming that deleting or moving records to another standard object solves archival needs, when only Big Objects provide the scale and query capability required for massive historical data.
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 Salesforce Big Objects to store archived records and query them via Async SOQL.
For high-volume, low-access data that must be retained and occasionally queried, Big Objects with Async SOQL provide a scalable, cost-effective archival solution. They allow storage of billions of records without impacting standard object performance. Deletion or moving to another custom object does not address the scale and accessibility requirements. Field history tracking is not a full archival mechanism.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable field history tracking on all fields and rely on it for archival.
Why it's wrong here
Field history tracking only retains changes for up to 18-24 months and is limited to 20 fields per object. It does not store full records and cannot serve as an archive for complete records. It is also not queryable for reporting in the same way as records. This option misunderstands the purpose of field history.
- ✗
Move records to a custom object with a lookup to the original record and use standard reports.
Why it's wrong here
A custom object still counts against storage limits and does not provide the scalability of Big Objects for 20 million records per year. While it keeps data accessible, it does not solve the long-term storage cost and performance issues. This approach may also hit governor limits and degrade reporting performance as data grows.
- ✗
Create a scheduled batch job that deletes records older than 2 years.
Why it's wrong here
Deleting records would violate the requirement that archived data remain accessible for occasional reporting. The business needs to retain the data, not remove it. A deletion job also moves records to the Recycle Bin, which is purged after 15 days, making recovery impossible. This approach fails to meet the retention and accessibility needs.
- ✓
Use Salesforce Big Objects to store archived records and query them via Async SOQL.
Why this is correct
Big Objects are designed for massive data volumes and provide cost-effective storage with asynchronous query capabilities via Async SOQL. They allow the organization to retain records beyond the standard object limits while keeping them accessible for occasional reporting. This approach aligns with data archiving best practices for high-volume, low-access data.
Visual reference
About these practice questions
This SF-Data-Arch question is part of Courseiva's 222-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-Data-Arch 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-Data-Arch exam.