Question 1

What is Amazon RDS?

Accepted Answer

RDS is AWS's managed relational database service supporting MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and Aurora. AWS handles provisioning, patching, backups, replication and failover while you keep standard SQL and normal client drivers. You do not get operating-system access. The boundary to name is what you give up: no OS access, restricted parameter tuning, a supported subset of extensions and versions. That is precisely the trade-off that decides between RDS and self-managing a database on EC2.

Question 2

What is the difference between Multi-AZ and a read replica?

Accepted Answer

Multi-AZ maintains a synchronous standby in another AZ that serves no traffic and is failed over to automatically — it is a high-availability feature. A read replica replicates asynchronously, has its own endpoint, serves read queries, can be cross-region, and must be promoted manually — it is a scaling and DR feature. This is the most-asked RDS question. The consequences to add: Multi-AZ gives near-zero RPO but no read capacity, while a read replica adds read capacity but has replication lag, so reads that must reflect a just-completed write cannot go to it.

Question 3

What is a Multi-AZ DB cluster and how does it differ from Multi-AZ instance deployment?

Accepted Answer

The classic Multi-AZ instance deployment has one standby that serves no traffic. A Multi-AZ DB cluster deploys a writer and two readable standbys across three AZs, with semi-synchronous replication, lower failover times and readable standbys — so it provides both HA and read capacity. The readable-standby capability is the practical improvement, since the classic deployment left an entire instance idle. Knowing that failover is typically much faster in the cluster deployment is the operational detail worth naming.

Question 4

How does RDS failover work and what must the application do?

Accepted Answer

On failure, RDS promotes the standby and updates the DNS CNAME of the endpoint to point at it, typically completing in one to two minutes. Existing connections are dropped. The application must detect the broken connections, retry with backoff, and honour short DNS TTLs so it resolves the new address. The DNS caching issue is the specific failure: a JVM caching DNS indefinitely will keep connecting to the old address after failover. Naming that, and RDS Proxy as the mechanism that removes the problem by handling failover at the proxy, is the strong answer.

Question 5

How do RDS backups and point-in-time recovery work?

Accepted Answer

Automated backups take a daily snapshot during a backup window and continuously ship transaction logs, letting you restore to any second within the retention period, up to 35 days. Manual snapshots persist until you delete them. Restores always create a *new* instance rather than rolling the existing one back. The restore-to-new-instance behaviour is the operational fact that shapes the recovery runbook — you restore then cut over, which takes time proportional to database size. Automated backups are also deleted when the instance is deleted unless you take a final snapshot, which is a real data-loss trap.

Question 6

What is Aurora and how does its architecture differ from standard RDS?

Accepted Answer

Aurora is a MySQL- and PostgreSQL-compatible database with a distributed, log-structured storage layer separate from compute. Data is replicated six ways across three AZs, storage auto-scales in 10 GB increments up to 128 TB, and replicas share the same storage volume rather than each holding a copy. Shared storage is the architectural insight that explains everything else: replicas add read capacity without replicating data, replica lag is typically tens of milliseconds, and adding a replica is fast. It also means a failed writer can be replaced without data movement.

Question 7

What are Aurora replicas and how does failover work?

Accepted Answer

Aurora supports up to 15 replicas sharing the storage volume, all readable, with typical lag in the tens of milliseconds. If the writer fails, a replica with the highest configured tier is promoted, usually in under 30 seconds. The cluster provides a writer endpoint and a reader endpoint that load-balances across replicas. The failover speed compared with RDS Multi-AZ is a genuine differentiator, and knowing about promotion tiers — which control the order of promotion — shows real Aurora experience. Custom endpoints for routing specific workloads to specific instances are the other feature worth naming.

Question 8

What is Aurora Serverless v2?

Accepted Answer

Aurora Serverless v2 scales compute capacity in fine-grained Aurora Capacity Units in response to load, in place and without dropping connections, from a configured minimum to maximum. It supports the full Aurora feature set including replicas, Multi-AZ and Global Database, unlike v1. The advantage over provisioned Aurora is matching cost to variable demand without over-provisioning for peak. The consideration to name is that the minimum ACU setting establishes a cost floor, so it is not free when idle in the way Lambda is.

