SF-Data-Arch Data Modeling and Database Design Practice Question
A Data Architect is designing a high-volume data model where an Account has millions of Child records. Which TWO strategies should be implemented to ensure optimal performance and avoid data skew?
⚠ Common exam trap
Candidates often propose increasing batch sizes or adding more hardware, failing to realize that data skew is a structural issue requiring redistribution of ownership or proper indexing.
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
✓
Ensure that the owner of the parent records is not a single user or small group.
Performance issues in Salesforce often arise from data skew, where a small number of parent records own a vast majority of child records. Implementing strategies like record ownership distribution and utilizing indexing on high-cardinality fields prevents row-level locking contention. These design patterns are critical for maintaining query performance and ensuring that API operations do not time out during large-scale data processing or complex analytical reporting cycles.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Ensure that the owner of the parent records is not a single user or small group.
Why this is correct
When one user owns a large volume of child records, record locking can occur during updates to the parent record. Distributing ownership across multiple users helps alleviate contention, as the platform's locking mechanism is often tied to the parent record's owner and sharing rules in the underlying database.
- ✗
Convert all Lookup relationships to Master-Detail relationships to improve query speed.
Why it's wrong here
Master-Detail relationships actually increase the likelihood of locking contention because they force child records to be locked when the parent is modified. This is the opposite of the desired behavior for high-volume scenarios where you want to minimize the impact of parent-level updates on child performance.
- ✗
Avoid using custom indexes on fields that have high cardinality.
Why it's wrong here
High-cardinality fields, such as external IDs or unique identifiers, are the best candidates for custom indexes. Indexing these fields allows the Salesforce query optimizer to quickly filter records, significantly reducing scan times and improving the efficiency of SOQL queries performed against large datasets in the database.
- ✗
Avoid creating parent-child relationships where the parent is a 'Person Account'.
Why it's wrong here
Person Accounts are valid parent records and do not inherently cause performance issues. The primary concern is the distribution of records under the parent, not the record type itself. Focusing on record distribution and indexing is far more impactful than restricting the use of specific Salesforce record types.
- ✓
Index the foreign key fields used for reporting and filtering.
Why this is correct
Indexing foreign key fields is essential for query optimization. Without an index, large volume queries result in full table scans, which are resource-intensive and slow. By ensuring that relationship fields used in WHERE clauses are indexed, architects significantly improve the overall system response time during data retrieval.
About these practice questions
Courseiva writes every SF-Data-Arch question from scratch — 222 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.