Interview prep · written by the FindAJobAI team

Database Administrator Interview Questions (2026) and How to Answer

By FindAJobAI team Updated How we wrote this page

Database administrator interviews focus on what happens when things go wrong: a failed backup, a slow query under load, a corrupted table, a 3 a.m. page. Expect scenario questions on recovery, tuning exercises, and questions on replication, indexing and access control.

Interviewers want someone who protects data first, stays calm under an incident, and can explain a technical fix to people who aren't database specialists.

Below: 30 questions with what each one really asks and an answer outline, full sample answers to the 10 most asked, red flags to avoid and a 7-day plan.

Answering with STAR

Tell each story in four steps: the situation in a sentence, your task, the actions you took (most of the answer) and the result, with a number if you have one. Aim for about two minutes; the outlines show what to include, the details must be yours.

Behavioural questions (1–10)

How you've handled real situations. Answer each with one true story, in STAR order.

  1. 1.Tell me about a time you recovered a database after a serious failure.

    What they're really asking: Can you execute a recovery calmly and correctly under pressure?

    Answer outline (STAR)

    • SituationA production database that went down or lost data unexpectedly.
    • TaskRestore service with the least data loss possible.
    • ActionConfirm the last good backup, isolate the cause, restore in a test environment first, then promote.
    • ResultDowntime length, data loss window, and the safeguard you added after.

    Full sample answer (fictional example)

    A storage volume failure corrupted our primary order database at around 2 a.m. I confirmed our last full backup was six hours old and our transaction logs were intact up to the failure point, so a full point-in-time recovery was possible. I restored to a separate instance first to verify integrity before touching anything in production, which took about forty minutes, then promoted it and redirected traffic. Total downtime was one hour and ten minutes with zero data loss. Afterward I added automated alerting on storage health metrics, since the failure had been building for two days before it became critical.

  2. 2.Describe a time you had to tell a team their query or schema design was causing a production problem.

    What they're really asking: Can you deliver a hard technical truth without alienating the team that wrote the code?

    Answer outline (STAR)

    • SituationAn application team's query pattern degrading database performance for everyone.
    • TaskFix the problem without making it personal.
    • ActionShow the evidence: the query plan, the lock waits, the resource usage, then propose the fix together.
    • ResultThe change made, and how the working relationship held up.

    Full sample answer (fictional example)

    During a Monday spike, our orders database slowed to a crawl, and I traced it to a report query that scanned a forty-million-row table without an index. The developer who wrote it was new and anxious. I showed him the execution plan next to a version using an index, and I explained the cost without blaming him. I added the index during a quiet window and asked him to run the report again; it dropped from four minutes to under two seconds. Then I wrote a short guide to reading plans and offered to review his next queries before release. He took me up on it, and the team now includes a plan check in code review.

  3. 3.Tell me about a time you planned and executed a major database migration.

    What they're really asking: Do you plan for the failure case, not just the happy path?

    Answer outline (STAR)

    • SituationA migration to a new version, engine or hosting platform.
    • TaskMove the data with no loss and minimal downtime.
    • ActionTest the migration path repeatedly on a copy, script it, and prepare a rollback at every stage.
    • ResultThe downtime achieved, and the issue your rollback plan actually caught.

    Full sample answer (fictional example)

    We moved a 600 GB PostgreSQL database from an old server to a managed cloud instance with a downtime window of thirty minutes. I rehearsed the migration three times on a copy of the environment and timed each step. In the second rehearsal I found a sequence that wasn't being reset, which would have caused duplicate key errors. I fixed the script and added a post-migration check comparing row counts and checksums on the largest tables. On the night, we started on time, finished in twenty-six minutes, and the checks all passed. I kept the old server read-only for a week as a fallback, and nobody needed it. The runbook is still the template for our later migrations.

  4. 4.Tell me about catching a performance problem before it caused an outage.

    What they're really asking: Are you watching the system proactively, or only reacting to pages?

    Answer outline (STAR)

    • SituationA slow trend in query times, disk usage or replication lag you noticed early.
    • TaskFix it before users felt it.
    • ActionInvestigate the trend, find the root cause, and make the fix before it hit a critical threshold.
    • ResultThe outage avoided, and the monitoring alert you added so it's caught automatically next time.

    Full sample answer (fictional example)

    While reviewing weekly capacity metrics, I noticed disk growth on our reporting database had doubled in a month. At that rate we'd run out of space in about three weeks. I traced it to a nightly log table that wasn't being archived after a job change. I wrote a cleanup job, moved older rows to cheaper storage, and set an alert for when free space dropped below a quarter of the disk. I told the team's lead the same day and documented the cause. We never had an outage, and the alert fired once more three months later for a different table, which gave us time to plan a disk upgrade calmly.

  5. 5.Tell me about a disagreement with a developer over schema design.

    What they're really asking: Can you balance data integrity against development speed without just saying no?

    Answer outline (STAR)

    • SituationA proposed schema that was fast to build but risked data integrity or performance.
    • TaskReach a schema that worked for both concerns.
    • ActionExplain the specific risk with an example, and propose an alternative that still met their deadline.
    • ResultThe schema adopted, and the problem it avoided down the line.
  6. 6.Tell me about a time you had to enforce a security or compliance requirement that slowed a team down.

    What they're really asking: Will you hold a necessary line even when it's unpopular?

    Answer outline (STAR)

    • SituationA team wanting to skip an access review or encryption requirement to hit a deadline.
    • TaskKeep the requirement without becoming the blocker everyone resents.
    • ActionExplain the specific risk and regulation behind the requirement, and help find a faster compliant path.
    • ResultThe requirement upheld, and the faster process you built afterward.
  7. 7.Describe a time you automated a manual database task.

    What they're really asking: Do you reduce repeat risk instead of just repeating it carefully?

    Answer outline (STAR)

    • SituationA recurring manual task, such as index maintenance or user provisioning.
    • TaskRemove the manual steps without losing the checks that made it safe.
    • ActionScript the task, add validation checks, and run it in parallel with the manual process before cutting over.
    • ResultTime saved, and the error it caught that a human might have missed.
  8. 8.Tell me about onboarding a new database engine or technology the team hadn't used before.

    What they're really asking: Can you build real operational competence, not just pass a tutorial?

    Answer outline (STAR)

    • SituationA new engine, such as moving from a relational database to a document store for one service.
    • TaskGet the team operationally ready, not just technically working.
    • ActionBuild a runbook, practice failure scenarios in a test environment, and document what's different from the familiar system.
    • ResultThe go-live outcome, and the gap the runbook caught before it became an incident.
  9. 9.Tell me about a time capacity planning prevented a problem.

    What they're really asking: Do you plan ahead of growth instead of reacting to it?

    Answer outline (STAR)

    • SituationA growth trend in data volume, connections or load you tracked over time.
    • TaskScale ahead of the point where it would have caused an outage.
    • ActionModel the growth trend, set a threshold, and act on the plan before hitting the ceiling.
    • ResultThe scaling done in advance, and the outage it avoided.
  10. 10.Tell me about handling a conflict between the security team and a business team over database access.

    What they're really asking: Can you mediate between competing legitimate priorities?

    Answer outline (STAR)

    • SituationA security requirement for tighter access that a business team said would slow their work.
    • TaskFind an approach both teams could accept.
    • ActionIdentify the specific friction point, and find a scoped access model that satisfied both the control and the workflow.
    • ResultThe access model adopted, and how both teams responded to it.

