SF-Data-Arch Data Modeling and Database Design Practice Question
An org has a custom object 'Invoice__c' with a Lookup to Account. Users frequently complain that deleting an Account leaves orphaned Invoice records, and reports show Invoices with no Account. The business wants the platform to prevent an Invoice from being saved without a valid Account. Which change should the architect make?
⚠ Common exam trap
The trap here is relying on page layout requirements or validation rules, which can be bypassed or do not stop parent deletion, instead of a Master-Detail relationship that enforces integrity natively.
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
✓
Convert the Lookup to a Master-Detail relationship from Invoice__c to Account.
A Master-Detail relationship enforces the parent reference at the data layer, so records cannot be saved without a valid Account and referenced Accounts cannot be deleted while children exist. This is the native way to eliminate orphaned child records across UI, API, and data-load paths.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Convert the Lookup to a Master-Detail relationship from Invoice__c to Account.
Why this is correct
Master-Detail makes the parent reference mandatory at the database level, so an Invoice cannot be saved without a valid Account regardless of whether it is created in the UI, via API, or through data loading. It also blocks Account deletion while Invoices exist, directly resolving the orphaned-record problem.
- ✗
Mark the Lookup field as required on the page layout only.
Why it's wrong here
A page layout requirement only affects the user interface and does not enforce the rule for API inserts, data loads, or Flow-created records. Orphaned Invoices would still be possible through integrations, so this does not satisfy the requirement for platform-level prevention across all entry points.
- ✗
Create a validation rule that checks whether the Account field is blank.
Why it's wrong here
A validation rule can require the Account field to be populated, but it does not by itself prevent an Account from being deleted while Invoices reference it, and it must be maintained across profiles and record types. It is a weaker, partially redundant control compared with a Master-Detail relationship that enforces the rule natively.
- ✗
Enable a duplicate rule that flags Invoices with a null Account.
Why it's wrong here
Duplicate rules identify matching records and offer alert or block behavior for duplicates; they have no mechanism to require a parent lookup or prevent orphaned children. This option misapplies a matching feature to a referential integrity problem, so it will not stop Invoices from being saved without an Account.
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.