Amazon RDS — Managed Relational Databases
By Pritesh Yadav 22 min read —
Amazon RDS is a managed service for traditional relational (SQL) databases, so AWS handles patching, backups, and the underlying servers while you keep control of your data and queries. The two features candidates mix up most are Multi-AZ (a standby copy in another Availability Zone purely for high availability and automatic failover) and Read Replicas (extra readable copies that scale read-heavy traffic). You also need to tell RDS apart from Aurora, DynamoDB (NoSQL), and a self-managed database you install on EC2.
Most confused here: Multi-AZ = high availability/automatic failover (NOT performance); Read Replicas = read scaling/performance (NOT failover). RDS = managed relational/SQL; DynamoDB = NoSQL. Automated backups (point-in-time, time-limited) vs snapshots (manual, kept until deleted). On RDS, AWS manages the OS/engine; on EC2 you manage everything.
Q1 An online store's RDS database runs fine most of the time, but during big sales the reporting dashboards generate so many read queries that the database slows down. The company wants to offload these read queries without changing the main database. Which RDS feature directly solves this?
- Enable Multi-AZ so the standby instance answers the reporting queries
- Add one or more Read Replicas and point the reporting dashboards at them
- Take a manual snapshot and restore it each morning for reporting
- Switch the database engine to DynamoDB for faster reads
Answer: B
Why B is correct: Read Replicas are read-only copies of the database made specifically to take read traffic (like reports and dashboards) off the primary database, which scales read performance during busy periods.
Why the other options are wrong:
- A — The Multi-AZ standby is for failover only; it does not accept any read or write traffic while the primary is healthy, so it cannot offload reporting queries.
- C — Restoring a snapshot creates a separate, point-in-time database that quickly goes stale and is operationally heavy; it is a recovery tool, not a read-scaling tool.
- D — DynamoDB is a NoSQL database with a different data model; switching engines is a major rewrite, not a way to offload reads from a relational database.
Common trap: Believing the Multi-AZ standby can serve reads. It stays idle and invisible until a failover, so it never improves performance.
Q2 A finance app must stay available even if an entire Availability Zone fails, and it needs failover to happen automatically with no manual steps. The team is not worried about read performance — only uptime. Which RDS option is designed for this?
- Create five Read Replicas spread across Availability Zones
- Enable automated backups with a 35-day retention window
- Enable Multi-AZ deployment
- Resize the instance to a larger instance class
Answer: C
Why C is correct: Multi-AZ keeps a synchronized standby copy in a second Availability Zone and automatically fails over to it if the primary or its AZ fails, which is exactly the high-availability goal described.
Why the other options are wrong:
- A — Read Replicas scale reads and are not promoted automatically; promoting one to recover from a failure is a manual action, so they do not provide automatic failover.
- B — Backups let you restore data after a problem but do nothing to keep the database continuously available during an AZ outage.
- D — A bigger instance adds capacity (vertical scaling) but still lives in one AZ, so it offers no protection if that AZ goes down.
Common trap: Picking Read Replicas for availability. Replicas are about read scaling and require manual promotion; Multi-AZ is the automatic-failover answer.
Q3 A developer says: "Our RDS Read Replica is in a different Availability Zone, so we already have automatic high availability." Why is this statement incorrect for the exam?
- Read Replicas cannot be placed in a different Availability Zone
- Read Replicas only work with DynamoDB, not RDS
- Read Replicas are encrypted and therefore cannot be used for availability
- A Read Replica is not promoted automatically on failure, so it does not provide automatic failover like Multi-AZ does
Answer: D
Why D is correct: A Read Replica is a scaling tool. If the primary fails, AWS does not automatically switch traffic to a replica — someone must manually promote it — so it does not give the automatic high availability that Multi-AZ provides.
Why the other options are wrong:
- A — Read Replicas can absolutely be placed in another AZ (or even another Region); placement is not the reason the statement is wrong.
- B — Read Replicas are an RDS/Aurora feature; DynamoDB is unrelated NoSQL and uses different mechanisms.
- C — Encryption is independent of a replica's role and does not block it from being used; this is irrelevant.
Common trap: Assuming "copy in another AZ" automatically equals high availability. Only Multi-AZ adds the automatic failover; a replica's job is read scaling.
Q4 A startup needs a flexible NoSQL database with single-digit-millisecond performance and no fixed table schema for a high-traffic mobile app. Which AWS service fits, and why is RDS not the right choice here?
- Amazon DynamoDB, because it is a managed NoSQL database, while RDS is for relational (SQL) workloads
- Amazon RDS for MySQL, because RDS supports NoSQL data through Read Replicas
- Amazon Aurora, because Aurora is the NoSQL version of RDS
- Amazon Redshift, because it is AWS's NoSQL key-value store
Answer: A
Why A is correct: DynamoDB is AWS's managed NoSQL (non-relational) key-value and document database built for flexible schemas and very fast, large-scale access. RDS is for relational databases that use fixed tables and SQL, so it does not match a schema-less NoSQL requirement.
Why the other options are wrong:
- B — RDS is relational only; Read Replicas just copy a relational database and do not add NoSQL capability.
- C — Aurora is a relational (MySQL/PostgreSQL-compatible) engine within RDS, not a NoSQL database.
- D — Redshift is a relational data warehouse for analytics, not a NoSQL key-value store.
Common trap: Thinking Aurora is the "NoSQL RDS." Aurora is still fully relational; DynamoDB is the NoSQL service.
Q5 Which statement best describes the difference between RDS automated backups and manual DB snapshots?
- Automated backups are kept forever, while snapshots are deleted after 7 days
- Automated backups enable point-in-time recovery within a retention window and are deleted when retention expires, while manual snapshots are kept until you delete them
- Snapshots run continuously in the background, while automated backups must be taken by hand
- Automated backups and snapshots are identical; the names are interchangeable
Answer: B
Why B is correct: Automated backups let you restore to any point in time inside a retention period (up to 35 days) and are removed automatically once that period passes. Manual snapshots are user-initiated and persist until you explicitly delete them, making them useful for long-term keeps.
Why the other options are wrong:
- A — This reverses the behavior; automated backups expire by retention while snapshots are the ones that persist indefinitely.
- C — It is backwards: automated backups are the ones AWS runs on a schedule, and snapshots are the manual ones.
- D — They differ in lifecycle and how they are created, so they are not interchangeable.
Common trap: Assuming automated backups are kept forever. They are tied to a retention window; for indefinite retention you take a manual snapshot.
Q6 A team currently installs and runs MySQL themselves on an EC2 instance. They are tired of handling OS patching, database engine upgrades, backups, and replication setup. If they move to Amazon RDS, which tasks does AWS take over?
- Designing the database schema and writing the SQL queries
- Deciding which data is sensitive and tuning every individual query
- Nothing changes; RDS and self-managed EC2 require the same operational work
- Operating-system and database-engine patching, automated backups, and managing the underlying hardware
Answer: D
Why D is correct: RDS is managed, so AWS handles the heavy operational chores — patching the OS and database engine, running automated backups, and managing the servers and storage underneath. That is the main reason teams switch from self-managed databases on EC2.
Why the other options are wrong:
- A — Schema design and query writing are always the customer's job; RDS never does application-level design for you.
- B — Classifying sensitive data and optimizing application queries remain customer responsibilities under the shared responsibility model.
- C — The whole point of RDS is that it removes much of the operational burden you carry when self-managing on EC2.
Common trap: Expecting RDS to also handle schema design and query tuning. Those stay with you; RDS offloads the infrastructure and maintenance work, not your application logic.
Q7 A company's RDS instance is running out of CPU and memory because the workload has grown, but the number of read queries is normal. They want more power on the same database. What is the most direct way to scale here?
- Add Read Replicas to spread the CPU load
- Enable Multi-AZ to double the available CPU
- Change to a larger instance class (vertical scaling / scale up)
- Convert the database to DynamoDB on-demand capacity
Answer: C
Why C is correct: Moving to a larger instance class gives the same database more CPU and memory — this is vertical scaling (scaling up), the standard way to handle a primary that is simply too small for its workload.
Why the other options are wrong:
- A — Read Replicas only help when reads are the bottleneck; here reads are normal, so they would not fix the primary's CPU/memory pressure (and writes still hit the primary).
- B — Multi-AZ adds a standby for failover, not extra usable CPU; the standby does not process your workload.
- D — Switching to DynamoDB is a complete data-model change, not a scaling adjustment for a relational database.
Common trap: Thinking Multi-AZ or replicas add capacity to the primary. To give one database more raw power, you resize the instance (scale vertically).
Q8 Which of the following is a genuine benefit of Amazon Aurora compared with standard RDS engines, while still being a relational database?
- Aurora is a NoSQL database that removes the need for SQL
- Aurora removes the need for any backups because data is never lost
- Aurora can only run on EC2 instances you manage yourself
- Aurora is MySQL- and PostgreSQL-compatible and offers higher performance and storage that grows automatically, while remaining relational
Answer: D
Why D is correct: Aurora is AWS's cloud-optimized relational engine that is drop-in compatible with MySQL and PostgreSQL, delivers higher performance than the standard engines, and grows its storage automatically — all while staying relational.
Why the other options are wrong:
- A — Aurora is relational and uses SQL; it is not NoSQL.
- B — Aurora is highly durable but still uses backups and snapshots; no database eliminates the need for backups.
- C — Aurora is a fully managed part of RDS, not something you install on your own EC2 instances.
Common trap: Labeling Aurora as NoSQL or as a self-managed engine. It is a managed, relational, MySQL/PostgreSQL-compatible service inside the RDS family.
Q9 A new application has an unpredictable, spiky workload: busy for a few hours, then almost idle for long stretches. The team wants a relational database that automatically scales capacity up and down and can save money when traffic is low. Which option fits best?
- Amazon Aurora Serverless
- A large fixed-size RDS instance running 24/7
- DynamoDB with provisioned capacity
- A self-managed PostgreSQL server on a Reserved EC2 instance
Answer: A
Why A is correct: Aurora Serverless automatically adjusts relational database capacity to match demand and can scale down when traffic is low, so you pay for what you use — ideal for unpredictable, intermittent workloads.
Why the other options are wrong:
- B — A fixed-size instance running all the time wastes money during idle periods and cannot shrink automatically.
- C — DynamoDB is NoSQL, so it does not fit a relational requirement, and provisioned capacity is the fixed-capacity mode.
- D — A Reserved EC2 instance commits to steady usage, which is the opposite of what a spiky, intermittent workload wants, and you still manage everything yourself.
Common trap: Reaching for DynamoDB whenever "serverless/auto-scaling" appears. For a relational workload that must auto-scale, Aurora Serverless is the match.
Q10 A compliance rule requires that data stored in the company's RDS database be encrypted at rest. What is the correct understanding of RDS encryption for the exam?
- RDS cannot encrypt data; you must move to DynamoDB for encryption
- Encryption only protects data while it travels over the network, not data stored on disk
- You must manually encrypt each row in your application because RDS offers no encryption
- RDS supports encryption at rest (using AWS KMS keys), which also covers the underlying storage, automated backups, snapshots, and read replicas of that database
Answer: D
Why D is correct: RDS offers built-in encryption at rest backed by AWS KMS keys. When a database is encrypted, that protection extends to its storage, automated backups, snapshots, and read replicas, satisfying at-rest compliance requirements.
Why the other options are wrong:
- A — RDS supports encryption natively; there is no need to switch to DynamoDB to get it.
- B — That describes encryption in transit; the requirement here is encryption at rest, which RDS handles separately.
- C — Manual per-row encryption in the app is unnecessary because RDS provides encryption at rest as a feature.
Common trap: Confusing encryption at rest (data on disk) with encryption in transit (data on the network). The compliance ask here is at rest, which RDS encryption with KMS covers.
Q11 Which scenario is the clearest signal to choose Amazon RDS rather than another database approach?
- You need a key-value store for billions of items with a flexible, changing schema
- You have an existing application that uses standard SQL and relational tables, and you want AWS to manage backups, patching, and high availability for you
- You want to store large media files like videos and images cheaply
- You need a fully self-managed database where you control the operating system and install custom database extensions yourself
Answer: B
Why B is correct: RDS is the right fit when you have a relational (SQL) workload and want a managed service to handle backups, patching, and high availability, so the team focuses on the application instead of database operations.
Why the other options are wrong:
- A — A flexible-schema, massive key-value store points to DynamoDB (NoSQL), not relational RDS.
- C — Large media files belong in Amazon S3 object storage, not a relational database.
- D — Wanting full OS control and custom engine tweaks points to self-managing a database on EC2, not the managed RDS service.
Common trap: Forcing every database need into RDS. Choose RDS specifically for managed relational SQL workloads; other needs map to DynamoDB, S3, or EC2.
Q12 Under the AWS shared responsibility model, which task remains the customer's responsibility even when using Amazon RDS?
- Patching the database engine and underlying operating system
- Replacing failed physical disks in the data center
- Configuring database users, managing access permissions, and protecting the application's data and credentials
- Maintaining the physical security of the AWS facilities
Answer: C
Why C is correct: Even with RDS managing the infrastructure, the customer is still responsible for security "in" the database — setting up database users, controlling who can access what, and safeguarding their data and credentials.
Why the other options are wrong:
- A — RDS handles engine and OS patching for you, so this is AWS's job, not the customer's.
- B — Replacing physical hardware is part of AWS's responsibility for the underlying infrastructure.
- D — Physical security of data centers is always AWS's responsibility.
Common trap: Assuming "managed" means AWS does everything. You still own access control, user management, and data protection — that is the "security in the cloud" half.
Q13 A team needs to keep a particular RDS database backup for several years to meet an audit requirement, well beyond the maximum automated backup retention period. What should they use?
- Take a manual DB snapshot, which persists until you choose to delete it
- Rely on automated backups and increase retention to 10 years
- Enable Multi-AZ, since the standby keeps a permanent backup
- Create a Read Replica and never promote it, so it acts as the archive
Answer: A
Why A is correct: Manual snapshots are kept until you explicitly delete them, so they are the right tool for long-term, multi-year retention that outlasts the automated backup window (which maxes out at 35 days).
Why the other options are wrong:
- B — Automated backup retention is capped (up to 35 days), so it cannot meet a multi-year requirement.
- C — The Multi-AZ standby is a live failover copy, not a long-term archive of point-in-time backups.
- D — A Read Replica is a live, changing copy for read scaling, not a frozen archival snapshot.
Common trap: Trying to stretch automated backups for long-term archiving. Their retention is limited; manual snapshots are the durable, keep-as-long-as-you-want option.
Q14 Which of the following is NOT a database engine that Amazon RDS supports?
- MongoDB
- PostgreSQL
- MySQL
- Microsoft SQL Server
Answer: A
Why A is correct: RDS supports relational engines: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and Amazon Aurora. MongoDB is a NoSQL document database and is not an RDS engine.
Why the other options are wrong:
- B — PostgreSQL is a supported RDS relational engine.
- C — MySQL is a supported RDS relational engine.
- D — Microsoft SQL Server is a supported RDS relational engine.
Common trap: Seeing a familiar database name and assuming RDS runs it. RDS is relational only; MongoDB is NoSQL (on AWS its managed look-alike is DocumentDB, not RDS).
Q15 A global app has its primary RDS database in one Region, and users in a distant Region complain that reads are slow. The team wants faster local reads for those users without moving the primary. Which approach helps most?
- Enable Multi-AZ in the primary Region
- Create a cross-Region Read Replica closer to the distant users
- Increase the automated backup retention period
- Switch the database engine to a larger instance class
Answer: B
Why B is correct: A cross-Region Read Replica places a readable copy near the far-away users, letting them read from a nearby database and cutting latency, without disturbing the primary in the original Region.
Why the other options are wrong:
- A — Multi-AZ adds a standby within the same Region for failover, so it does nothing for users in a distant Region.
- C — Backup retention is about recovery, not read latency for remote users.
- D — A bigger instance adds power in the same location but does not bring data closer to far-away users.
Common trap: Using Multi-AZ to solve a geographic latency problem. Multi-AZ is same-Region failover; Read Replicas (including cross-Region) are the tool for local read performance.
Q16 Which statement correctly contrasts Amazon RDS with running your own database on Amazon EC2?
- With RDS you must still manually install OS updates and configure replication, just like on EC2
- With EC2 you get a managed service and AWS handles patching, while RDS makes you manage everything
- With RDS, AWS automates patching, backups, and failover setup, whereas on EC2 you are responsible for installing, patching, backing up, and managing the database yourself
- There is no operational difference; the choice only affects pricing
Answer: C
Why C is correct: RDS is the managed option where AWS automates patching, backups, and high-availability setup. On EC2 you self-manage everything — installing the engine, patching the OS, configuring backups and replication — trading more control for more operational work.
Why the other options are wrong:
- A — RDS automates OS patching and offers built-in replication features, so you do not do those manually as you would on EC2.
- B — This reverses reality: RDS is the managed one, EC2 is the self-managed one.
- D — The operational difference is large and is the main reason to choose one over the other, not just price.
Common trap: Mixing up which option is managed. RDS = managed (less operational work); database on EC2 = self-managed (full control, full responsibility).
Q17 During a planned maintenance window, AWS needs to patch a Multi-AZ RDS database. How does Multi-AZ help minimize downtime in this case?
- It lets the standby serve read and write traffic, doubling throughput during patching
- It eliminates the need for any maintenance because patches are skipped
- It automatically creates Read Replicas to take over reads during the patch
- It allows AWS to patch the standby first, then fail over to it, reducing the disruption to the application
Answer: D
Why D is correct: With Multi-AZ, maintenance can be applied to the standby and then a failover switches roles to it, which shortens the window where the application is affected compared with patching a single instance directly.
Why the other options are wrong:
- A — The standby never serves live traffic, so it does not double throughput; its role is failover only.
- B — Maintenance and patches still happen; Multi-AZ reduces their impact rather than skipping them.
- C — Multi-AZ does not spin up Read Replicas; replicas are a separate feature you configure for read scaling.
Common trap: Imagining the Multi-AZ standby actively handles traffic. It is a passive failover target — useful for reducing downtime, not for adding capacity.
Q18 A manager asks whether enabling Multi-AZ on RDS will improve the database's query performance for end users. What is the most accurate answer?
- Yes, Multi-AZ doubles read and write performance automatically
- No, Multi-AZ improves availability and failover, not performance; to scale reads you use Read Replicas and to scale up you resize the instance
- Yes, but only for write-heavy workloads
- No, Multi-AZ actually reduces availability while improving performance
Answer: B
Why B is correct: Multi-AZ exists for high availability and automatic failover, not performance. The standby is idle until needed. To improve read performance you add Read Replicas, and to add raw capacity you scale the instance up.
Why the other options are wrong:
- A — Multi-AZ does not double performance; the standby does not serve traffic.
- C — Multi-AZ does not boost write performance either; writes still go to the single primary.
- D — Multi-AZ increases availability, not decreases it, and it does not trade availability for performance.
Common trap: Believing Multi-AZ is a performance feature. It is purely an availability feature; performance comes from Read Replicas (reads) or larger instances (vertical scaling).
Q19 A company wants a managed relational database but is worried about losing data if the database is accidentally corrupted. They want to be able to restore the database to a specific minute in the recent past. Which RDS capability provides this?
- Point-in-time recovery using automated backups
- Promoting a Read Replica to the primary
- Enabling Multi-AZ failover
- Increasing the instance size to a larger class
Answer: A
Why A is correct: RDS automated backups support point-in-time recovery, letting you restore the database to any specific moment within the retention window — exactly what is needed to roll back after accidental corruption.
Why the other options are wrong:
- B — Promoting a Read Replica gives you a current copy of the data, including any corruption; it does not roll back to an earlier minute.
- C — Multi-AZ failover switches to an up-to-date standby, which would also carry the corrupted data; it is for availability, not data rollback.
- D — Resizing the instance adds capacity and has nothing to do with restoring past data.
Common trap: Thinking replicas or Multi-AZ can undo corruption. Both keep current (possibly corrupted) data; point-in-time recovery from backups is what rewinds to a clean moment.
Q20 A team running Aurora wants both high availability and the ability to handle large volumes of read traffic. Which combination correctly maps each goal to the right Aurora capability?
- Use automated backups for high availability and snapshots for read scaling
- Use a single large instance for both goals at once
- Use Aurora's multi-AZ replication for high availability/failover and Aurora Replicas to scale read traffic
- Use DynamoDB for high availability and RDS for reads
Answer: C
Why C is correct: Aurora keeps copies of data across multiple Availability Zones for high availability and automatic failover, and Aurora Replicas serve read traffic to scale read-heavy workloads. Each goal maps to a distinct capability — availability vs read scaling.
Why the other options are wrong:
- A — Backups and snapshots are for recovery, not for continuous availability or live read scaling.
- B — One larger instance adds power but does not provide automatic failover or distribute reads across replicas.
- D — Mixing in DynamoDB introduces a NoSQL service for no reason; Aurora already provides both availability and read scaling within one relational service.
Common trap: Collapsing availability and read scaling into one feature. They are separate concerns: multi-AZ for availability/failover, replicas for read scaling — the same distinction as standard RDS.