11 Database Services · AWS Cloud Practitioner

In this chapter you will learn the difference between relational and NoSQL databases, why most AWS customers choose managed databases over running their own on Amazon EC2, and how to match common workloads to the right AWS database service: Amazon RDS, Amazon Aurora, Amazon DynamoDB, Amazon ElastiCache, Amazon MemoryDB, Amazon DocumentDB, Amazon Neptune, Amazon Keyspaces, Amazon Timestream, and Amazon Redshift. You will also review how AWS Database Migration Service moves existing databases into AWS. This chapter maps to exam Domain 3, Cloud Technology and Services, Task Statement 3.4: Identify AWS database services.

11.1 Why databases deserve their own chapter

Almost every application you will ever meet stores data somewhere. An online shop keeps products, customers, and orders. A mobile game keeps player profiles and high scores. A hospital keeps appointments and test results. That data has to be stored safely, found quickly, backed up, and protected from people who should not see it. On the CLF-C02 exam you will not be asked to write a SQL query or tune an index. You will be asked to read a short business scenario and pick the AWS database service that fits it. Questions often hinge on a single phrase: “relational,” “key-value,” “microsecond latency,” “graph,” “MongoDB-compatible,” “data warehouse.” This chapter teaches you to spot those phrases and connect each one to a service.

AWS describes its approach as purpose-built databases. Instead of forcing every workload into one general database, AWS offers a family of engines, each designed for a particular data shape and access pattern. Your job, as a cloud practitioner, is to know the family well enough to point a team in the right direction.

11.2 Relational and NoSQL in plain English

Relational databases

A relational database stores data in tables made of rows and columns, much like a set of spreadsheets that know about each other. Every row in a table has the same columns, which is called a fixed schema. Tables are linked through keys: an Orders table might hold a customer_id column that points to a row in the Customers table. You ask questions with SQL (Structured Query Language) and can combine tables with joins, for example “show every order placed by customers in Toronto last month.”

Relational databases also offer strong transactions, often described with the acronym ACID (atomicity, consistency, isolation, durability). In everyday terms, a transaction either completes fully or not at all. When you move money between two bank accounts, you never want the debit to succeed while the credit fails. That guarantee is why relational databases still run most finance, inventory, and order-management systems.

Common relational engines include MySQL, PostgreSQL, MariaDB, Oracle Database, Microsoft SQL Server, and IBM Db2.

NoSQL databases

NoSQL (“not only SQL”) is an umbrella term for databases that do not use the classic table-and-join model. They trade some relational features for flexibility and scale. There are several kinds:

Key-value: each item is found by a unique key, like a giant, very fast dictionary.

Document: each record is a JSON-like document that can nest data inside it.

Graph: data is stored as nodes and the relationships between them.

Wide-column: rows can have many, varying columns, built for very high write volumes.

In-memory: data lives in RAM for extremely fast reads.

Time series: data points are stamped with a time and usually arrive in order.

NoSQL databases usually have a flexible schema. Two items in the same table can carry different attributes, and you can add a new attribute without changing the whole table. They are designed to scale horizontally, spreading data across many servers, which lets them handle huge numbers of requests with steady, low latency.

Figure 11.1: The same customer and order data stored as related relational tables (left) and as a single key-value item with nested orders (right).

Good to know

“NoSQL” does not mean “no structure” or “no queries.” It means the database is optimized for a different access pattern than ad hoc SQL joins. Many NoSQL services, including DynamoDB, now offer SQL-like query languages for convenience. How to tell them apart on the exam

Clue in the question Points toward
Joins, complex queries, transactions Relational (RDS, Aurora)
Fixed schema, existing SQL app Relational
Key-value, massive scale, single-digit ms DynamoDB
Flexible or changing schema NoSQL
Analytics over large historical data Redshift

11.3 Self-managed on EC2 versus fully managed

You can run any database you like on an Amazon EC2 instance. You launch the instance, install the database software, configure storage, and you are in business. This is sometimes the right choice, but think about everything you have now signed up for:

Patching the operating system and the database software.

Configuring and testing backups, and practicing restores.

Building replication and failover for high availability.

Monitoring disk space and scaling storage before it fills up.

Hardening security and managing encryption.

Under the shared responsibility model, AWS secures the physical hardware and the hypervisor, but everything inside your EC2 instance is your responsibility.