Question 9

What is Aurora Global Database?

Accepted Answer

Global Database replicates an Aurora cluster to secondary regions with typical lag under a second, using dedicated infrastructure rather than the database engine, giving low-latency local reads worldwide and cross-region disaster recovery with a recovery time typically under a minute. The RPO and RTO figures are what make it a DR answer rather than just a read-scaling one — around a second of potential data loss and a fast managed failover. Write forwarding from secondary regions is the feature that simplifies application logic and is worth naming.

Question 10

What is RDS Proxy and what problems does it solve?

Accepted Answer

RDS Proxy is a managed connection pool between applications and RDS or Aurora. It multiplexes many client connections onto a smaller number of database connections, which is essential for serverless and containerised workloads, reduces failover time by handling reconnection at the proxy, and enforces IAM authentication. The two problems it solves are connection exhaustion from many short-lived clients, and slow failover caused by DNS caching in clients. Naming both, rather than only pooling, is what shows you understand why AWS built it.

Question 11

How do you scale reads on RDS?

Accepted Answer

Add read replicas and route read-only queries to them, ideally through the Aurora reader endpoint or application-level routing. Cache hot reads in ElastiCache. Scale the writer vertically for remaining load. For very high read fan-out, Aurora with up to 15 replicas is the natural fit. The qualification is replication lag: reads that must reflect a just-completed write must go to the writer. Describing routing by query intent — reporting and browse to replicas, post-write reads to the writer — is the practical design rather than a blanket split.

Question 12

How do you scale writes when one RDS writer is not enough?

Accepted Answer

Optimise first — indexes, batching, removing unnecessary writes; scale vertically to a larger instance; offload non-transactional writes such as events and analytics to Kinesis and a warehouse; shard by tenant or key at the application layer; or move to a horizontally-scaling store such as DynamoDB or Aurora Limitless where the model allows. Naming the cost of sharding — cross-shard queries, rebalancing, operational complexity — is what makes the answer honest. Interviewers ask this to see whether you exhaust cheaper options before proposing a rewrite.

Question 13

What are the main causes of RDS performance problems?

Accepted Answer

Missing or unused indexes causing scans; connection exhaustion or churn; long-running transactions holding locks; undersized memory so the buffer pool thrashes; storage IOPS limits because the volume is too small or the wrong type; and on PostgreSQL, autovacuum falling behind causing bloat and wraparound risk. The AWS-specific tool to name is Performance Insights, which shows database load broken down by wait event, SQL statement, host and user over time. Starting there rather than guessing is what distinguishes a systematic answer.

Question 14

What is RDS Performance Insights?

Accepted Answer

Performance Insights visualises database load as average active sessions, broken down by wait event, SQL query, host, user and application, with a configurable retention period. It shows which queries and which waits dominate, making the bottleneck visible rather than inferred. The wait-event breakdown is the valuable part: it distinguishes CPU-bound from I/O-bound from lock-bound load, which entirely changes the remedy. A candidate who names wait events rather than just "top queries" has actually used it.

Question 15

What storage types does RDS support and how do you choose?

Accepted Answer

General Purpose gp3 is the default, with baseline IOPS and independently provisionable throughput. gp2 is the older type where IOPS scale with volume size. Provisioned IOPS io1 and io2 give consistent high IOPS for latency-sensitive workloads. Magnetic is legacy. Aurora manages storage itself with no type to choose. The gp2-to-gp3 point is practical: gp3 decouples IOPS from capacity, so you no longer over-provision storage just to get IOPS, which was a real cost distortion. Aurora removing the decision entirely is one of its operational advantages.

Question 16

How does RDS handle encryption?

Accepted Answer

Encryption at rest uses KMS and covers the instance, its automated backups, snapshots and read replicas. It must be enabled at creation — you cannot encrypt an existing unencrypted instance in place; you snapshot, copy the snapshot with encryption, and restore. In transit, TLS is supported and can be enforced with a parameter. The cannot-encrypt-in-place constraint is the specific fact interviewers test, because it makes encryption a day-one decision. Also worth naming: an encrypted snapshot cannot be shared publicly, and cross-account sharing requires the key to be shared too.

