SF-Data-Arch Data Governance Practice Question
The governance board at a financial services firm wants to know when critical fields on the Opportunity object were changed, who changed them, and what the previous value was, without writing custom code. Which native capability should the architect enable?
⚠ Common exam trap
The trap here is equating real-time notifications or scheduled snapshots with an auditable history, when only Field History Tracking natively stores prior values with user and timestamp attribution.
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 the selected Opportunity fields
The board wants a native, no-code record of when critical Opportunity fields changed, who changed them, and the prior values. Field History Tracking provides exactly that for selected fields and requires only configuration. Chatter notifications, custom Flow logging, and nightly exports each capture partial or indirect information and cannot deliver a reliable, attributed field-change history.
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 the selected Opportunity fields
Why this is correct
Field History Tracking is the native, no-code feature that records changes to selected fields, including the user who made the change, the timestamp, and the old and new values. Enabling it on the chosen Opportunity fields directly answers the governance board's question about when and by whom critical fields changed.
- ✗
Build a Flow that writes a record to a custom log object on every Opportunity update
Why it's wrong here
A Flow-based logging pattern requires custom design, maintenance, and a custom object, and it is not the native capability the requirement asks for. It also risks gaps when updates occur through paths the Flow does not cover, making it less reliable than the built-in history feature.
- ✗
Schedule a nightly Data Loader export of Opportunity records for comparison
Why it's wrong here
A nightly export captures only the end-of-day state and cannot attribute changes to a specific user or timestamp within the day. Multiple edits collapse into one snapshot, so the audit trail the governance board wants is incomplete and untrustworthy.
- ✗
Create a Workflow Rule that posts to Chatter when Opportunity fields change
Why it's wrong here
A Workflow Rule posting to Chatter notifies people in the moment, but it does not persist a structured history of old and new values, nor does it reliably record the acting user for every field. It is a notification mechanism, not an auditable field-change record, so it fails the governance need.
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.