How to Audit Two Dataverse Account Columns
Short answer
CD Enable auditing for the Account table, then enable auditing on the two specific columns so Dataverse logs only those column changes.
Question
You plan to implement Microsoft Dataverse. You must track changes for two columns in the Account table. You must maintain a historical log of changes for the two columns and track only what is necessary. You configure the appropriate organization settings. You need to configure the system to track changes for the two columns. Which two actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.
Key Takeaways
The question tests the difference between change tracking (used for data integration/sync) and auditing (used for a historical log), and the trap is assuming column-level auditing works without first enabling auditing at the table level.
In Microsoft Dataverse, maintaining a historical log of column changes means using auditing, not change tracking. Because the organization-level audit setting is already configured, you must enable auditing on the Account table and then enable auditing on the two specific columns, yielding answers C and D.
Common mistake: The most common wrong pick is A and B (change tracking for the columns and the table). Learners confuse change tracking—which exposes a row-level watermark for dataflows, Synapse Link, and other sync scenarios—with auditing, which is the only mechanism that stores a per-column historical log of old and new values.
Expert Analysis
Why the Answer Is Correct
Because the question says you already "configure the appropriate organization settings" (organization-level auditing is on) and you need to "maintain a historical log of changes," auditing is the required feature. Dataverse auditing is hierarchical: auditing must be turned on for a table before any of its columns can be audited, so enabling auditing for the Account table (C) is a prerequisite. Once table-level auditing is on, you enable auditing on the two specific columns (D), and Dataverse then records every change to only those columns, satisfying the "track only what is necessary" requirement and minimizing audit log size and performance overhead.Why the Other Options Are Wrong
Options A and B describe change tracking, which is not an auditing feature. Change tracking records only a row-level modification timestamp/watermark so that downstream consumers (dataflows, Synapse Link, virtual tables, Dataverse to SQL sync) know which rows changed—it does not store a historical record of previous column values. Enabling change tracking for the columns or for the Account table would therefore fail the requirement to "maintain a historical log of changes for the two columns." Additionally, changing tracking itself is applied at table level, not per column, so option A misrepresents how the feature works. Auditing cannot be scoped to columns alone in a self-contained way: without the table-level switch, the column-level settings have no effect, which is why C alone is insufficient.Community Comment Notes
The community comments are short but consistent: both exam_upskill and FabiolaRT selected the auditing pair, with FabiolaRT stating "Correct answer: C. Enable auditing for the Account table D. Enable auditing for the thow specific columns." No commenter argued for change tracking, and their reasoning aligns with Microsoft's documented auditing model, so the two-vote consensus here matches the technical analysis rather than merely reflecting vote popularity.Official Reference
Exam Strategy
On PL-410/AB-410, keywords decide the feature: "historical log," "audit trail," or "who changed what and when" mean auditing; "sync," "dataflow," "Synapse Link," or "which rows changed" mean change tracking. Remember auditing is enabled top-down (organization → table → column), so table-level auditing must accompany any column-level auditing selection.
Frequently Asked Questions
Why is enabling change tracking for the Account table wrong here?
Change tracking only flags which rows changed for integration tools like dataflows or Synapse Link; it stores no old/new column values, so it cannot maintain a historical log.
Do I need to enable auditing at the table level if I only audit two columns?
Yes. Column-level auditing is ignored unless auditing is enabled for the table (and at the organization level), so the Account table switch must be turned on first.
Discussion 2 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded.
From public community threads 2
-
FabiolaRT 👍 1Correct answer: C. Enable auditing for the Account table D. Enable auditing for the thow specific columns
-
exam_upskill 👍 1C. Enable auditing for the Account table. D. Enable auditing for the two specific columns
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.