Technical and role-skill questions (11–22)

Can you do the work itself? Think out loud and name the trade-offs.

  1. 11.Walk me through your backup strategy for a production database.

    What they're really asking: Do you have a real strategy, or just 'we run backups'?

    Answer outline

    • Combine full, incremental and transaction log backups based on recovery point needs.
    • Store backups off the primary server, and test restores on a schedule, not just hope they work.

    Full sample answer (fictional example)

    I run full backups nightly, differential backups every six hours, and transaction log backups every fifteen minutes for our most critical databases, which gives us a recovery point objective under fifteen minutes. Backups are stored in a separate region from the primary, not just a separate disk. The part teams often skip is testing: I run an automated restore of the previous night's backup into an isolated environment every morning and alert if it fails. That caught a corrupted backup file once, within hours instead of discovering it during a real emergency a month later.

  2. 12.A query that used to run fast is now slow. How do you diagnose it?

    What they're really asking: Can you work from evidence instead of guessing?

    Answer outline

    • Check the execution plan for a change, such as a missing or stale index statistic.
    • Look at data growth, locking and blocking, and whether the query itself changed.
  3. 13.Explain the difference between a clustered and a non-clustered index.

    What they're really asking: Indexing fundamentals that most DBA interviews test directly.

    Answer outline

    • A clustered index determines the physical order of the table's rows; a table has at most one.
    • A non-clustered index is a separate structure pointing back to the table, and a table can have many.
  4. 14.How do you approach setting up replication for high availability?

    What they're really asking: Do you understand what replication does and doesn't protect against?

    Answer outline

    • Replication protects against hardware failure, not against a bad query or a dropped table.
    • Choose synchronous replication when you need zero data loss and can accept the latency cost, asynchronous otherwise.

    Full sample answer (fictional example)

    I'd first clarify what we're protecting against: replication handles hardware or node failure, but it won't help if someone runs a bad DELETE, since that replicates too. For failover, I'd choose synchronous replication if the business needs zero data loss and can tolerate the write latency cost, or asynchronous if a few seconds of potential loss is acceptable in exchange for better performance. I actively monitor replication lag with an alert threshold, because a standby that's silently falling behind gives false confidence. I also test actual failover periodically, not just confirm that replication is running.

  5. 15.How do you manage database access control across many applications and teams?

    What they're really asking: Do you default to least privilege, or convenience?

    Answer outline

    • Grant the minimum permissions each role needs, not broad admin access by default.
    • Use service accounts per application rather than shared credentials.
  6. 16.What's your process for applying a schema change to a production database with no downtime?

    What they're really asking: Can you change a live system safely?

    Answer outline

    • Make additive changes first, deploy the application that uses them, then remove old columns later.
    • Use online schema change tools for large tables rather than locking the table outright.
  7. 17.How do you decide when a database needs to scale up versus scale out?

    What they're really asking: Do you know the trade-offs instead of defaulting to one answer?

    Answer outline

    • Scaling up buys time with less complexity, but hits a hardware ceiling eventually.
    • Scaling out, such as sharding or read replicas, adds complexity but removes that ceiling.
  8. 18.How would you diagnose and resolve a deadlock happening repeatedly in production?

    What they're really asking: Do you understand locking well enough to fix the cause, not just retry past it?

    Answer outline

    • Capture the deadlock graph to see exactly which resources and queries were involved.
    • Look for a consistent order of operations that two transactions are hitting in reverse.

    Full sample answer (fictional example)

    I'd capture the deadlock graph the database engine produces, which shows exactly which two transactions were waiting on each other and which resources were involved. Usually the cause is two operations acquiring the same two resources in opposite order, for example updating an orders row then an inventory row in one transaction, and the reverse order in another. The real fix is making the access order consistent across the codebase, or narrowing the transaction scope so locks are held for less time, not just adding a retry and hoping it happens less often.

  9. 19.How do you approach database capacity planning for a growing product?

    What they're really asking: Can you plan months ahead instead of reacting to a resource alert?

    Answer outline

    • Track growth trends in storage, connections and query volume over time, not just current usage.
    • Model when each resource will hit its practical ceiling given the current growth rate.
  10. 20.What's your approach to data retention and archiving for a large, growing table?

    What they're really asking: Do you manage data lifecycle, or let tables grow forever?

    Answer outline

    • Agree retention rules with the business, based on legal and operational needs, not convenience.
    • Archive old data to cheaper storage rather than deleting it outright where it might still be needed.
  11. 21.How do you handle encryption for data at rest and in transit?

    What they're really asking: Do you know what encryption actually protects against, and its limits?

    Answer outline

    • Encrypt data at rest to protect against someone obtaining the physical storage or a backup file.
    • Encrypt data in transit with TLS to protect against interception on the network.
  12. 22.How would you design a database schema to support multi-tenant data with strict isolation?

    What they're really asking: Can you weigh isolation against operational complexity correctly for the use case?

    Answer outline

    • Separate databases per tenant give the strongest isolation but the most operational overhead at scale.
    • A shared database with a tenant ID column and row-level security is more efficient but needs careful enforcement.

