All jobs / Database administrator
Security interview questions
Security questions a Database administrator can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What is the difference between a server-level login and a database-level user, and why does it bite you after a restore?
The strongest answer: The login authenticates to the instance; the user lives in one database and holds the permissions. Restore that database elsewhere and the users arrive without their logins, so they must be remapped
Why it works: Right — authentication at the instance, authorisation inside the database, and the mapping between them is what a restore leaves dangling.
- Login: authenticate to the instance.
- User: permissions inside one database.
- Restores leave users orphaned.
- Recreate and remap, do not over-grant.
The release is tomorrow and the new service fails with a permissions error on start-up.
A developer asks for the application account to have superuser or db_owner rights “so nothing blocks the release”.
The strongest answer: I grant the application exactly the objects and operations it uses, and separate accounts for migrations and for the app’s runtime
Why it works: Exactly — least privilege, and a split between the account that changes schema and the one that serves requests.
- Grant what is used, nothing more.
- Separate migration and runtime accounts.
- Temporary grants become permanent.
- Superuser in an app is a breach waiting.
Security asks for “the database to be encrypted”. What do you actually put in place?
The strongest answer: Encryption in transit with enforced TLS, encryption at rest for data files and backups with managed keys, and a clear answer on what column-level encryption is for — each protects against a different attacker
Why it works: Exactly — transit, rest and backups are separate controls against separate threats.
- TLS in transit, enforced.
- Encrypt data files and backups.
- Column encryption is a targeted tool.
- Each control matches a threat.
HR asks who changed a salary value last Tuesday. Can you answer, and what would you set up?
The strongest answer: Only if auditing was already on — so I enable auditing for sensitive tables, with named accounts, and ship the audit trail off the server where the auditor cannot alter it
Why it works: Exactly — you cannot audit retrospectively; set it up for sensitive data and protect the trail.
- Auditing must be on beforehand.
- Named accounts make it meaningful.
- Store the trail off the server.
- Transaction logs are not an audit.
The request arrives as a ticket asking for “a fresh prod dump in staging by Monday”.
Developers want a copy of the production database in staging. Conditions?
The strongest answer: Only with personal data masked or synthesised on the way in, the same access controls as production on the copy, and a retention limit — or, better, a generated dataset with production’s shape
Why it works: Exactly — a copy of personal data is still personal data.
- Mask or synthesise PII.
- Copies inherit the rules.
- Limit retention.
- Prefer generated data.
How do you rotate the application’s database password without downtime?
The strongest answer: Create a second credential or role, deploy the application with the new one while both are valid, verify no connections use the old one, then revoke it — and automate this via a secrets manager
Why it works: Exactly — overlap, verify, revoke, automate.
- Two valid credentials overlap.
- Verify before revoking.
- Automate with a secrets manager.
- Service accounts rotate too.
On an instance you have inherited, permissions are granted directly to dozens of named accounts, each set slightly different.
Why does that matter, and how do you fix it?
The strongest answer: Nobody can answer who can do what, and leavers get missed — so I define a role per job, grant only to roles, migrate the existing grants, and review membership regularly
Why it works: Exactly — roles turn a pile of grants into something reviewable, and reviewable is what both an auditor and an on-call engineer need.
- Grant to roles, not people.
- Roles map to jobs.
- Migrate grants before revoking.
- Review membership on a schedule.
The queries page through the table in ordered chunks and the host is not in the application fleet.
At three in the morning the application account starts running large SELECTs over the customer table from an unfamiliar host. Response?
The strongest answer: Treat it as a possible breach: preserve the session and audit evidence, terminate the connections and rotate the credential, involve security, check what was read, and then find how the credential was obtained
Why it works: Exactly — contain, preserve, escalate, assess exposure, then root cause.
- Assume breach until shown otherwise.
- Preserve evidence, then contain.
- Rotate the credential.
- Involve security early.
A new market requires that customer data stays within its borders. Impact on the database platform?
The strongest answer: Regional database instances with backups, replicas and logs kept in-region, routing so that market’s data never lands elsewhere, and documented evidence of it — the platform now has a data-location dimension
Why it works: Exactly — residency touches every copy: primary, replica, backup and log.
- Every copy stays in-region.
- Backups and logs too.
- Routing enforces it.
- Evidence, not assurance.
An auditor asks you to prove who can read personal data and who has read it. How do you answer?
The strongest answer: From the access model: roles and grants exported from the databases, the join to real people through the identity provider, audit logs of access to the sensitive schemas, and a periodic review process with sign-off
Why it works: Exactly — grants mapped to people, evidence of use, and a review cadence.
- Grants mapped to people.
- Audit logs of access.
- Periodic access review.
- Encryption is not access control.