All jobs / Database administrator

Installation & Configuration interview questions

Installation & Configuration questions a Database administrator can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. You have just installed a database engine with its default settings. What do you review before anyone connects?

    The strongest answer: Memory and CPU limits, where the data, log and backup files live, the backup and maintenance schedule, and the accounts the installer created — defaults are sized for a laptop, not this server

    Why it works: Right — memory, file layout, backups and accounts are the four that bite first, and all four are wrong out of the box.

    • Defaults are generic, not yours.
    • Set memory and CPU limits.
    • Separate data, log and backup paths.
    • Trim the installer’s accounts.

  2. How much of a database server’s memory do you give the engine, and how do you decide?

    The strongest answer: Leave the operating system and agents enough to run, cap the engine explicitly at the rest, then check whether the working set fits and revisit once you have watched real traffic

    Why it works: Exactly — reserve for the OS, cap explicitly, then measure; the right number comes from the workload, not from a formula.

    • Reserve for the OS first.
    • Cap the engine explicitly.
    • Check the working set fits.
    • Revisit with real usage.

  3. You are specifying storage for a busy transactional database. How do you lay out the volumes, and why?

    The strongest answer: Separate the transaction log from the data files — the log is the small sequential write every commit waits on — keep backups on different storage, and size for the I/O pattern, not capacity

    Why it works: Right — the log is the commit latency path, and backups on the same device disappear with it.

    • Log writes are commit latency.
    • Separate log from data files.
    • Backups on different storage.
    • Size for IOPS, not only capacity.

  4. A mixed workload: short transactional queries all day, plus a handful of heavy reports.

    A report grabs every core and the short queries stall behind it. What do you do about parallelism?

    The strongest answer: Cap how many workers one query may take, raise the threshold for going parallel, then ask why the report is so expensive — an index or summary table may remove the need

    Why it works: Exactly — bound the blast radius, tune when parallelism is chosen, then fix the query that wanted every core.

    • Bound one query’s worker count.
    • Raise the threshold for going parallel.
    • Then fix the expensive report.
    • No single query starves the rest.

  5. Managed cloud database or self-hosted? How do you decide?

    The strongest answer: Managed by default for the operational work it removes, self-hosted where we need extensions, versions, tuning or cost control the service does not allow — and I write down what we lose either way

    Why it works: Exactly — a deliberate trade with the constraints named.

    • Managed by default.
    • Self-host for named constraints.
    • Count people in the cost.
    • Write down what you lose.

  6. Nobody remembers approving anything, and traffic has grown only modestly.

    The cloud database bill has doubled in a quarter. Where do you look?

    The strongest answer: Break the bill into compute, storage, I/O, backups and replicas; look for oversized instances, unused replicas, backup retention beyond policy, and I/O-heavy queries — then right-size with measurements

    Why it works: Exactly — decompose the bill, find the driver, fix it with data.

    • Decompose the bill.
    • Find the growth driver.
    • Right-size on measurements.
    • Retention follows policy, not cost.

  7. The team is choosing between a cloud vendor’s proprietary database and an open engine on the same cloud. How do you frame the decision?

    The strongest answer: Name what the proprietary option gives us that we will use, what leaving would cost in years, and how much of the application touches vendor-specific features — then decide with eyes open, not by principle

    Why it works: Exactly — lock-in is a cost to be priced, not a sin to be avoided at all costs.

    • Name the real benefit.
    • Price the exit.
    • Contain vendor-specific features.
    • Decide with eyes open.

  8. A new service needs a relational database and the team asks whether to run PostgreSQL, SQL Server or MySQL. How do you decide?

    The strongest answer: On constraints, not preference: licence cost, the features this workload truly needs, what the team can operate on call, and whether a managed version exists — then record what would change the answer

    Why it works: Exactly — the engines are close enough that licensing, tooling and operability decide; the written trade-off is what makes the choice reviewable later.

    • Decide on constraints, not fandom.
    • Price the licence and the platform.
    • Weigh what the team can operate.
    • Record what would change the answer.