5 exercises — practise answering Database Reliability Engineer interview questions in professional technical English.
0 / 15 completed
1 / 15
The interviewer asks: "Can you compare streaming replication and logical replication in PostgreSQL, and describe when you would use read replicas versus multi-region topologies?" Which answer best demonstrates Database Reliability Engineer expertise?
Option B is strongest because it precisely distinguishes the WAL-block versus row-level change-event mechanisms, names real HA tools (Patroni, repmgr), explains synchronous_commit modes for RPO control, and highlights operational risks like WAL accumulation from unmanaged replication slots. Option A is superficial and misses topology trade-offs entirely. Option C is vague and incorrectly suggests logical replication for multi-master without addressing conflict resolution. Option D conflates configuration files with replication architecture and has no depth. Database Reliability Engineer interview best practice: always tie replication topology choices to RPO/RTO targets and show awareness of the operational monitoring required to keep replication healthy under load.
2 / 15
The interviewer asks: "Walk me through your backup strategy for a critical PostgreSQL database. How do you ensure you can meet aggressive RTO and RPO targets?" Which answer best demonstrates Database Reliability Engineer expertise?
Option B is strongest because it names specific tools (pgBackRest, Barman), applies the 3-2-1 rule to the database context, explains PITR semantics, quantifies the RTO target (under two minutes with Patroni/etcd), and demonstrates validation practices including weekly restore tests with checksum verification. Option A describes the minimum viable approach but lacks PITR, validation, and HA standby design. Option C mentions pgBackRest but lacks depth on PITR, testing frequency, and HA topology. Option D avoids the question by delegating to a managed service, demonstrating no underlying knowledge of backup architecture. Database Reliability Engineer interview best practice: always distinguish between RPO (data loss tolerance, answered by WAL archiving frequency) and RTO (downtime tolerance, answered by standby readiness), and show how each part of your strategy addresses both dimensions.
3 / 15
The interviewer asks: "Our application is hitting PostgreSQL max_connections limits under load. How would you approach connection pooling, and what are the trade-offs between PgBouncer's session, transaction, and statement modes?" Which answer best demonstrates Database Reliability Engineer expertise?
Option B is strongest because it explains why raising max_connections backfires, quantifies the memory cost per backend, names all three PgBouncer modes with their specific trade-offs and incompatible session features (prepared statements, advisory locks, LISTEN/NOTIFY), gives concrete pool sizing guidance tied to CPU core count, and identifies the monitoring metrics that signal pool exhaustion. Option A gives the wrong primary advice before mentioning PgBouncer. Option C is partially correct but lacks depth on incompatible session features, sizing heuristics, and monitoring. Option D addresses a different problem without solving the connection limit issue for synchronous clients. Database Reliability Engineer interview best practice: always identify which session-level PostgreSQL features your application uses before recommending a PgBouncer mode, and monitor cl_waiting as the leading indicator of pool exhaustion.
4 / 15
The interviewer asks: "How do you approach database monitoring in production? What specific signals do you track to detect performance degradation before it becomes an outage?" Which answer best demonstrates Database Reliability Engineer expertise?
Option B is strongest because it describes a complete monitoring stack from infrastructure to application SLIs, names specific system views (pg_stat_statements, pg_locks, pg_stat_activity, pg_stat_user_tables, pgstattuple, pg_stat_replication), gives concrete alert thresholds (500 ms lock wait, 20% bloat), explains the operational response for each signal, and ties everything to a Prometheus-based alerting pipeline supplemented by auto_explain. Option A is too generic — CPU and memory are lagging indicators and slow query logs alone are insufficient for proactive reliability. Option C names the right views but lacks a complete strategy, thresholds, and proactive bloat management. Option D describes a valid tooling choice but demonstrates no underlying understanding of what signals to measure. Database Reliability Engineer interview best practice: always demonstrate that you monitor leading indicators (lock wait time growth, bloat rate, autovacuum lag) rather than only lagging indicators (query timeout, replication failure).
5 / 15
The interviewer asks: "We need to add a NOT NULL column to a 500-million-row table in production without downtime. What tools and approaches would you use?" Which answer best demonstrates Database Reliability Engineer expertise?
Option B is strongest because it correctly explains the PostgreSQL 11+ catalog optimization, names multiple tools across databases (pg_repack, gh-ost, pt-online-schema-change, Liquibase, Flyway), describes the expand-contract pattern for zero-downtime deployments, mentions rate-limited batch backfilling for IOPS control, and explains the NOT NULL VALIDATE CONSTRAINT technique that avoids a write-blocking lock. Option A is partially correct but incomplete — it only applies to specific non-volatile DEFAULT types and ignores backfill and constraint validation. Option C requires a maintenance window and a single large UPDATE that would lock the table and generate massive IOPS. Option D names gh-ost correctly but gives no depth on the overall phased strategy or PostgreSQL-specific alternatives. Database Reliability Engineer interview best practice: always break online schema changes into three phases — add nullable column, backfill in rate-limited batches, add constraint — and validate each phase independently in a staging environment before running in production.
6 / 15
Reviewer: 'This query is running *really* slow. Can you explain why it's using a full table scan instead of an index? It's impacting user experience significantly.' Which response best addresses the reviewer's concern as a Database Reliability Engineer?
A reliability engineer's focus isn't just on optimizing SQL; it's about identifying and resolving underlying issues impacting system stability. Investigating schema and index coverage is a crucial first step in diagnosing performance problems like full table scans – this directly addresses the root cause. Scaling server resources might be a temporary fix, but doesn't solve the fundamental problem.
7 / 15
Liam (DevOps): 'Database metrics are spiking! High CPU usage on the primary Postgres instance. Any ideas?' Which response is MOST suitable for Liam from a Database Reliability Engineer perspective in this Slack conversation?
As a reliability engineer, your initial response should focus on identifying potential causes of high CPU usage. Scheduled batch jobs are a common culprit. Suggesting a reboot is a reactive step and doesn't address the underlying problem. Monitoring alone isn't sufficient – you need to proactively investigate potential issues.
8 / 15
You're writing the PR description for a change that adds automated failover testing to your PostgreSQL cluster. The description should clearly communicate the purpose and scope of this work. Which statement is MOST effective?
A good PR description should clearly articulate *what* was changed and *why*. Describing automated failover testing – specifically simulating primary failure and verifying secondary takeovers – directly addresses a core reliability concern. The other options are too vague or unrelated to the described work.
9 / 15
During your daily stand-up, you're asked: 'What did you work on yesterday?' You respond: 'I optimized a few slow queries.' How would a Database Reliability Engineer BEST expand upon this answer to demonstrate their role?
While optimizing queries is part of a reliability engineer's job, it's crucial to frame it within the context of system stability. Saying you reduced query execution time demonstrates an impact on performance and user experience – the key focus for reliability. The other options represent tasks outside the core responsibilities.
10 / 15
You're tasked with mitigating a potential data corruption issue in your production PostgreSQL database. You discover a significant number of duplicate records introduced by a recent ETL process. What's the MOST appropriate initial action for a Database Reliability Engineer to take?
Data corruption is a serious issue; restoring from backup isn't a solution but a recovery step. `pg_repack` can rebuild tables without downtime – it's a targeted approach to address the problem. The most crucial first step is always understanding *why* the corruption occurred (the ETL pipeline) to prevent recurrence.
11 / 15
Reviewer: 'This query is running *really* slow. Can you explain why it's using a full table scan instead of an index? It's impacting user experience significantly.' Which response best addresses the reviewer's concern as a Database Reliability Engineer?
A reliability engineer's focus isn't just on optimizing SQL; it's about identifying and resolving underlying issues impacting system stability. Investigating schema and index coverage is a crucial first step in diagnosing performance problems like full table scans – this directly addresses the root cause. Scaling server resources might be a temporary fix, but doesn't solve the fundamental problem.
12 / 15
Liam (DevOps): 'Database metrics are spiking! High CPU usage on the primary Postgres instance. Any ideas?' Which response is MOST suitable for Liam from a Database Reliability Engineer perspective in this Slack conversation?
As a reliability engineer, your initial response should focus on identifying potential causes of high CPU usage. Scheduled batch jobs are a common culprit. Suggesting a reboot is a reactive step and doesn't address the underlying problem. Monitoring alone isn't sufficient – you need to proactively investigate potential issues.
13 / 15
You're writing the PR description for a change that adds automated failover testing to your PostgreSQL cluster. The description should clearly communicate the purpose and scope of this work. Which statement is MOST effective?
A good PR description should clearly articulate *what* was changed and *why*. Describing automated failover testing – specifically simulating primary failure and verifying secondary takeovers – directly addresses a core reliability concern. The other options are too vague or unrelated to the described work.
14 / 15
During your daily stand-up, you're asked: 'What did you work on yesterday?' You respond: 'I optimized a few slow queries.' How would a Database Reliability Engineer BEST expand upon this answer to demonstrate their role?
While optimizing queries is part of a reliability engineer's job, it's crucial to frame it within the context of system stability. Saying you reduced query execution time demonstrates an impact on performance and user experience – the key focus for reliability. The other options represent tasks outside the core responsibilities.
15 / 15
You're tasked with mitigating a potential data corruption issue in your production PostgreSQL database. You discover a significant number of duplicate records introduced by a recent ETL process. What's the MOST appropriate initial action for a Database Reliability Engineer to take?
Data corruption is a serious issue; restoring from backup isn't a solution but a recovery step. `pg_repack` can rebuild tables without downtime – it's a targeted approach to address the problem. The most crucial first step is always understanding *why* the corruption occurred (the ETL pipeline) to prevent recurrence.
What does "Database Reliability Engineer — IT English Interview Practice" cover?
Practice answering Database Reliability Engineer interview questions in professional English. 5 multiple-choice exercises covering replication topologies, backup strategies, connection pooling, monitoring, and online schema migrations.
How many questions are in this interview set?
This set has 15 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.