Databases sit inside the single largest domain on the AWS Certified Cloud Practitioner (CLF-C02) exam — Cloud Technology and Services, weighted at 34% of your score. The exam will not ask you to design a schema or tune a query. It asks recognition questions: “A team needs a managed relational database — which service?” or “Which AWS service is a fully managed NoSQL key-value database with single-digit millisecond performance?” Your job is to name the right service for a described need, and to know which category each service belongs to.
This guide is a structured tour of the AWS databases the CLF-C02 expects you to recognise, written at exactly that altitude. For each service you get a plain-English explanation, what problem it solves, and the words in a question that point to it. If you want the wider services picture first, the Core AWS Services guide for the Cloud Practitioner tours compute, storage, networking and databases together; this article carves out the database category and goes deeper. For the full blueprint and logistics, start with the AWS Cloud Practitioner exam guide for 2026 and the domains breakdown.
The Managed-Database Mental Model
Before the individual services, internalise the one idea the whole domain rests on: AWS database services are managed services. When you run a database yourself on an EC2 instance, you patch the operating system, install and upgrade the database engine, configure backups, handle failover, and scale the hardware. When you use a managed database like Amazon RDS, AWS does the undifferentiated heavy lifting — patching, backups, failover, and the underlying hardware — and you focus on your data and your queries.
This is the shared responsibility model in action, and the exam loves to test it. The more managed the service, the more AWS handles and the less you do.
Signal words: “fully managed”, “no servers to manage”, “reduce operational overhead”, “AWS handles patching and backups” → the answer is a managed AWS database service, not “install a database on EC2.”
Relational vs Non-Relational: The First Fork
Almost every database question starts by sorting into one of two families.
Relational (SQL) databases store data in tables with rows and columns, enforce a fixed schema, and support joins and transactions. They are the classic choice for structured data with clear relationships — orders, customers, inventory. On AWS this means Amazon RDS and Amazon Aurora.
Non-relational (NoSQL) databases store data in flexible formats — key-value pairs, documents, graphs — without a rigid schema, and scale horizontally to enormous request volumes. They shine when the access pattern is simple and predictable but the scale is huge. On AWS the flagship is Amazon DynamoDB.
| Question hint | Family | Likely service |
|---|---|---|
| ”structured data”, “tables and joins”, “SQL”, “relational” | Relational | RDS or Aurora |
| ”flexible schema”, “key-value”, “NoSQL”, “massive scale”, “single-digit millisecond” | Non-relational | DynamoDB |
| ”data warehouse”, “analytics”, “run complex queries on huge datasets” | Analytics (OLAP) | Redshift |
| ”in-memory”, “cache”, “microsecond latency”, “speed up reads” | Caching | ElastiCache |
Get this fork right and half the database questions answer themselves.
Amazon RDS: Managed Relational Databases
Amazon Relational Database Service (RDS) is a managed service for running standard relational database engines without operating the servers yourself. RDS supports the engines you already know:
- MySQL
- PostgreSQL
- MariaDB
- Oracle
- Microsoft SQL Server
RDS handles provisioning, OS and database patching, automated backups, snapshots, and point-in-time recovery. Two features come up often enough that a Cloud Practitioner should recognise them:
- Multi-AZ deployment is about high availability. RDS keeps a synchronous standby copy in a second Availability Zone and fails over to it automatically if the primary has a problem. The keyword is availability / disaster recovery, not performance.
- Read replicas are about read scaling and performance. They are asynchronous copies you can send read traffic to, taking load off the primary. The keyword is scale reads / offload reporting queries.
You do not need to configure either on the exam — you need to know which one solves availability (Multi-AZ) and which one solves read performance (read replicas).
Signal words: “managed MySQL/PostgreSQL/Oracle/SQL Server”, “lift-and-shift an existing relational database”, “automated backups and patching for a SQL database” → Amazon RDS.
Amazon Aurora: AWS’s Cloud-Native Relational Engine
Amazon Aurora is AWS’s own relational database engine, compatible with MySQL and PostgreSQL. It runs in RDS but is built for the cloud from the ground up, delivering higher performance and throughput than the standard engines while remaining drop-in compatible with existing MySQL/PostgreSQL applications. Its storage grows automatically and it keeps multiple copies of your data across Availability Zones for durability.
For the CLF-C02 you should recognise two things about Aurora:
- It is MySQL- and PostgreSQL-compatible, so applications written for those engines can move to it with little or no change.
- Aurora Serverless automatically starts, scales, and stops capacity based on demand — a fit for workloads that are intermittent or unpredictable, where you would rather not size a server in advance.
Signal words: “MySQL/PostgreSQL-compatible but higher performance”, “AWS-built relational database”, “cloud-native relational engine”, “auto-scaling relational database” → Amazon Aurora.
Amazon DynamoDB: Managed NoSQL at Any Scale
Amazon DynamoDB is a fully managed NoSQL key-value and document database. It is serverless — there is no instance to choose or manage — and it delivers single-digit millisecond performance at virtually any scale, which is why it powers shopping carts, gaming leaderboards, session stores, and IoT ingestion.
The recognition points that matter for the exam:
- It is NoSQL, not relational — flexible schema, no joins.
- It is fully managed and serverless — no servers, automatic scaling.
- It offers single-digit millisecond latency at high request volumes.
- DynamoDB Accelerator (DAX) is an in-memory cache for DynamoDB that pushes read latency to microseconds — worth recognising by name.
Signal words: “NoSQL”, “key-value”, “serverless database”, “single-digit millisecond”, “massive scale with a simple access pattern” → Amazon DynamoDB.
Amazon Redshift: The Data Warehouse
Amazon Redshift is a fully managed data warehouse built for analytics — running complex queries and aggregations across very large volumes of structured data. This is the OLAP (online analytical processing) side of the house, as opposed to the OLTP (online transaction processing) work that RDS, Aurora, and DynamoDB handle.
The distinction the exam tests:
| Workload | Meaning | Service family |
|---|---|---|
| OLTP | Many small, fast reads/writes (place an order, update a profile) | RDS, Aurora, DynamoDB |
| OLAP | Fewer, very large analytical queries (quarterly sales trends across billions of rows) | Redshift |
If a scenario says “business intelligence”, “data warehouse”, “analyze petabytes”, or “reporting and analytics across large datasets”, the answer is Redshift.
Signal words: “data warehouse”, “analytics”, “business intelligence”, “complex queries on large datasets”, “OLAP” → Amazon Redshift.
Amazon ElastiCache: In-Memory Caching
Amazon ElastiCache is a managed in-memory data store and cache, supporting the Redis and Memcached engines. It is not a primary system of record; it sits in front of a database to serve frequently accessed data from memory, cutting read latency to microseconds and taking load off the backend database.
Recognise ElastiCache when a scenario is about speeding up an existing database, caching session data, or reducing repeated reads — not about storing the authoritative copy of the data.
Signal words: “in-memory”, “cache”, “microsecond latency”, “reduce database load”, “speed up read-heavy applications” → Amazon ElastiCache.
The Purpose-Built Databases (Recognition Only)
AWS offers a database for almost every data shape. The CLF-C02 expects you to recognise these by their category — you will not be asked to operate them. Learn the one-line mapping:
| Service | Type | Use it for |
|---|---|---|
| Amazon DocumentDB | Document (MongoDB-compatible) | JSON document workloads |
| Amazon Neptune | Graph | Highly connected data — social networks, fraud graphs, recommendations |
| Amazon Keyspaces | Wide-column (Cassandra-compatible) | Apache Cassandra workloads, managed |
| Amazon MemoryDB | In-memory, durable (Redis-compatible) | Ultra-fast primary database with durability |
| Amazon Timestream | Time series | IoT and operational metrics over time |
| Amazon QLDB | Ledger | Immutable, cryptographically verifiable transaction history |
The pattern to remember: AWS provides a purpose-built database for each data model, rather than forcing every workload into one relational engine. If a question names a data shape (graph, document, time series, ledger), match it to the service above.
Migrating Databases: AWS DMS
Rounding out the domain, the AWS Database Migration Service (DMS) helps you migrate databases to AWS with minimal downtime — the source database stays operational during the migration. DMS handles like-to-like migrations (Oracle to Oracle) and, paired with the AWS Schema Conversion Tool (SCT), heterogeneous migrations that change engines (Oracle to Aurora PostgreSQL, for example).
Signal words: “migrate a database to AWS”, “minimal downtime migration”, “move an on-premises database to the cloud” → AWS DMS (with SCT if the engine changes).
The When-to-Use Decision Table
This single table answers the majority of CLF-C02 database questions. Read a scenario, find the row, pick the service.
| The scenario needs… | Choose | Category |
|---|---|---|
| A managed MySQL, PostgreSQL, Oracle, or SQL Server database | Amazon RDS | Relational (OLTP) |
| A high-performance, MySQL/PostgreSQL-compatible cloud database | Amazon Aurora | Relational (OLTP) |
| A serverless NoSQL key-value store at massive scale | Amazon DynamoDB | Non-relational (OLTP) |
| A data warehouse for analytics and BI | Amazon Redshift | Analytics (OLAP) |
| An in-memory cache to speed up reads | Amazon ElastiCache | Caching |
| A managed MongoDB-compatible document database | Amazon DocumentDB | Document |
| A graph database for connected data | Amazon Neptune | Graph |
| To migrate a database to AWS | AWS DMS | Migration |
How the CLF-C02 Frames Database Questions
Cloud Practitioner database questions almost always take one of three shapes:
- Match the need to the service. “A company wants a managed relational database and does not want to manage servers.” → RDS. These are pure recognition — get the category right and the service follows.
- Distinguish two similar services. RDS vs DynamoDB (relational vs NoSQL), RDS vs Redshift (transactions vs analytics), or Multi-AZ vs read replicas (availability vs read scaling). The trap is a plausible-but-wrong sibling; the fix is knowing the one keyword that separates them.
- Identify the managed-service benefit. “Which is a benefit of using RDS over running a database on EC2?” → reduced operational overhead: AWS handles patching, backups, and failover.
The way to make these reflexive is not to re-read the list — it is to answer scenario questions until the signal words trigger the right service automatically. That is exactly the practice the Sailor.sh Cloud Practitioner mock exam bundle is built for: scenario-driven questions that mirror the exam’s phrasing, with explanations that reinforce why the right service wins and why each distractor loses. Pair it with the free Cloud Practitioner practice questions to check your recognition speed before exam day.
A Focused Study Sequence
If databases are your weak spot, work them in this order:
- Lock the relational-vs-NoSQL fork. Everything branches from it.
- Learn RDS’s five engines and the Multi-AZ (availability) vs read-replica (read scaling) split.
- Memorise DynamoDB’s four recognition points (NoSQL, serverless, single-digit ms, massive scale).
- Separate OLTP from OLAP so Redshift never gets confused with RDS.
- Skim the purpose-built table for one-line recognition of Neptune, DocumentDB, Timestream, QLDB, Keyspaces, MemoryDB.
- Add ElastiCache and DMS as the caching and migration answers.
Slot this into the broader plan in the AWS Cloud Practitioner study plan, and revisit the core services, storage, and compute categories so the whole 34% domain hangs together.
Going Deeper Later
The CLF-C02 stays at the recognition level, and this guide matches it. When you move on to associate-level certifications, the same services come back with real architectural depth — Multi-AZ failover mechanics, DynamoDB capacity modes, Aurora replicas, and cross-service trade-offs. If you are curious what that looks like, the RDS, Aurora, and DynamoDB deep dive for the Solutions Architect Associate (SAA-C03) picks up exactly where the Cloud Practitioner leaves off. For now, keep your focus on naming the right service for the described need — that is what earns points on the CLF-C02.
Frequently Asked Questions
What is the difference between Amazon RDS and Amazon DynamoDB?
RDS is a managed relational (SQL) database service for engines like MySQL and PostgreSQL, with tables, a fixed schema, and joins. DynamoDB is a fully managed NoSQL key-value database that is serverless and delivers single-digit millisecond performance at massive scale. Choose RDS for structured, relational data; choose DynamoDB for high-scale workloads with a simple, predictable access pattern.
When should I use Amazon Aurora instead of RDS?
Use Aurora when you want a MySQL- or PostgreSQL-compatible database with higher performance and cloud-native durability than the standard RDS engines, or when Aurora Serverless’s automatic scaling fits an intermittent or unpredictable workload. Aurora is a database engine within RDS, so it keeps the managed benefits while adding AWS-built performance.
What is Amazon Redshift used for?
Redshift is a fully managed data warehouse for analytics and business intelligence — running complex queries across very large volumes of structured data. It handles OLAP (analytical) workloads, in contrast to the OLTP (transactional) workloads that RDS, Aurora, and DynamoDB serve.
Is Amazon ElastiCache a database?
ElastiCache is an in-memory cache (Redis or Memcached), not a primary system of record. It sits in front of a database to serve frequently accessed data from memory, reducing read latency and offloading the backend. The authoritative copy of your data still lives in a database like RDS or DynamoDB.
Do I need hands-on database skills for the Cloud Practitioner exam?
No. The CLF-C02 tests recognition and when-to-use judgment, not configuration. You should be able to name the right database service for a scenario and explain the benefits of a managed service, but you will not write queries or provision instances.
What does AWS DMS do?
The AWS Database Migration Service migrates databases to AWS with minimal downtime, keeping the source running during the move. For migrations that change the database engine (a heterogeneous migration), you pair it with the AWS Schema Conversion Tool (SCT).
Conclusion
AWS database questions on the CLF-C02 reward one skill above all: matching a described need to the right managed service. Sort the scenario into relational, non-relational, analytics, or caching; recognise RDS and Aurora for SQL, DynamoDB for NoSQL, Redshift for the warehouse, and ElastiCache for the cache; and keep the purpose-built databases and DMS in reserve for the questions that name a specific data shape or a migration. Drill those signal words with realistic scenario questions until the right service surfaces before you finish reading the prompt — and the entire database slice of the 34% domain becomes free points.