SF-Data-Arch Data Modeling and Database Design Practice Question
A financial services org needs to record every change to the 'Credit_Score__c' field on Contact for regulatory audit, including the prior value, the new value, the user, and the timestamp. The data volume is moderate and auditors query the history by Contact. Which approach should the architect recommend?
⚠ Common exam trap
The trap here is assuming a custom audit object or Flow is required for compliance, when native Field History Tracking already records old and new values with user and timestamp.
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
✓
Enable Field History Tracking on Credit_Score__c and expose the related history list on the Contact page layout.
Field History Tracking is purpose-built to capture old value, new value, user, and timestamp for selected fields, and it surfaces that data in a related list that auditors can query and report on. For a moderate-volume regulatory need on a specific field, it avoids the overhead of a custom audit object or streaming integration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a before-save Flow to copy the previous Credit_Score__c value into a text field on Contact for comparison.
Why it's wrong here
A before-save Flow cannot reliably read the prior persisted value to compare because before-save logic operates on the incoming record state. This approach also keeps only one prior value rather than a full audit trail, so it fails the regulatory requirement to record every change with user and timestamp.
- ✗
Enable Change Data Capture on Contact and subscribe to the event channel from an external system.
Why it's wrong here
Change Data Capture streams change events in near real time but does not retain long-term history inside Salesforce for auditors to query on the record page. It requires an external consumer and storage, which adds architecture complexity that the moderate-volume, in-org audit requirement does not justify.
- ✓
Enable Field History Tracking on Credit_Score__c and expose the related history list on the Contact page layout.
Why this is correct
Field History Tracking natively stores the old value, new value, user, and timestamp for tracked fields, and the history related list is queryable and reportable. For a moderate-volume audit need focused on a specific field, this is the standard declarative solution and requires no custom object or automation.
- ✗
Create a custom object 'Credit_Score_Audit__c' with a Flow that inserts a record on every Contact update.
Why it's wrong here
A custom audit object with Flow works but adds development and maintenance overhead, governor-limit exposure, and potential gaps if the Flow fails or is bypassed by data loads. Field History Tracking already provides the same old-value and new-value capture natively, so this custom approach is unnecessary for the stated moderate-volume requirement.
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.