Question 17

What is IAM database authentication?

Accepted Answer

IAM database authentication lets applications and users connect to MySQL or PostgreSQL on RDS and Aurora using an IAM-generated authentication token valid for 15 minutes, instead of a stored password. Access is then managed through IAM policies. The benefit is eliminating shared static database passwords, and revocation becomes an IAM change rather than a password rotation. The constraint to name is a connection-rate limit, which is why RDS Proxy with IAM auth is the pattern at scale.

Question 18

How do you migrate a database to RDS with minimal downtime?

Accepted Answer

Use AWS Database Migration Service with change data capture: a full load followed by continuous replication from the source, so the cutover window is only the time to stop writes, let replication drain, and repoint the application. Use the Schema Conversion Tool for heterogeneous migrations, and rehearse the cutover. The details that show experience are validating unsupported features, extensions and stored procedures before starting, and running a rehearsal to measure the actual drain time rather than assuming it is instant. DMS validation, which compares source and target data, is the assurance step.

Question 19

What is the difference between RDS and DynamoDB, and when do you choose each?

Accepted Answer

RDS is relational with joins, ad-hoc queries, transactions and constraints, scaled vertically with read replicas. DynamoDB is a key-value and document store scaling horizontally to any throughput with single-digit millisecond latency, but requires access patterns to be known in advance and cannot join. The decisive question is whether query patterns are known up front. RDS absorbs unanticipated queries; DynamoDB punishes them because every access pattern needs a key or index designed for it. Framing it that way is more useful than "SQL versus NoSQL".

Question 20

What is RDS Blue/Green Deployment?

Accepted Answer

It creates a synchronised staging environment — a full copy of the production database kept in sync by replication — where you apply changes such as a major version upgrade or schema change, test them, then switch over in typically under a minute with safeguards that prevent data loss. It transforms a major version upgrade from a long maintenance window with an uncertain rollback into a tested, fast switchover. Naming that the green environment is read-only-protected until switchover, and that the old environment remains for rollback, shows real familiarity.

Question 21

How do RDS maintenance windows work?

Accepted Answer

AWS applies patches and required updates during a weekly window you configure. Some maintenance requires a reboot; on Multi-AZ deployments it is applied to the standby first, then a failover occurs, then the former primary is patched, so the interruption is a failover rather than full downtime. The Multi-AZ patching behaviour is a strong argument for Multi-AZ beyond disaster resilience — it converts a maintenance outage into a short failover. That is a benefit many candidates miss when justifying the extra cost.

Question 22

What are RDS parameter groups and option groups?

Accepted Answer

A parameter group holds engine configuration such as max_connections, buffer sizes and logging settings, applied to one or more instances; some parameters are static and require a reboot. An option group enables engine-specific features such as Oracle Transparent Data Encryption or SQL Server Audit. The parameter to name for diagnostics is slow query logging — log_min_duration_statement on PostgreSQL or the slow query log on MySQL — because enabling it is usually the fastest route from "the database is slow" to a specific offending statement.

Question 23

How do you protect an RDS instance from accidental deletion?

Accepted Answer

Enable deletion protection; take manual snapshots that survive instance deletion; ensure a final snapshot is taken on delete; restrict rds:DeleteDBInstance and rds:ModifyDBInstance to a small group; add an SCP denying deletion outside a break-glass path; and copy snapshots to a separate account. The layered answer matters because deletion protection is a flag anyone with modify permission can turn off. Cross-account snapshot copies are the control that survives a fully compromised account, which is the scenario worth designing for.

Question 24

What is ElastiCache and how does it complement RDS?

Accepted Answer

ElastiCache is managed Redis, Valkey and Memcached. It absorbs repetitive reads, holds session state, rate-limit counters and computed results, so the relational database serves only what genuinely needs transactional consistency. Redis offers replication, automatic failover, persistence and data structures; Memcached is simpler and multi-threaded. The design caution is cache invalidation and the thundering herd when a hot key expires. Naming TTL jitter or a single-flight lock as the mitigation is what distinguishes having operated a cache from having added one.

Question 25

What caching strategies would you use?

Accepted Answer

