Three internal applications all connect to the same database using one shared login named app_svc. After rows were deleted from a payments table, the audit log shows only that app_svc ran the DELETE, so the team cannot tell which application did it. Which change restores accountability?

Accountability requires that each action in an audit trail be attributable to a single identity. When several applications share one login, every statement is recorded under that login, so no amount of logging can separate them. Creating a dedicated login per application gives each one its own identity in the audit records, and granting each only the permissions it needs applies least privilege, so an application that only reads payments cannot delete from them at all. Raising the audit level on the shared login records more detail per statement, but every record still names app_svc, so the attribution problem remains. Weekly password rotation is a credential-hygiene measure; it limits the lifetime of a leaked secret but changes nothing about who the audit log can identify, and distributing the new password to three teams spreads it further. Placing the shared login in a role and auditing the role still produces one identity for all three applications, and roles are a way to group permissions rather than a way to distinguish callers. Exam caveat: shared and generic accounts defeat non-repudiation regardless of how strong their passwords are. Operational check: after the change, confirm each application connects with its own login and that a test statement appears in the audit log under the expected login name.