During the engagement, three engineers all authenticate as admin, and at the end nobody can say who changed what. What account practice would have prevented this?
Select an answer to reveal the explanation.
Short Explanation
Three engineers, one 'admin' login, one awkward conversation the day something changes. Logs attribute accounts, not humans — so everyone gets a named account with the right role, and the shared default goes into the vault for emergencies. Accountability isn't a tool you install later; it's a name you attach at login.
Full Explanation
Attribution is a design property of accounts, not of intent. The log records which account authenticated and what it ran; when three humans share one name, the log can only say admin, and the operational truth — who ran the command that broke a replication context — is unrecoverable after the fact. Individual named accounts with role-appropriate privileges put a human identity behind every action, while the factory default credential is set aside as a break-glass recovery account. Rotating a shared password weekly fails the mechanism: rotation changes who knows the secret over time but still logs a single identity, so attribution is never restored. A sign-in wiki fails on the same axis from the other side — self-reported times correlate loosely with logged actions, are incomplete under pressure, and audit poorly precisely when the audit matters. MAC-restricting the shared login fails twice: MAC addresses are trivially spoofable, and every permitted machine still logs as one identity. Exam caveat: the access-configuration tasks expect named administrators with role-appropriate privileges as the baseline. Operational check: create the named users, verify each role against its documented privilege set, and vault the default admin credential behind a break-glass procedure.