Cache-aside is the default — check cache, fall back to the database on a miss, populate the cache. Write-through updates both on write for consistency at the cost of write latency. Write-behind buffers writes for throughput at the risk of loss. Choose TTLs that bound staleness and add jitter so keys do not expire simultaneously. The failure mode to name is the cache stampede: a popular key expires and hundreds of requests hit the database at once. Jitter, proactive refresh before expiry, or a lock so only one request repopulates are the standard mitigations.

Question 26

How is RDS priced and where does cost hide?

Accepted Answer

Instance hours whether or not queries run, provisioned storage per GB-month, provisioned IOPS if applicable, backup storage beyond the free allocation equal to the database size, snapshots, and data transfer. Multi-AZ roughly doubles instance and storage cost because the standby is a full instance. The recommendation that follows is Multi-AZ in production only, since it is often enabled everywhere by a template and doubles non-production cost for no benefit. Reserved Instances for the steady baseline is the other lever.

Question 27

What is the difference between an RDS snapshot and an automated backup?

Accepted Answer

Automated backups are managed by RDS with a retention period up to 35 days and enable point-in-time recovery; they are deleted when the instance is deleted unless a final snapshot is taken. Manual snapshots persist independently until you delete them and can be copied across regions and shared across accounts. The deleted-with-the-instance behaviour of automated backups is a genuine data-loss trap. Any real DR plan therefore includes manual or AWS Backup-managed snapshots copied to another account and region.

Question 28

How do you handle schema migrations against a live RDS database?

Accepted Answer

Use expand-and-contract: add the new column or table, deploy code writing to both shapes, backfill in batches, switch reads, then remove the old shape in a later release. Avoid long locking DDL on large tables during peak; use online schema change tooling where the engine requires it; and run migrations from CI with a versioned tool. The requirement that every release be backwards-compatible with the previous schema is the substance, because during a rolling deploy both versions run simultaneously. Blocking ALTER TABLE on a large table stalling the application is the failure to pre-empt.

Question 29

What is Aurora Backtrack?

Accepted Answer

Backtrack rewinds an Aurora MySQL cluster to a point in time within a configured backtrack window, in place and in seconds, without restoring from a snapshot. It is intended for recovering from a bad data change such as an accidental delete or a faulty migration. The distinction from point-in-time recovery is that Backtrack rewinds the *existing* cluster rather than creating a new one, which is dramatically faster. The limitations to name are that it is Aurora MySQL only and rewinds the whole cluster, not a single table.

Question 30

What is Aurora cloning?

Accepted Answer

Aurora fast database cloning creates a new cluster that shares the source's storage using copy-on-write, so the clone is created in minutes regardless of database size and only stores the pages that diverge. It is used for creating test environments from production data. The copy-on-write mechanism is why it is nearly free initially and grows only with changes, which makes production-like test environments practical. The caution is that clones are not isolated from a storage-layer problem in the source and are not a backup.

Question 31

How do you monitor an RDS instance?

Accepted Answer

CloudWatch for CPU, freeable memory, free storage space, IOPS, database connections, replica lag and read and write latency. Enhanced Monitoring for OS-level metrics at higher resolution. Performance Insights for query-level load. Alert on free storage, connection count approaching maximum, replica lag and sustained CPU. Free storage space is the alert that prevents the most common self-inflicted RDS outage, since a full volume takes the database down. Replica lag is the second, because a lagging replica silently serves stale data rather than erroring.

Question 32

What is the difference between vertical and horizontal scaling on RDS, and what downtime does each involve?

Accepted Answer

Vertical scaling changes the instance class and requires a restart — on Multi-AZ, AWS applies it to the standby and fails over, reducing the interruption to a failover. Horizontal scaling adds read replicas with no downtime, but only adds read capacity, not write. The Multi-AZ benefit for resizing is worth naming because it converts a maintenance outage into a brief failover. That writes cannot be scaled horizontally on standard RDS is the constraint that eventually forces sharding or a different database.

Question 33

What is Amazon DocumentDB, Neptune and Timestream, in one line each?

Accepted Answer