A managed database service shifts much of that undifferentiated heavy lifting to AWS. With Amazon RDS, for example, AWS provisions the hardware, installs and patches the database engine during a maintenance window you choose, takes automated backups, and can maintain a standby copy in another Availability Zone. You still own your data, your schema, your queries, who can access the database, and settings such as whether encryption is turned on. Task Database on EC2 Managed (for example RDS)

Hardwareand data center AWS AWS
OS patching You AWS
Database software patching You AWS (in your window)
Backupsand failover You build them Built-in options
Schema, queries, access You You

So when would you still choose EC2? When you need something a managed service does not offer: full operating-system access, a database engine or version that the managed service does not support, or custom software installed alongside the database. For some commercial engines, Amazon RDS Custom (available for Oracle and SQL Server) sits in between, giving you access to the underlying OS while AWS still automates much of the management.

Exam tip

If a question asks how to “reduce operational overhead,” “avoid managing patches and backups,” or “let the team focus on the application,” the answer is almost always a managed service such as RDS, Aurora, or DynamoDB rather than a database on EC2.

11.4 Amazon RDS

Amazon Relational Database Service (Amazon RDS) is a managed service for running relational databases in the cloud. It supports several popular engines:

Amazon Aurora (MySQL-compatible and PostgreSQL-compatible), covered in Section 11.5 You choose an engine, an instance class (the CPU and memory size, similar to EC2 instance types), and storage. AWS handles provisioning, patching, backups, and monitoring hooks. You connect to RDS through an endpoint, a DNS name your application uses instead of a server’s IP address. For commercial engines you can often pick between license-included pricing and bring-your-own-license.

Multi-AZ deployments: for availability

A Multi-AZ deployment keeps a standby copy of your database in a different Availability Zone in the same Region. Every write to the primary is copied to the standby synchronously, so the standby is always up to date. If the primary fails, its AZ has a problem, or you perform certain maintenance, RDS automatically fails over: it points the database endpoint to the standby, which becomes the new primary. Your application reconnects to the same endpoint name, usually within a minute or two.

In the classic Multi-AZ instance deployment the standby does not serve read traffic; it exists purely for resilience. RDS also offers a Multi-AZ DB cluster option for MySQL and PostgreSQL with two readable standbys, but for the exam the key idea stays the same: Multi-AZ is about high availability, not performance.

Read replicas: for read performance

A read replica is a read-only copy of your database that is updated asynchronously from the primary. Applications send writes to the primary and can send read queries, such as reports, dashboards, or product-page lookups, to one or more replicas. This spreads the read load so the primary is not overwhelmed.

Read replicas can live in the same AZ, a different AZ, or even a different Region. A cross-Region replica keeps a copy of your data closer to users in another part of the world and can serve as part of a disaster recovery plan, because you can promote a replica to become a standalone, writable database.

Figure 11.2: Multi-AZ keeps a synchronous standby for automatic failover; read replicas receive asynchronous copies and serve read traffic.

Common trap

Multi-AZ and read replicas are not interchangeable. “Survive an AZ outage with automatic failover” means Multi-AZ. “Improve performance of a read-heavy application” means read replicas. If a question mentions both availability and read scaling, the answer may use both.

Backups and snapshots

RDS gives you two ways to protect data:

Automated backups: RDS takes a daily backup of your instance and stores transaction logs, which lets you perform a point-in-time restore to any second within your retention period. You set retention from 1 to 35 days. Manual snapshots: you take these whenever you like, for example before a risky schema change. They are kept until you delete them, even if you delete the database.

Backups are stored in Amazon S3 behind the scenes, so you do not manage that storage yourself. A restore always creates a new database instance; it does not overwrite the existing one.

Security and scaling

RDS databases run inside your VPC, typically in private subnets with no public access, protected by security groups that only allow traffic from your application servers. You can encrypt storage, backups, and replicas at rest with AWS KMS keys and use TLS for data in transit. Storage can grow automatically with storage autoscaling, and you can change the instance class to scale vertically. For many engines you can also use IAM database authentication instead of storing passwords in application code.

Hands-on lab

Mini lab: create a small RDS database (Free Tier eligible where available)

