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.

• 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.