How would you track who created or updated data in an EF Core-backed API?

An EF Core SaveChanges interceptor can populate UpdatedAt and UpdatedBy for entities implementing an auditable interface. For high-risk changes like permissions or payments, I would add a separate append-only audit event.

• Treating audit fields and data change tracking as a syntax detail instead of a production behavior.
• Not checking generated SQL, query plans, or actual data volume.
• Testing only with tiny local data and assuming production will behave the same.
• Fixing symptoms with caching, timeouts, or retries before understanding the data-access cause.

• Cannot explain how audit fields and data change tracking affects API behavior.
• Gives only a definition with no practical example.
• Ignores production failure modes.
• Does not know how to verify the behavior.

• When are simple audit fields enough?
• When do you need an immutable audit log?
• How should background jobs set audit actor values?
• What sensitive data should not be stored in audit logs?

Listen for practical reasoning about audit fields and data change tracking. The answer should connect EF Core or SQL mechanics to API behavior, production diagnostics, and trade-offs.

Audit fields explain when and by whom data changed, while richer change tracking may need history beyond the current row. The design affects supportability, compliance, storage, and write-path complexity.