1. Sign in to the AWS Management Console and open RDS.
2. Choose Create database, then Standard create.
3. Under Engine options, choose PostgreSQL (or MySQL).
4. Under Templates, choose Free tier if it is offered for your account, otherwise Dev/Test.
5. Leave availability as Single-AZ for this lab. Note that production would use a Multi-AZ option.
6. Enter an identifier such as lab-db-1 , a master username, and a password (or let AWS manage the secret in AWS Secrets Manager).
7. Under Connectivity, set Public access to No.
8. Review Backup retention (for example, 7 days) and choose Create database.
9. When the status reads Available, open the database and find its endpoint. Then delete the database, choosing whether to keep a final snapshot, to avoid charges.

Figure 11.3: A simplified create-database screen showing creation method, engine, template, availability, instance settings, and connectivity. (Illustration, not an actual AWS screenshot.)

11.5 Amazon Aurora

Amazon Aurora is a relational database engine built by AWS for the cloud. It is compatible with MySQL and PostgreSQL, which means applications written for those engines usually work with Aurora with little or no change. Aurora is managed through Amazon RDS, so everything you learned about endpoints, backups, and maintenance windows carries over.

What makes Aurora different is its storage layer. Instead of a disk attached to one server, Aurora uses a distributed, self-healing storage volume that keeps six copies of your data across three Availability Zones and grows automatically as you add data. Aurora can have up to 15 low-latency read replicas that share that same storage volume, and failover to a replica is typically fast. AWS states that Aurora delivers several times the throughput of standard MySQL and PostgreSQL on similar hardware, at a fraction of the cost of commercial databases.

Aurora Serverless

Aurora Serverless v2 automatically scales database capacity up and down in fine-grained steps based on demand. You set a minimum and maximum capacity and pay for the capacity you actually use. It suits workloads that are unpredictable, spiky, or used only part of the day, such as a new application whose traffic you cannot forecast, or development and test databases.

Aurora Global Database

An Aurora Global Database spans multiple AWS Regions. One primary Region handles writes, and data is replicated to one or more secondary Regions with typical lag of under a second. Secondary Regions serve fast local reads and can be promoted to take over writes if the primary Region has a major outage. Think “global users” and “Region-level disaster recovery.”

Aurora DSQL

Amazon Aurora DSQL, which became generally available in 2025, is a serverless, distributed SQL database that is PostgreSQL-compatible. There are no instances to choose or manage, and it scales automatically. Its standout feature is active-active operation: applications can read and write in multiple Regions at once with strong consistency, which makes it a fit for globally distributed applications that need very high availability. At this level, remember the one-line summary: serverless, distributed, PostgreSQL-compatible SQL with multi-Region active-active writes.

Exam tip

“MySQL- or PostgreSQL-compatible with higher performance and availability than standard RDS” points to Aurora. “Unpredictable workload, pay only for capacity used” points to Aurora Serverless. “Read in many Regions with fast cross-Region disaster recovery” points to Aurora Global Database.

11.6 Amazon DynamoDB

Amazon DynamoDB is AWS’s flagship NoSQL database: a fully managed, serverless key-value and document database that delivers consistent single-digit-millisecond performance at virtually any scale. There are no servers or instances to manage, no software to patch, and no storage to provision. You create a table, choose a partition key (and optionally a sort key), and start reading and writing items.

DynamoDB automatically replicates data across multiple Availability Zones in a Region. Common uses include shopping carts, user profiles and preferences, session data, gaming leaderboards and player state, IoT device data, and any high-traffic application where requests are simple lookups by key.

Capacity modes

On-demand: you pay per request and DynamoDB instantly accommodates traffic as it rises and falls. Great for new or unpredictable workloads, and the recommended default for many teams.

Provisioned: you specify the read and write capacity you expect, optionally with auto scaling, and pay for that capacity. Often cheaper for steady, predictable traffic.

Features worth knowing

Global tables: replicate a table across multiple Regions so that applications can read and write locally in each Region (multi-active). Ideal for globally distributed users and Region-level resilience.

DynamoDB Accelerator (DAX): an in-memory cache built specifically for DynamoDB that reduces read latency from milliseconds to microseconds without changing application logic much.

Backups: on-demand backups plus point-in-time recovery for continuous protection.

DynamoDB Streams: a time-ordered record of item changes that can trigger AWS Lambda functions, for example to send a welcome email when a new user item appears.

Time to Live (TTL): automatically deletes expired items, such as old sessions, at no extra cost. Encryption at rest is always on.

Common trap

