SF-Data-Arch Large Data Volume Considerations Practice Question
You are auditing a Salesforce environment and discover a custom object with 20 million records. Users report that searching for records by a custom field 'External_ID__c' is extremely slow. What is the most appropriate action to take?
⚠ Common exam trap
Candidates often assume that standard fields like Name or Id are the only ones automatically indexed, forgetting that custom fields require explicit configuration like marking them as External ID or Unique.
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
✓
Mark the field as an External ID to trigger an automatic index.
When an object has large data volumes, non-indexed fields cause full table scans, which are highly inefficient and slow. By marking the 'External_ID__c' field as an External ID or unique field, Salesforce automatically creates a database index. This allows the query engine to perform a targeted lookup rather than scanning all 20 million records, providing an immediate and significant performance improvement for queries and searches involving that specific field.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a custom report type to better filter the data.
Why it's wrong here
Report types change how data is displayed and summarized but do not change how the underlying database executes queries. Even with a custom report type, the database engine will still perform a full table scan if the underlying filter fields are not indexed properly.
- ✓
Mark the field as an External ID to trigger an automatic index.
Why this is correct
Marking a field as an External ID (or unique) creates a database index. This is a standard Salesforce optimization for large objects, ensuring that queries filtering on that field become highly performant by avoiding full table scans, which are the primary bottleneck for large-scale record retrieval.
- ✗
Increase the batch size of the user's list view.
Why it's wrong here
Increasing the batch size of a list view does not address the underlying query inefficiency. If the list view filter criteria are not indexed, the query will still perform a full table scan, regardless of how many records are displayed per page to the end user.
- ✗
Convert the custom object into a Big Object.
Why it's wrong here
Big Objects are designed for massive datasets in the billions, but they have significant limitations regarding DML operations and query flexibility. Converting a 20-million-record object just for search performance is architectural overkill when standard indexing can resolve the issue with minimal impact on current functionality.
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.