A DBA disables server auditing on the lock-lab SQL server “because the water-quality database already has its own audit.” What is the correct guidance?
Select an answer to reveal the explanation.
Short Explanation
Database audit is an extra camera in one room. Server audit is the building system—don’t rip out the building cameras because one lab already has a webcam.
Full Explanation
Server-level auditing provides estate-wide coverage for databases on the logical server or managed instance. A database-level audit adds more granular or additional coverage for a specific water-lab database; it does not replace or obsolete the server audit. Keeping server auditing enabled while a database audit exists is correct. Disabling server auditing whenever any database audit exists reintroduces gaps for every other database and for newly created ones. Dynamic data masking changes how results appear to non-privileged callers; it does not log SELECT activity and cannot replace auditing. Moving “auditing” into NSG flow logs captures network five-tuples, not SQL principal actions on tables and logins. Exam caveat: duplicate events can appear when both levels audit similar actions—tune destinations and queries rather than tearing out server coverage. Operational check: with both audits enabled, create a login failure against a database that also has a database audit, confirm server-level pipeline still receives estate events for other databases, and document which workspace tables or storage prefixes security operations should query first. Treat database auditing as additive instrumentation for sensitive labs, not a reason to dismantle server-wide logging for the rest of the estate.