Take-home or live exercise: tips

DBA interviews often include a live troubleshooting scenario, such as diagnosing a slow query from an execution plan or walking through a recovery plan for a described failure.

  • State your diagnostic steps out loud in order, rather than jumping to a fix before confirming the cause.
  • In a recovery scenario, always mention verifying the backup or restore before promoting it to production.
  • Ask about the acceptable recovery time and data loss window before proposing a specific approach.
  • Mention monitoring or alerting you'd add afterward, not just the immediate fix.

Situational questions (23–30)

Scenarios that test judgement: say what you'd do first, and why.

  1. 23.You get paged at 3 a.m. because the production database is unresponsive. What do you do?

    What they're really asking: Can you triage an incident methodically under pressure and lack of sleep?

    Answer outline

    • Check whether it's actually down or just slow, and whether it's one node or all of them.
    • Look at recent changes, deploys or jobs that ran around the time it started.

    Full sample answer (fictional example)

    First I check whether it's genuinely down or just under heavy load, and whether it's affecting one node or the whole cluster, since that changes the response completely. I look at recent deploys, scheduled jobs and any configuration changes around the time it started, since those cause a large share of incidents. I'll post an early status update to stakeholders even before I have a full diagnosis, so people aren't guessing. Once I find the cause, I fix the immediate problem first and investigate the deeper reason afterward, rather than trying to solve everything at 3 a.m.

  2. 24.A developer asks for direct production database access to debug an issue quickly. What do you do?

    What they're really asking: Will you balance speed against the risk of unrestricted access?

    Answer outline

    • Understand exactly what they need to see or do before deciding.
    • Offer a scoped read replica or a temporary, logged, limited-permission account instead of full access.

    Full sample answer (fictional example)

    I'd ask exactly what they're trying to see, because that usually changes what I offer. If they need to inspect data, I'd point them to a read replica with scoped, logged access rather than the primary. If they genuinely need to run something against production, I'd create a temporary account with the minimum permission needed and an expiration date, rather than broad admin access. Afterward I'd revoke it on schedule rather than leaving it active by default, since temporary access that never gets revoked is one of the most common ways access sprawls out of control.

  3. 25.You discover a backup hasn't actually been restorable for the past month. What do you do?

    What they're really asking: Do you treat a near-miss on data safety as seriously as it deserves?

    Answer outline

    • Fix the backup immediately and verify a successful restore right away.
    • Tell stakeholders about the exposure window, even though nothing was actually lost.

    Full sample answer (fictional example)

    I'd treat it as seriously as if we'd actually lost data, because for a month we effectively had no safety net. First I'd fix the backup process immediately and run a real restore test to confirm it now works. Then I'd tell stakeholders about the exposure window honestly, even though nothing was actually lost, because the risk was real during that time. Finally I'd add automated restore verification that runs daily and alerts on failure, so a broken backup is caught within a day instead of being discovered a month later by chance.

  4. 26.Two teams want conflicting schema changes to a shared table on the same release. How do you handle it?

    What they're really asking: Can you mediate a resource conflict between teams fairly?

    Answer outline

    • Understand what each change needs to achieve, not just what they asked for.
    • Look for a schema that satisfies both, or sequence the changes to avoid a collision.
  5. 27.A migration you're running overnight is taking far longer than estimated, and a deadline is in six hours. What do you do?

    What they're really asking: Can you make a sound call under time pressure without rushing into a worse mistake?

    Answer outline

    • Check progress against a safe checkpoint, and estimate the real remaining time honestly.
    • Decide whether to let it finish, pause safely, or roll back, based on that estimate, not hope.
  6. 28.You notice unusual query activity that looks like it could be a security incident. What do you do?

    What they're really asking: Will you treat a possible breach seriously and escalate quickly?

    Answer outline

    • Capture evidence of the activity before it's lost or overwritten.
    • Escalate to the security team immediately rather than investigating alone for too long.
  7. 29.A critical report depends on a query that's now timing out due to data growth. The business needs it today. What do you do?

    What they're really asking: Can you solve the immediate need and the underlying cause separately?

    Answer outline

    • Find a quick mitigation, such as an index or a cached result, to get today's report out.
    • Communicate clearly that it's a short-term fix, not the real solution.
  8. 30.Leadership wants to cut the database budget by reducing redundancy. How do you respond?

    What they're really asking: Will you state the real risk of a cost decision plainly, even if it's unwelcome?

    Answer outline

    • Translate the proposed cut into the specific risk it creates: longer recovery time, more data loss exposure.
    • Offer a version of the cut that preserves the most critical protection if full redundancy must go.