DocumentDB is a MongoDB-compatible managed document database. Neptune is a managed graph database supporting property graph and RDF with Gremlin, openCypher and SPARQL. Timestream is a purpose-built time-series database with automatic tiering between memory and magnetic storage. The point of knowing the purpose-built family is recognising when a relational database is the wrong shape — highly connected relationship queries belong in a graph database, and high-cardinality time series belong in a time-series store. Naming the query language for Neptune shows more than surface familiarity.

Question 34

An RDS instance is at 100% CPU. What do you do?

Accepted Answer

Open Performance Insights to find the queries and wait events dominating load; check for missing indexes and full scans; look for lock contention and long-running transactions; correlate with recent deployments or batch jobs; and check whether the load is connection churn. Short term, scale up or throttle the offending workload; long term, fix the query or index. Diagnosing before scaling is what interviewers assess, because scaling a badly-indexed query just makes the same problem more expensive. Naming Performance Insights rather than describing generic database debugging is the AWS-specific part.

Question 35

What causes connection exhaustion on RDS and how do you fix it?

Accepted Answer

Too many clients each holding connections — commonly serverless or containerised workloads where concurrency multiplies pool size — or connection leaks where connections are not returned. Fix with RDS Proxy to multiplex, smaller per-instance pools with a capped maximum concurrency, and a max_connections parameter appropriate to the instance size. The arithmetic is the answer: maximum concurrent executions multiplied by pool size must stay below max_connections, which itself scales with instance memory. Being able to state that calculation is the difference between knowing the concept and having debugged the outage.

Question 36

What is Aurora Limitless Database?

Accepted Answer

Aurora Limitless provides automated horizontal sharding for Aurora PostgreSQL, distributing data and queries across multiple shards behind a single endpoint so writes scale beyond a single instance while the application still sees one database. It addresses the write-scaling ceiling that otherwise forces application-level sharding or a move to DynamoDB. The consideration is that data distribution keys still have to be chosen well, so it removes the operational burden of sharding rather than the modelling decision.

Question 37

How would you design a database layer with an RPO near zero and an RTO under 15 minutes?

Accepted Answer

Aurora with Multi-AZ replicas for in-region resilience, giving automatic failover in under a minute with no data loss thanks to the shared, six-way-replicated storage. Aurora Global Database for cross-region DR with roughly a second of RPO and a managed failover. Automated backups plus snapshots copied to a separate account, RDS Proxy so failover is transparent to the application, and a quarterly failover drill that is actually executed. The closing scenario. The differentiators are being explicit that in-region gives near-zero RPO while cross-region does not, and insisting the drill is executed — an untested DR plan has an unknown RTO, which is the same as not having one.

Question 38

What is a DB subnet group and why does it matter?

Accepted Answer

A DB subnet group is the set of subnets — in at least two Availability Zones — that RDS may place instances in. It determines where the primary and standby can live, and therefore whether Multi-AZ is even possible, and whether the database sits in private subnets with no internet route. The design point is that databases belong in private subnets with no route to an internet gateway, so the subnet group is a security control as well as a placement one. Creating a subnet group with subnets in only one AZ silently prevents Multi-AZ, which is the specific trap.

Question 39

When would you run a database on EC2 rather than RDS?

Accepted Answer

When you need an engine, version or extension RDS does not support; when you need OS-level access for an agent or custom tuning; when a specific replication topology is required; or when licensing makes it materially cheaper. You then own patching, backups, failover, monitoring and scaling. The honest framing is that the operational burden is substantial and frequently underestimated, so the requirement must be real. Being able to name a specific unsupported extension or version as the trigger is what makes the answer credible rather than dogmatic.

Question 40

What is the difference between a database engine upgrade that is minor versus major on RDS?

Accepted Answer

Minor version upgrades can be applied automatically during the maintenance window and are generally backwards-compatible. Major version upgrades change behaviour, may require parameter group changes and application testing, are never automatic, and involve a longer outage — which is why Blue/Green Deployments exist. The practical guidance is to enable auto minor version upgrade so security patches are applied, and to plan major upgrades as projects with testing. Naming Blue/Green as the mechanism that makes major upgrades safe and fast is the current best-practice answer.

AWS RDS & Aurora Interview Questions and Answers

How to use this set