Amazon CLF-C02: Core Database Services — Study Guide

By Laurynas Brazys · 28 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

Part of the AWS Cloud Practitioner CLF-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

Managed relational databases: Amazon RDS and Amazon Aurora

Amazon RDS provides fully managed relational engines (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle) with automated backups, Multi‑AZ for high availability, read replicas for scaling, and snapshot-based restore. Aurora is a purpose-built, MySQL- and PostgreSQL-compatible engine that separates compute from a distributed, fault-tolerant storage layer to deliver higher throughput, fast crash recovery, and features like backtrack and Global Database for cross-region replication. Pricing models include On-Demand instances for flexible capacity, Reserved Instances or Savings Plans for predictable savings, and serverless or autoscaling capacity models for Aurora Serverless to align cost with variable workloads. Key architecture decisions hinge on read/write profile, latency requirements, and operational tolerance: choose RDS when compatibility and licensing needs dominate, and Aurora when you need higher performance, storage autoscaling, or global reads. Common practitioner traps are under-provisioning IOPS for high-write workloads, forgetting to enable Multi‑AZ for production, retaining default master credentials, and not testing point-in-time recovery. For compliance, enable encryption at rest using AWS KMS, enforce TLS for in-transit encryption, and validate that automated backups and snapshots meet retention and cross-region DR goals.

NoSQL, caching, and graph databases: DynamoDB, ElastiCache, Amazon Neptune

For key-value and document workloads at massive scale, Amazon DynamoDB offers single-digit millisecond latency, automatic partitioning, and two capacity modes: provisioned (with autoscaling) and on-demand for unpredictable traffic. Features like DynamoDB Streams, global tables, and point-in-time recovery (PITR) support replication, change data capture, and backups. A common pitfall is poor partition key design that creates hot partitions and throttling; model data access patterns first. For low-latency in-memory workloads use ElastiCache: Redis offers persistence, clustering, and pub/sub, while Memcached is simple, multi-threaded caching. Use DAX for read-heavy DynamoDB workloads requiring microsecond caching. For relationship-centric graph queries, Amazon Neptune is a fully managed graph database supporting Gremlin and SPARQL. Pricing decisions: DynamoDB on-demand is easy but more expensive at steady high traffic; provisioned with autoscaling and Reserved Capacity can be much cheaper. Cache sizing, eviction policies, and persistence choices in ElastiCache affect cost and recovery. Evaluate durability, consistency models, and operational complexity when choosing between managed NoSQL, in-memory caches, and graph databases.

DynamoDB vs RDS/Aurora: DynamoDB for massive scale, schema-flexible, single-table design; RDS/Aurora for complex SQL queries, transactions, and relational integrity.
ElastiCache (Redis) vs DAX: Redis for general-purpose in-memory workloads and persistence; DAX is a DynamoDB-specific read cache with client-side integration.
Neptune: Use when traversals and graph analytics are core to the application.

Analytics and data lake patterns: Amazon Redshift, Athena, and S3 storage choices

Amazon Redshift is a columnar, petabyte-scale data warehouse optimized for complex analytic queries and high concurrency. Modern Redshift (RA3 nodes) decouples compute and managed storage, letting you scale compute independently and reduce cost by leveraging S3 as managed storage; Redshift Spectrum queries data in S3 directly for data lake integration. For ad-hoc SQL over files, Amazon Athena provides serverless, pay-per-query analytics (billed per TB scanned) and is ideal for CSV/Parquet/JSON on S3; optimizing formats and compression drastically reduces cost. S3 offers multiple storage classes: for unknown access patterns, S3 Intelligent‑Tiering automatically moves objects between access tiers to minimize cost without retrieval fees; for long‑term archives consider S3 Glacier or Glacier Deep Archive where retrieval latency and fees apply. Cost trade-offs include storage vs compute: compress, partition, and use columnar formats to reduce scan volumes; consider Redshift concurrency scaling and workload management for predictable performance. For machine learning workloads tied to analytics, heavy training may require GPU EC2 families (P or G series), but most analytic DB workloads rely on optimized CPU and columnar execution rather than GPUs.

Migration, backup, security, and operational best practices

Migrating and protecting databases requires the right mix of services and policies. AWS Database Migration Service (DMS) handles homogeneous and heterogeneous migrations with minimal downtime; the Schema Conversion Tool helps convert database schemas when moving between engine types. For backups and policy-based protection, use native engine features (RDS automated backups and snapshots, DynamoDB PITR) alongside AWS Backup for centralized, cross-service backup policies and cross-account or cross-region copies. Security must include least-privilege IAM policies, encryption in transit (TLS) and at rest (KMS), and network controls: security groups are stateful host-level firewalls that you attach to instances, while network ACLs are stateless subnet-level filters — both are complementary but different in behavior. Under shared responsibility, AWS manages the cloud infrastructure, while customers manage data, IAM, OS-level patches on self-managed instances, and key rotation for secrets and access credentials. Operational automation using CloudFormation, the AWS CLI, or SDKs enables repeatable environment provisioning; common traps are relying on the root account, leaving broad IAM policies in place, neglecting key rotation, and failing to monitor using CloudWatch, VPC Flow Logs, or AWS Config. For large data transfers, consider AWS Snowball or DataSync to move terabytes/petabytes securely with encryption in transit and integrity validation.

Practical Problem: Use-Case Scenario

Scenario: AcmeRetail runs a seasonal ecommerce platform with an on-premises MySQL OLTP database and large historical CSV sales files in an on-prem NFS share. Their AWS account has a VPC with private subnets and a Transit Gateway to their data center. They need to migrate the transactional database with minimal downtime and make historical data queryable for BI.

Challenge: Move the production database with near-zero downtime, enable scalable analytics on historical CSVs, and ensure backups, encryption, and least-privilege access.

Recommended Approach:

Use AWS Database Migration Service (DMS) with the Schema Conversion Tool if needed to migrate MySQL to Amazon Aurora (MySQL-compatible), configuring continuous replication to minimize downtime.
Transfer historical CSVs to Amazon S3 using AWS DataSync or Snowball (for very large volumes), store them in S3 using Intelligent‑Tiering, and convert to Parquet with AWS Glue ETL for query efficiency.
Provision Amazon Redshift (RA3) or use Amazon Athena over the S3 data (Parquet) for BI queries; use Redshift Spectrum if combining warehouse and lake queries.
Implement automated backups (RDS automated backups and snapshots), enable encryption with KMS keys, restrict access with least-privilege IAM roles and security groups, and centralize backup policies with AWS Backup.

Rationale: Continuous DMS replication enables near-zero downtime migration for transactional systems; S3 + Parquet + Athena/Redshift minimizes analytic cost and scan sizes; KMS, backups, and least-privilege IAM align with shared-responsibility and operational best practices for availability, security, and cost control.

← Core Storage Services · All domains · Networking →

Practice these questions → · Timed practice on ExamRoll.io →