Red flags to avoid in your answers

Each one is quick to fix before the day.

  1. Describing backups without ever mentioning testing a restore.

    State explicitly how and how often you verify restores actually work.

  2. Jumping to a fix before confirming the actual cause of a problem.

    Narrate the diagnostic steps you'd take first, with the evidence each one would show.

  3. Treating access control as someone else's job.

    Describe the least-privilege practices you apply directly to database access.

  4. No mention of monitoring or prevention after describing a fixed incident.

    Always name the safeguard or alert you added so it doesn't happen again.

How to prepare for a database administrator interview in 7 days

An hour or two a day is enough; the order matters more than the length.

  1. Day 1: Review recovery fundamentals

    Write out your backup strategy cold: recovery time objective, recovery point objective, and how you'd explain both to a non-technical manager.

  2. Day 2: Query tuning drills

    Practice reading execution plans on sample queries and naming the likely fix out loud for each.

  3. Day 3: Incident story prep

    Write two full incident stories with a timeline: detection, diagnosis, fix and the prevention step added after.

  4. Day 4: Engine-specific review

    Study the indexing, locking and replication behavior of the specific database engine the job listing names.

  5. Day 5: Access and security review

    Rehearse how you'd explain least-privilege access control and encryption at rest and in transit.

  6. Day 6: Capacity and scaling scenarios

    Prepare an answer on scaling up versus out, and a capacity-planning story with real growth numbers.

  7. Day 7: DBA mock interview

    Run a mock: one live troubleshooting scenario and two behavioral questions, then rest.

Questions to ask the interviewer

Pick two or three; the answers tell you whether you want the job.

  1. What database engines and versions does the team support today?
  2. What does the on-call rotation and escalation path look like?
  3. How often are backups tested with an actual restore, not just a successful backup job?
  4. How are schema changes reviewed and deployed here?
  5. What's the biggest database-related incident the team has had in the past year, and what changed after it?

Preparation tips

  • Review backup and recovery fundamentals cold: recovery time objective, recovery point objective, and how to explain both plainly.
  • Practice reading a query execution plan and naming the likely fix out loud.
  • Prepare one incident story with a clear timeline: detection, diagnosis, fix, and the prevention step added after.
  • Know the indexing and locking behavior of whichever database engine the job specifies, not just general theory.

Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.

How we wrote this page

The FindAJobAI team wrote the questions, outlines and sample answers for database administrator interviews. The people, employers and numbers in the samples are invented: copy the structure, and use details from your own work.

Once we track enough live database administrator job ads, this page also shows the skills they ask for most, counted the same way as our in-demand skills report.

Last reviewed on November 1, 2026.