DynamoDB is not the right choice when a question stresses complex joins, ad hoc relational reporting, or an existing application written for Oracle or SQL Server. Those clues point to RDS or Aurora. Also remember that DAX accelerates DynamoDB only; for caching in front of RDS, use ElastiCache.

11.7 In-memory databases: ElastiCache and MemoryDB

Reading from memory is far faster than reading from disk. AWS offers two in-memory services that sound similar but solve different problems.

Amazon ElastiCache

Amazon ElastiCache is a managed in-memory cache. It supports three engines: Valkey (an open source fork of Redis that AWS recommends for new workloads), Redis OSS, and Memcached. You can run it on nodes you size yourself or choose ElastiCache Serverless, which scales automatically.

The classic pattern is to put ElastiCache in front of a database. When the application needs data, it checks the cache first. On a hit, it gets the answer in microseconds. On a miss, it reads from the database and stores the result in the cache for next time. This reduces load on the database, cuts latency, and can lower cost because you may need a smaller database. ElastiCache is also widely used for session stores, real-time leaderboards, and rate limiting.

A cache is usually treated as a copy of data that lives somewhere else. If the cache is lost, the application can rebuild it from the source database.

Amazon MemoryDB

Amazon MemoryDB is a durable, in-memory primary database compatible with Valkey and Redis OSS. It offers microsecond reads like a cache, but it also stores every write in a distributed transaction log across multiple Availability Zones, so you can use it as the system of record, not just a cache. Choose MemoryDB when you want Redis-style data structures and speed for an application whose data must not be lost, such as a real-time inventory or a high-speed user-session service that is the only copy of the data.

Need Service
Cache in front of RDS oranother database ElastiCache
Cache in front of DynamoDB specifically DAX
Durable in-memory primary database MemoryDB

11.8 Other purpose-built databases

Amazon DocumentDB (with MongoDB compatibility)

Amazon DocumentDB is a managed document database that stores JSON-like documents and is compatible with MongoDB APIs and drivers. Teams that built applications on MongoDB can move to a managed AWS service without rewriting their code. Typical uses: content management, product catalogs, and user profiles where each record has a nested, evolving structure.

Amazon Neptune

Amazon Neptune is a managed graph database. Graph databases shine when the relationships between things matter as much as the things themselves: “Which friends of my friends also bought this product?” or “Which accounts share a phone number, device, and address with this known fraudster?” Use cases include social networks, recommendation engines, fraud detection, and knowledge graphs. A related option, Neptune Analytics, runs graph analytics on large graphs in memory.

Amazon Keyspaces (for Apache Cassandra)

Amazon Keyspaces is a serverless, managed wide-column database compatible with Apache Cassandra. Teams running Cassandra clusters on premises can use the same Cassandra Query Language (CQL) code and drivers without managing Cassandra nodes. The exam clue is simply “Cassandra.”

Amazon Timestream

Amazon Timestream is a managed time-series database for data points that carry a timestamp, such as IoT sensor readings, application metrics, and industrial telemetry. Time-series databases are tuned for writing data as it arrives and for queries such as “average temperature per hour over the last week.” Timestream offers a managed InfluxDB option for teams using that popular open source time-series engine. AWS has adjusted the Timestream product line over time, so check current availability of each option before designing a new workload. For the exam, “time series” or “IoT measurements over time” points to Timestream.

Amazon Redshift

Amazon Redshift is a fully managed, petabyte-scale data warehouse. Unlike the databases above, which handle many small, fast transactions (called OLTP, online transaction processing), Redshift is designed for analytics (OLAP, online analytical processing): complex SQL queries that scan and aggregate huge amounts of historical data, such as “total sales by region by quarter for the last five years.”

Redshift stores data in columnar format and spreads queries across many nodes in parallel. You can run it on provisioned clusters or use Redshift Serverless, which scales automatically and charges for what you use. Redshift Spectrum lets you query data that sits in Amazon S3 without loading it into Redshift first. Business intelligence tools, including Amazon QuickSight, connect to Redshift to build dashboards. Chapter 13 places Redshift in the wider analytics picture.

Good to know

Amazon QLDB, a ledger database that appeared in older study material, has reached end of support. If you see a requirement for an immutable, verifiable history of changes, AWS now suggests alternatives such as Aurora PostgreSQL with audit features. It is unlikely to be a correct answer on a current exam.

Solid border = operational (OLTP) databases. Dashed border = analytics-oriented stores.

