Rotate a database credential without breaking every connection.

Instruction: Propose the transition, verification and removal sequence.

Context:

A fictional service has 20 instances and pooled database connections. Credentials are injected as environment variables at process start. The database permits two separately managed application identities with the same narrow privileges during rotation. There is no current evidence of credential theft.

Updated

Example Answer

I would create the replacement identity with only the required privileges, verify it in a controlled instance, then roll the service so new processes receive the new secret. Updating the secret store will not change environment variables in already running processes.

I would drain old connections and verify new connections from all instances before revoking the old identity. A successful query on an existing pool connection does not prove that the new credential works. The rollback window and final revocation need to be explicit.

Worked reasoning

The runbook should name the current and replacement secret versions without exposing their values. Test an actual new connection, a representative read/write operation and expected denied operations. Roll in bounded batches with capacity and error monitoring.

Observe which identity establishes new sessions, restart or refresh consumers according to their documented behavior, and drain lingering pools or jobs. Include scheduled tasks and operational tools, not only web instances. Revoke the old identity after confirmed migration, then verify that new connections using it fail as intended.

If revocation affects only future logins, terminate remaining old sessions deliberately when required. Keep the prior application artifact deployable with the new compatible credential rather than relying on indefinite validity of the old secret.

What the interviewer is assessing

Core checks (1 point each):

  • Recognizes startup environment and pooled-connection behavior.
  • Tests new credentials through new sessions before broad rollout.
  • Verifies migration and explicitly revokes the old identity.

Stronger (+1 after all core checks): Includes background consumers and distinguishes credential revocation from terminating established sessions.

Acceptable alternatives: A supported dual-password mechanism can replace separate identities if its exact semantics are verified.

Red flags: Overwrites a secret and assumes every process refreshed it, or retains both credentials indefinitely.

Follow-up

Evidence of active theft appears during rotation. What changes?

Example response: Containment urgency increases: coordinate prompt revocation and session termination with the security and database owners, accepting a controlled service interruption if needed. Reduce the overlap window and investigate use of the exposed identity. The gradual no-theft plan should not delay stopping an active compromise.

Related Questions