Automate temporary elevated database access securely

WHAT THIS TESTS: Your grasp of just-in-time (JIT) privileged access management and how automation can strengthen rather than erode least privilege and auditability.

A GOOD ANSWER COVERS: Replace the manual ticket with a self-service request that captures who, what resource, why, and for how long. Route it through lightweight approval, ideally a peer or on-call lead, with optional auto-approval only for low-risk read paths. Grant access by assuming a short-lived role rather than editing a user's permanent identity, so the grant expires automatically after minutes or an hour. Scope tightly: a specific database, schema, or read replica, read-only unless write is justified. Emit a complete audit record linking the grant to a person, justification, ticket, and timestamp, stored immutably. Send alerts on every elevation so abuse is visible.

COMMON WRONG ANSWERS: Creating a shared admin account, granting standing elevated roles, removing human approval without compensating controls, or building automation that has no expiry so access silently persists.

LIKELY FOLLOW-UPS: How do you handle break-glass when the approval system itself is down? How do you prevent privilege creep over time? Where do audit logs live and who can tamper with them? How do you scope to production-only without blocking legitimate debugging?

ONE CONCRETE EXAMPLE: An engineer runs a CLI command requesting one hour of read access to the orders database to debug a customer report. The system files an approval request to the on-call lead, who approves in chat. A short-lived credential is issued via the cloud IAM temporary-access feature, scoped read-only to that database. After one hour it expires automatically. Every step, the request, approver, reason, and credential issuance, is written to a tamper-resistant audit log that security reviews weekly. No one holds standing production database admin, and every elevation is reconstructable months later.