Figure 11.4: Map of AWS purpose-built databases by data model, with typical use cases for each.

11.9 Choosing the right database

When you face a database question, walk through three questions in order:

1. Is this analytics or operations? Large-scale reporting and business intelligence over historical data points to Redshift. Day-to-day application reads and writes point to an operational database.
2. Is the data relational? If the scenario mentions SQL, joins, transactions, or an existing relational engine, choose RDS or Aurora. Choose Aurora when the question stresses performance, cloud-native high availability, Serverless, or global reach.
3. If not relational, what is the data shape? Key-value at scale goes to DynamoDB; documents to DocumentDB; relationships to Neptune; Cassandra to Keyspaces; time-stamped measurements to Timestream; caching to ElastiCache; a durable in-memory store to MemoryDB.

Then ask one more question that applies to everything in AWS: what is the most managed option that meets the need? Only choose a self-managed database on EC2 if the scenario demands OS-level control or an unsupported engine. Choosing a database: a quick decision tree

Is the main job analytics on

huge historical data sets?

Yes
Amazon Redshift
No
Structured data with joins and

transactions (SQL)?

or access pattern?

most managed option that fits. Self-manage on EC2 only when you truly need control.

Figure 11.5: A decision tree for choosing an AWS database service based on workload type and data shape.

Real-world example

Real-world scenario: A ticket-booking start-up runs its order system on PostgreSQL in its own data center. The team is small and tired of 2 a.m. disk alarms. They move orders to Aurora PostgreSQL-Compatible with a reader in a second AZ, store seat-hold sessions that expire after ten minutes in DynamoDB with TTL, put ElastiCache in front of Aurora for the busy event-listing pages, and copy nightly order data into Redshift Serverless so the marketing team can run sales reports without slowing down the booking system. Each piece of data lives in the database best suited to it.

11.10 Migrating databases to AWS

You met AWS Database Migration Service (AWS DMS) in the migration chapter (Chapter 3); here is a short recap from the database point of view.

AWS DMS moves data from a source database to a target database while the source stays fully operational, which keeps downtime to a minimum. It can perform a one-time full load and then use change data capture (CDC) to continuously replicate ongoing changes until you are ready to switch the application over.

Homogeneous migration: same engine on both sides, such as on-premises MySQL to RDS for MySQL.

Heterogeneous migration: different engines, such as Oracle to Aurora PostgreSQL. The schema and code (tables, views, stored procedures) must first be converted. DMS Schema Conversion (or the downloadable AWS Schema Conversion Tool, AWS SCT) handles that step, and DMS then moves the data.

DMS is also used for ongoing replication, for example feeding a copy of operational data into Redshift or Amazon S3 for analytics. For very large datasets with limited network bandwidth, an AWS Snowball device can carry the initial bulk load.

Exam tip

“Migrate a database with minimal downtime” is DMS. “Convert the schema from Oracle to PostgreSQL” is the Schema Conversion Tool or DMS Schema Conversion. Moving to Aurora or RDS after migration is the “replatform” strategy from the 7 Rs.

Chapter 11 summary

Relational databases use fixed schemas, SQL, joins, and transactions; NoSQL databases use flexible schemas and scale horizontally for specific access patterns.

Managed database services shift patching, backups, and failover to AWS; run a database on EC2 only when you need OS access or an unsupported engine.

Amazon RDS runs MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2, and Aurora. Multi-AZ provides a synchronous standby for automatic failover; read replicas provide asynchronous copies for read scaling. RDS automated backups enable point-in-time restore within a 1 to 35 day retention period; manual snapshots are kept until you delete them.

Aurora is MySQL- and PostgreSQL-compatible, keeps six copies of data across three AZs, and offers Serverless v2, Global Database, and the serverless, multi-Region Aurora DSQL.

DynamoDB is a serverless key-value and document database with single-digit-millisecond latency, on-demand or provisioned capacity, global tables, and DAX for microsecond caching.

ElastiCache (Valkey, Redis OSS, Memcached) is a cache; MemoryDB is a durable in-memory primary database. DocumentDB is for MongoDB-compatible documents, Neptune for graphs, Keyspaces for Cassandra, Timestream for time series, and Redshift for data warehousing and analytics.

AWS DMS migrates databases with minimal downtime; schema conversion tools handle heterogeneous moves.

