5 exercises — choose the best-structured answer to DBRE interview questions. Focus on PostgreSQL replication, failover, query performance, connection pooling, and live migrations.
What separates good from great DBRE answers
Name the lock type: "AccessExclusiveLock" beats "it locks the table"
Explain the failure mode: what specifically breaks and why
Multi-root-cause thinking: slowness can be plan, statistics, or contention
PostgreSQL internals: process-per-connection, WAL, catalog storage all matter
0 / 18 completed
1 / 18
The interviewer asks: "How do you set up and validate PostgreSQL streaming replication?" Which answer demonstrates hands-on experience?
Option B is the strongest: names specific configuration parameters (wal_level, max_wal_senders, replication slots), explains each component's purpose (slots prevent premature WAL recycling), gives the exact monitoring view (pg_stat_replication) with the specific columns to watch, and warns about a real production failure mode (stuck slot exhausting disk). This is the answer of someone who has debugged replication in production. Option A is technically accurate but a textbook summary. Option C is vague about validation. Option D mentions pg_stat_replication but gives no insight into what to look for or why.
2 / 18
The interviewer asks: "Walk me through a PostgreSQL failover. What can go wrong?" Choose the most complete answer.
Option B is the strongest: introduces a memorable three-phase structure (fence → promote → redirect), explains split-brain precisely and why fencing comes first, gives the specific WAL check commands (replay_lag, pg_last_wal_replay_lsn), names the exact promotion command (pg_ctl promote or pg_promote()), and lists three concrete failure modes with their mechanisms. This answer shows someone who has planned and executed real failovers. Option A describes the happy path without any failure modes. Option C mentions Patroni but does not explain the underlying mechanics. Option D is correct but shallow — naming "replication lag" as a problem without explaining the data loss mechanism misses the key insight.
3 / 18
The interviewer asks: "How do you diagnose a slow query in PostgreSQL?" Which answer shows the most systematic approach?
Option B is the strongest: establishes a top-down funnel (aggregate visibility first via pg_stat_statements, then drill down with EXPLAIN), names the exact EXPLAIN flags and what each reveals (BUFFERS for disk I/O, ANALYZE for actual vs estimated rows), correctly identifies stale statistics as the cause of plan divergence, and adds the crucial dimension of wait events — showing that slowness can be contention-based not plan-based. This multi-root-cause thinking is what separates DBREs from developers. Option A is the most common answer but too narrow. Option C adds autovacuum but as a checklist, not a framework. Option D mentions the right tools but without the diagnostic reasoning chain.
4 / 18
The interviewer asks: "What is connection pooling and why is it critical for PostgreSQL at scale?" Choose the strongest explanation.
Option B is the strongest: explains the PostgreSQL-specific mechanism (process-per-connection vs thread-per-connection), quantifies the memory cost (~5-10 MB per backend), explains how PgBouncer's transaction mode works mechanically, names the real trade-off (transaction mode breaks LISTEN/NOTIFY and prepared statements), and states the practical target (max_connections 100-300 regardless of application thread count). This is a genuinely expert answer. Option A is correct but has no depth. Option C mentions the three modes and names the trade-off correctly but does not explain the PostgreSQL process model that makes pooling necessary. Option D is vague. Strong DBRE answers explain PostgreSQL's internals, not just the tool.
5 / 18
The interviewer asks: "How do you approach zero-downtime schema migrations on a large table?" Which answer is the most operationally mature?
Option B is the strongest: names the exact lock type to avoid (AccessExclusiveLock), explains the PostgreSQL 11+ optimisation for NOT NULL with defaults (catalog storage, no rewrite), describes CREATE INDEX CONCURRENTLY with its trade-offs, and most importantly explains the expand/migrate/contract pattern with the specific NOT VALID + VALIDATE CONSTRAINT technique — a genuinely advanced approach that minimises lock duration. The governing principle at the end (never hold AccessExclusiveLock for more than milliseconds) is a memorable rule. Option A is naive — transactions don't help for DDL on live tables. Option C lists tools and practices correctly but has no understanding of lock types or the expand/contract pattern. Option D is correct on CREATE INDEX CONCURRENTLY but "PostgreSQL is usually fast" for columns reveals a misunderstanding of when table rewrites occur.
6 / 18
Sarah (Senior DB Engineer) just posted this code review comment on a new schema update:
`'This change introduces a significant performance impact. The `orders` table now has over 10 million records, and the query execution time for retrieving order details is spiking to 5 seconds – unacceptable! Please investigate immediately.'
Which response best addresses Sarah's concerns and demonstrates proactive database reliability engineering?
Sarah's comment highlights a critical performance problem requiring immediate action. Option A is too vague and doesn't show initiative. Option B demonstrates avoiding responsibility. Option C represents the correct approach: systematically diagnosing the issue with tools like `EXPLAIN ANALYZE` and monitoring to validate the fix, aligning with best practices for reliability engineering.
7 / 18
Mark (DevOps Lead) sends this Slack message during a production incident:
`'Database connection pool exhausted. Rolling back transaction.'
What is the MOST important next step for a Database Reliability Engineer to take?
While all options have a role, Mark's message indicates a symptom. The *most* crucial step is to understand *why* the connection pool exhausted. Option A could mask the root cause and lead to further problems. Option B directly addresses diagnosing the issue, which is central to reliability engineering. Options C and D are reactive responses that don't address the core problem.
8 / 18
David (DBA) writes this PR description:
`'Updated PostgreSQL version to 16.2. Added configuration for `pg_stat_statements`. This will help us identify slow queries.'
What is the primary goal of implementing `pg_stat_statements`?
The core function of `pg_stat_statements` is to collect detailed information about query execution. While monitoring resource utilization can be a *result* of identifying slow queries (option B), it's not the primary purpose. Options A and D are unrelated to this specific tool. This aligns with proactive performance management, a key aspect of database reliability.
9 / 18
Emily (Database Reliability Engineer) is discussing schema changes with her team.
'We need to add an index to the `user_profiles` table. This will significantly improve query performance for retrieving user data based on their ID.'
Which statement best reflects Emily's understanding of the potential impact of this change from a reliability perspective?
While adding an index *can* improve performance, it's not a guaranteed solution. Option A is a dangerous oversimplification – indexes can create bottlenecks during write operations. Option B accurately describes the risk of poorly designed indexes impacting stability and contention. Options C and D misrepresent how indexes function in PostgreSQL; they require manual maintenance and tuning.
10 / 18
Sarah (Senior DB Engineer) just posted this code review comment on a new schema update:
`'This change introduces a significant performance impact. The `orders` table now has over 10 million records, and the query execution time for retrieving order details is spiking to 5 seconds – unacceptable! Please investigate immediately.'
Which response best addresses Sarah's concerns and demonstrates proactive database reliability engineering?
Sarah's comment highlights a critical performance problem requiring immediate action. Option A is too vague and doesn't show initiative. Option B demonstrates avoiding responsibility. Option C represents the correct approach: systematically diagnosing the issue with tools like `EXPLAIN ANALYZE` and monitoring to validate the fix, aligning with best practices for reliability engineering.
11 / 18
Mark (DevOps Lead) sends this Slack message during a production incident:
`'Database connection pool exhausted. Rolling back transaction.'
What is the MOST important next step for a Database Reliability Engineer to take?
While all options have a role, Mark's message indicates a symptom. The *most* crucial step is to understand *why* the connection pool exhausted. Option A could mask the root cause and lead to further problems. Option B directly addresses diagnosing the issue, which is central to reliability engineering. Options C and D are reactive responses that don't address the core problem.
12 / 18
David (DBA) writes this PR description:
`'Updated PostgreSQL version to 16.2. Added configuration for `pg_stat_statements`. This will help us identify slow queries.'
What is the primary goal of implementing `pg_stat_statements`?
The core function of `pg_stat_statements` is to collect detailed information about query execution. While monitoring resource utilization can be a *result* of identifying slow queries (option B), it's not the primary purpose. Options A and D are unrelated to this specific tool. This aligns with proactive performance management, a key aspect of database reliability.
13 / 18
Emily (Database Reliability Engineer) is discussing schema changes with her team.
'We need to add an index to the `user_profiles` table. This will significantly improve query performance for retrieving user data based on their ID.'
Which statement best reflects Emily's understanding of the potential impact of this change from a reliability perspective?
While adding an index *can* improve performance, it's not a guaranteed solution. Option A is a dangerous oversimplification – indexes can create bottlenecks during write operations. Option B accurately describes the risk of poorly designed indexes impacting stability and contention. Options C and D misrepresent how indexes function in PostgreSQL; they require manual maintenance and tuning.
14 / 18
Alex, a Database Reliability Engineer, received this Slack message from the DevOps team:
`'PostgreSQL replication lag is spiking. Investigate!'`
Which immediate action should Alex take to address this issue?
Analyzing pg_stat_replication provides crucial insights into the state of the streaming replication process – specifically, identifying the cause of the lag. Rolling back immediately is a drastic measure and shouldn't be done without understanding the root cause. Contacting DBAs isn't the first step; Alex should investigate first. Monitoring metrics with Grafana offers real-time visibility but doesn't directly address the immediate problem.
15 / 18
Sarah, a Database Reliability Engineer, is reviewing a code change that adds a new column to the `users` table. The code reviewer comments: "This could lead to significant performance degradation if not handled carefully."
What's the BEST follow-up action for Sarah?
A detailed query plan reveals how the new column impacts existing queries. This allows Sarah to identify potential bottlenecks and suggest appropriate solutions like adding an index or optimizing the query itself. Merging without understanding the impact is risky. Deferring isn't a proactive approach; discussing indexing strategies is good, but needs data first.
16 / 18
David, a Database Reliability Engineer, is troubleshooting slow queries in PostgreSQL. He uses the `EXPLAIN ANALYZE` command and observes that a particular query is performing full table scans.
What's the MOST effective next step to improve query performance?
Adding an index to the column used in the `WHERE` clause will allow PostgreSQL to quickly locate relevant rows and avoid full table scans. Increasing buffer pool size can help, but doesn't address the root cause of the slow query. Reducing concurrency limits would negatively impact overall system performance. Disabling extensions is rarely a targeted solution.
17 / 18
Mark, a Database Reliability Engineer, is explaining connection pooling to his team.
Which statement BEST describes the primary benefit of using connection pooling?
Connection pooling reuses existing database connections instead of creating a new one for each request. This dramatically reduces the overhead – time and resources – involved in establishing and closing connections. While availability is a *result* of pooling, it's not its primary purpose. Query optimization isn't a function of connection pooling; that's query design. Manual management is still required.
18 / 18
Emily, a Database Reliability Engineer, needs to perform a zero-downtime schema migration on a large PostgreSQL table (50GB). She's considering using logical replication.
What is the MOST critical consideration for Emily to address before initiating the migration?
A comprehensive rollback plan is paramount for zero-downtime migrations. If something goes wrong during the migration, a quick and reliable rollback will minimize disruption. While disk space, schema compatibility, and monitoring are important considerations, they are secondary to having a tested rollback strategy in place. Without it, even well-planned changes can lead to significant downtime.
What does "Database Reliability Engineer Interview Questions — Best-Answer Practice" cover?
Practice answering DBRE interview questions in professional English. 5 exercises on PostgreSQL replication, failover, query performance, connection pooling, and zero-downtime migrations.
How many questions are in this interview set?
This set has 18 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.