An auditor asks the DBA to demonstrate who connected to the production database, from which host or IP address, and when, including failed attempts. What should the DBA configure?
Select an answer to reveal the explanation.
Short Explanation
If the question is who knocked on the door, when, and whether they got in, you need a doorbell camera, not a record of what they did inside. Login and connection auditing captures exactly that, including the failed knocks. DDL auditing is the trap; it tracks schema changes, not who connected.
Full Explanation
Connection auditing records authentication events at the database: the login name, the client host or IP address, the time, the application where available, and whether the attempt succeeded or failed. Capturing failed attempts is important because repeated failures can indicate password guessing or misconfigured services, while successful logins from unexpected addresses can indicate stolen credentials. The audit records should be written to protected storage or forwarded to a central log management or SIEM system so database administrators cannot quietly alter them. Data definition language auditing captures CREATE, ALTER and DROP activity, which is valuable for change control but says nothing about who connected or from where. Query performance monitoring collects plans and timings to tune workload and is not designed as a security record of access. Backups preserve data for recovery, but they do not record connection activity at all. Exam caveat: auditing every event can generate large volumes, so the audit specification should target connection events and the retention period required by policy. Operational check: perform a test login, including a deliberately failed attempt from a known workstation, and confirm both events appear in the central log with correct user, address and timestamp.