Key terms
Term Meaning
Relational database Tables with fixed schema, queried with SQL
NoSQL Non-relational databases with flexible schemas
Managed service AWS runs the infrastructureand routine tasks
Multi-AZ Synchronous standby in another AZ for failover
Read replica Asynchronous read-only copy for scaling reads
Point-in-time restore Restore to any second within retention
Aurora Serverless v2 Aurorathat scales capacity automatically
Aurora Global Database Aurorareplicated across Regions
Aurora DSQL Serverless distributed SQL, active-active
DynamoDB global tables Multi-Region, multi-active DynamoDB tables
DAX In-memory cache for DynamoDB
ElastiCache Managed in-memory cache
MemoryDB Durable in-memory primary database
Data warehouse Store optimized foranalytics (Redshift)
AWS DMS Service that migratesand replicates databases
Practice questions

1. A company runs a MySQL database on EC2 instances and spends many hours each month applying patches and testing backups. Which AWS service would reduce this operational overhead while keeping MySQL compatibility?

A. Amazon DynamoDB B. Amazon RDS
C. Amazon Redshift D. Amazon ElastiCache

2. An e-commerce company needs its relational database to keep running with automatic failover if an Availability Zone becomes unavailable. Which feature should it enable?

A. Read replicas in the same AZ B. Multi-AZ deployment
C. DynamoDB Accelerator D. Manual snapshots

3. A news website’s RDS PostgreSQL database is overloaded by read queries from article pages, while writes are light. What is the most appropriate way to improve performance?

A. Enable Multi-AZ B. Increase the backup retention period
C. Add read replicas and direct read traffic to them D. Move the database to Amazon Neptune

4. Which AWS database service is a serverless key-value and document database that provides single-digit-millisecond performance at any scale?

A. Amazon Aurora B. Amazon DocumentDB
C. Amazon DynamoDB D. Amazon Keyspaces

5. A gaming company uses DynamoDB and needs microsecond read latency for its leaderboards with minimal application changes. Which service should it add?

A. Amazon ElastiCache for Memcached B. DynamoDB Accelerator (DAX)
C. Amazon MemoryDB D. Amazon RDS read replicas

6. A financial analyst team needs to run complex SQL queries across five years of sales data totaling several petabytes. Which service is designed for this?

A. Amazon RDS for SQL Server B. Amazon DynamoDB
C. Amazon Redshift D. Amazon ElastiCache

7. A social media start-up wants to store users and the relationships between them to quickly answer “friends of friends” queries. Which database fits best?

A. Amazon Neptune B. Amazon Timestream
C. Amazon Redshift D. Amazon Keyspaces

8. A company has an application built on MongoDB and wants a managed AWS service without rewriting code. Which service should it choose?

A. Amazon DynamoDB B. Amazon DocumentDB
C. Amazon Aurora D. Amazon Neptune

9. Which statements about Amazon Aurora are correct? (Choose two.)

A. It is compatible with MySQL and PostgreSQL. B. It is a NoSQL key-value database.
C. It stores six copies of data across three Availability Zones. D. It must be installed and patched by the customer on EC2.
E. It supports only a single Availability Zone.

10. A start-up is launching a new relational application and cannot predict traffic, which may be near zero at night and spike during promotions. It wants to pay only for the database capacity it uses. What should it choose?

A. RDS for MySQL on a large instance class B. Aurora Serverless v2
C. Amazon Redshift provisioned cluster D. A database on EC2 Reserved Instances

11. A company needs a cache in front of its Amazon RDS database to reduce load and speed up frequent queries. Which service should it use?

A. Amazon ElastiCache B. DynamoDB Accelerator (DAX)
C. Amazon Timestream D. AWS DMS

12. A manufacturer collects temperature and vibration readings from thousands of sensors every few seconds and wants to analyze trends over time. Which purpose-built database type is the best fit?

A. Graph B. Ledger
C. Time series D. Document

13. A company wants to migrate its on-premises Oracle database to Aurora PostgreSQL with minimal downtime. Which combination should it use? (Choose two.)

A. AWS Database Migration Service B. Amazon Redshift Spectrum
C. AWS Schema Conversion Tool or DMS Schema

Conversion

D. DynamoDB global tables
E. Amazon ElastiCache

14. A global retail app needs users in Europe, North America, and Asia to read and write data locally with low latency in a NoSQL key-value database. Which feature meets this need?

A. RDS read replicas B. DynamoDB global tables
C. Aurora Multi-AZ D. ElastiCache Serverless

15. Under the shared responsibility model, which task remains the customer’s responsibility when using Amazon RDS?

A. Patching the database engine B. Replacing failed storage hardware
C. Managing database users and who can access the data D. Maintaining the physical data center

16. A company currently runs Apache Cassandra on premises and wants a serverless, managed service that works with its existing CQL code. Which service should it use?

A. Amazon Keyspaces B. Amazon DocumentDB
C. Amazon Neptune D. Amazon MemoryDB

17. A team accidentally deleted important rows from an RDS table at 10:42 this morning. Automated backups are enabled with 7-day retention. What is the best way to recover?

A. Promote a read replica B. Fail over to the Multi-AZ standby
C. Perform a point-in-time restore to 10:41 into a new DB

instance

D. Contact AWS Support to undo the change

18. A company needs a Redis-compatible database that delivers microsecond reads and also durably stores data as its primary system of record across multiple AZs. Which service fits?

A. ElastiCache for Memcached B. Amazon MemoryDB
C. DynamoDB Accelerator (DAX) D. Amazon Redshift

Answers and explanations

1. B. Amazon RDS is a managed relational service that supports MySQL and automates patching and backups. DynamoDB is NoSQL and would need an application rewrite; Redshift is a data warehouse; ElastiCache is a cache.
2. B. Multi-AZ keeps a synchronous standby in another AZ and fails over automatically. Read replicas in the same AZ do not protect against an AZ outage and are not automatic failover targets; snapshots require a manual restore.
3. C. Read replicas offload read traffic from the primary. Multi-AZ improves availability, not read performance, and Neptune is a graph database unsuited to this workload.
4. C. DynamoDB is the serverless key-value and document database with single-digit-millisecond latency. Aurora is relational, DocumentDB is MongoDB-compatible documents on clusters, and Keyspaces is Cassandra-compatible.
5. B. DAX is an in-memory cache built for DynamoDB that delivers microsecond reads with minimal code changes. ElastiCache could work but requires more application changes; MemoryDB and RDS replicas do not cache DynamoDB.
6. C. Redshift is a petabyte-scale data warehouse built for complex analytical SQL. RDS is optimized for transactional workloads, and DynamoDB and ElastiCache are not analytics engines.
7. A. Neptune is a graph database designed to query relationships such as friends of friends. Timestream is for time series, Redshift for analytics, and Keyspaces for Cassandra workloads.
8. B. DocumentDB is compatible with MongoDB APIs and drivers. DynamoDB is a different API and would require code changes; Aurora is relational and Neptune is graph.
9. A, C. Aurora is MySQL- and PostgreSQL-compatible and keeps six copies of data across three AZs. It is relational, fully managed by AWS, and designed for multi-AZ durability.
10. B. Aurora Serverless v2 scales capacity automatically and charges for capacity used, which suits unpredictable relational workloads. A large fixed instance or Reserved Instances wastes money during quiet periods, and Redshift is for analytics.
11. A. ElastiCache is a managed in-memory cache commonly placed in front of RDS. DAX works only with DynamoDB; Timestream and DMS are unrelated to caching.
12. C. Time-series databases such as Amazon Timestream are designed for time-stamped measurements. Graph, ledger, and document models do not specialize in time-ordered data.
13. A, C. A heterogeneous migration needs schema conversion (AWS SCT or DMS Schema Conversion) and DMS to move the data with minimal downtime using change data capture. The other options do not perform migrations.
14. B. DynamoDB global tables replicate a table across Regions with local reads and writes in each. RDS read replicas are read-only, Aurora Multi-AZ stays in one Region, and ElastiCache is a cache.
15. C. With RDS, customers manage their data, database users, permissions, and network access rules. AWS patches the engine (in your maintenance window) and handles hardware and facilities.
16. A. Amazon Keyspaces is serverless and compatible with Apache Cassandra and CQL. DocumentDB is MongoDB-compatible, Neptune is graph, and MemoryDB is Redis-compatible.
17. C. Point-in-time restore uses automated backups to restore to a moment before the mistake, creating a new instance. A replica or Multi-AZ standby would already contain the deletion, and AWS Support cannot undo customer data changes.
18. B. MemoryDB is a durable, Redis- and Valkey-compatible in-memory primary database with a multi-AZ transaction log. ElastiCache and DAX are caches, and Redshift is a data warehouse.