Study guide
Purpose-Built Database Selection
AWS Certified Solutions Architect - Professional SAP-C02
Track your progress as you read
Finished sections get a check mark.
1 Introduction and SAP-C02 Exam Facts
Current SAP-C02 Exam Facts Exam Format, Scoring, and Retakes Candidate Profile and Four Exam Domains
2 Multi-Account Governance
Multi-Account Strategy, Account Topologies, and OU Hierarchies Service Control Policies, Inheritance, and Permission Guardrails Control Tower, Landing Zones, Central Logging, and Resource Sharing
3 Hybrid and Inter-VPC Connectivity
Transit Gateway, VPC Connectivity, and PrivateLink Direct Connect, VPN, and Hybrid Redundancy Hybrid DNS with Route 53 Resolver Segmentation, Traffic Monitoring, and Service Endpoints
4 Identity Federation and Cross-Account Access
IAM Identity Center, External IdPs, and Workforce Federation Cross-Account Roles, STS, and Resource Policies Permissions Boundaries, Delegated Administration, and Least Privilege at Scale
5 Data Protection, Encryption, and Compliance
KMS, Multi-Region Keys, Envelope Encryption, and Certificates Encryption in Transit, Security Groups, NACLs, and VPC Endpoints Centralized Audit, Security Hub, GuardDuty, Inspector, and Access Analyzer
6 Deployment, Compute, Containers, and Serverless
Infrastructure as Code, CI/CD, Change Management, and Rollback EC2 Families, Auto Scaling, and Managed Compute ECS, EKS, Fargate, and ECR at Enterprise Scale Lambda, Step Functions, API Gateway, and Configuration Management
7 Storage, Caching, and Edge Performance
S3 Storage Classes, Object Lock, Replication, and Access Paths EBS, EFS, FSx Family, and Storage Gateway CloudFront Behaviors, Origin Access, Edge Compute, and Global Accelerator ElastiCache, MemoryDB, DAX, and Buffering versus Cache versus Replicas
8 Purpose-Built and Global Databases
Aurora Storage, Replicas, and Global Database DynamoDB Keys, Global Tables, and DAX Purpose-Built Database Selection
9 Integration, Messaging, and Streaming
API Gateway Architectures Decoupled Messaging with Amazon SQS and Amazon SNS Event-Driven Design with Amazon EventBridge Streaming Analytics with Amazon Kinesis and Amazon MSK
10 Resilience and Disaster Recovery
Disaster Recovery Patterns Route 53 Routing and Application Recovery Controller Backup, Replication, and Service Quotas High Availability, Failover, Chaos, and Self-Healing
11 Operational Excellence and Automation
CloudWatch Centralized Telemetry Distributed Tracing with AWS X-Ray Systems Manager Automation Deployment Strategies and Auto-Remediation
12 Cost Optimization and Visibility
Cost Explorer, Budgets, CUR, and Allocation Tags Savings Plans, Reserved Instances, Coverage, and Sharing Spot, Mixed Auto Scaling, Compute Optimizer, and Storage Lens Data Transfer Modeling: NAT, Endpoints, CloudFront, and Hybrid
13 Improve Security and Performance
Secrets, Least Privilege Audits, and Traceability Config Rules, Patching, Backup, and Regulatory Controls Performance Tuning for Existing Workloads
14 Migration Assessment and Wave Planning
Seven Migration Strategies (7 Rs) and Workload Selection Application Discovery, Migration Hub, and Migration Evaluator Wave Planning, Prioritization, and Assessment Governance
15 Migration Tools and Data Transfer
AWS Application Migration Service (MGN) AWS DMS, SCT, and Change Data Capture Large-Scale Data Transfer and Landing-Zone Prerequisites
16 Target Architecture, Modernization, and Cutover
Selecting Compute, Storage, and Database Platforms for Migrated Workloads Container Modernization: ECS, EKS, Fargate, ECR, and Strangler Fig Serverless, Decoupling, Purpose-Built Databases, and Integration Services Cutover, Rollback, and Unscored Emerging AI Topics
Purpose-Built Database Selection
Key Takeaways Explain This Topic AI
Select a database from the data model and access pattern: relational OLTP, key-value, document, graph, wide-column, time series, in-memory cache, search, or warehouse analytics—not from a single favorite engine.
Amazon RDS offers six managed engines (PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Db2); Aurora adds MySQL- and PostgreSQL-compatible cluster-volume HA when that compatibility is enough.
Amazon DocumentDB fits JSON document workloads, Amazon Neptune fits highly connected graphs such as fraud rings, Amazon Keyspaces fits Cassandra-compatible wide-column tables, and Amazon Timestream fits timestamped Internet of Things telemetry—though LiveAnalytics closed to new customers on 20 June 2025 and AWS points new customers to Timestream for InfluxDB.
Amazon Redshift is a columnar OLAP warehouse, Amazon ElastiCache is an ephemeral cache rather than a system of record, and Amazon OpenSearch Service is search and log analytics rather than a payment ledger.
Installing a database on Amazon EC2 is the wrong SAP-C02 default when a managed service matches the workload; rehosting leaves patching, backups, failover, and capacity on the customer.
Last updated: September 2026
Selection is the Professional skill
SAP-C02 Task 2.5 is less “name every database” and more choose the engine whose data model matches the access pattern . AWS’s June 2026 Choosing an AWS database service decision guide frames OLTP catalogs (relational and non-relational) separately from Amazon Redshift , which exists for online analytical processing (OLAP) . The AWS Well-Architected Framework performance pillar makes the same point: use a purpose-built data store rather than one monolithic database.
Independent SAP-C02 study material by ExamFinch uses that published methodology. It does not claim ExamFinch is an AWS partner or that this guide is an official blueprint substitute.
Work the stem in order:
Data model — rows and joins, key-value, JSON documents, graph edges, wide-column, time series, vectors, or logs.
Access — single-item lookup, range query, multi-hop traversal, full-text search, or warehouse aggregation.
Consistency and latency — ACID multi-row, single-digit milliseconds, microseconds, or eventually consistent analytics.
Residency and scale — one Region Multi-AZ, active-active Regions, or petabyte scans.
Operations — managed versus self-hosted, serverless versus provisioned.
Migration reality — re-platform to RDS, refactor to Aurora or DynamoDB, or (rarely) rehost on EC2.
Usually more than one database appears in a correct architecture. AWS’s own ecommerce example mixes DocumentDB (catalog), DynamoDB (browse latency), and Aurora (inventory and orders). Northwind Payments should look the same: several purpose-built stores, not one Oracle on EC2 “for simplicity.”
Relational OLTP: RDS engines versus Aurora
Amazon Relational Database Service (Amazon RDS) is the managed path when you need a conventional engine with automated backups, patching, and Multi-AZ deployments. RDS engines are PostgreSQL , MySQL , MariaDB , SQL Server , Oracle , and Db2 . Pick RDS when the stem requires Oracle , SQL Server , MariaDB , or Db2 , or when the team must stay on a specific RDS feature set.
Amazon Aurora (MySQL-compatible and PostgreSQL-compatible) is the usual upgrade when the workload is relational OLTP and those two compatibilities are enough. You gain the shared cluster volume, typically sub-minute failover with readers, and Global Database. Aurora is not a drop-in for Oracle PL/SQL or SQL Server T-SQL. If Northwind’s core settlement system is still Oracle-specific, RDS for Oracle (or a stated migration off Oracle) is the honest answer—not “put it on Aurora PostgreSQL” without a conversion story.
Newer catalog entries such as Amazon Aurora DSQL and Aurora PostgreSQL Limitless Database exist in the 2026 decision guide (distributed SQL and sharded PostgreSQL). SAP-C02 still uses a three-month generally available gate before new features appear as scored items. Treat them as current AWS options to confirm against that rule, not as a reason to ignore classic Aurora clusters on this exam series.
Document, graph, wide-column, time series
Amazon DocumentDB (with MongoDB compatibility) stores JSON-like documents with rich queries across fields. Northwind’s merchant catalog (nested hours, terminals, and fee schedules that differ by merchant) is a document problem. It is not a reason to shred JSON into hundreds of RDS tables unless the stem demands relational constraints.
Amazon Neptune is the graph database for networks of objects: social graphs, fraud detection , and recommendations. Northwind’s fraud team does not want to JOIN seven SQL tables to ask “which cards share devices with this merchant and then paid at a second high-risk merchant?” Neptune is optimized to traverse relationships with low latency. That is the graph-fraud scenario on this exam: edges and multi-hop patterns, not a warehouse star schema and not a DynamoDB single-key lookup.
Amazon Keyspaces (for Apache Cassandra) is wide-column and Cassandra-compatible. Use it to migrate Cassandra or for heavy read/write tables that need single-digit millisecond latency and linear scale. Do not pick Keyspaces because a stem said “wide table” if the workload is actually relational reporting.
Amazon Timestream is the time series service for Internet of Things (IoT) data, application metrics, and asset tracking. Northwind’s terminals emit temperature, connectivity, and decline-rate points every few seconds. That telemetry is timestamped, high ingest, and queried as trends—not as a row-level payment authorization. Keep authorizations on Aurora or DynamoDB; land the time-series IoT stream on Timestream. Read the availability change before you design: AWS closed new customer access to Amazon Timestream for LiveAnalytics effective 20 June 2025 and tells new customers to evaluate Amazon Timestream for InfluxDB instead, while existing customers with an active payer account continue as normal. Timestream is still on the SAP-C02 in-scope service list, so it remains the exam-correct time-series answer; in a 2026 greenfield design, name the Timestream engine the account can actually onboard. Forcing billions of sensor points into Aurora bloats the OLTP volume and still yields a poor time-series engine.
Workload Typical managed service Why not the usual wrong answer
Card ledger, settlement, inventory Aurora or RDS DynamoDB if you truly have key-value access; Redshift if you confused OLAP with OLTP
- Session or cart DynamoDB (Global Tables if multi-Region) ElastiCache as the only durable store
- JSON catalog / profiles DocumentDB Neptune (unless the catalog is actually a graph of relationships)
- Fraud rings, device sharing Neptune Relational self-joins or OpenSearch as the graph
- Cassandra migration / wide-column Keyspaces RDS because “it is a database”
- Terminal IoT metrics Timestream Aurora as a metrics archive
- Microsecond cache of hot keys ElastiCache (Valkey, Memcached, or Redis OSS) Using the cache as the ledger
- Durable in-memory primary MemoryDB ElastiCache when the stem required persistence
- Full-text, logs, clickstream, hybrid search OpenSearch Service Using OpenSearch as PCI system of record
- BI across years of payments Redshift RDS/Aurora as the enterprise warehouse
- Redshift is OLAP, not the authorization database
Amazon Redshift is a managed columnar warehouse with massively parallel processing. AWS states it is designed for OLAP and business intelligence: aggregations, scans, and joins on large historical sets. PostgreSQL-compatible SQL does not make it an OLTP engine. Redshift omits OLTP-oriented behaviors (for example, it does not rely on the same secondary-index and single-row DML profile as PostgreSQL) so analytic scans run well.
Northwind’s CFO dashboard that groups yearly interchange by country belongs on Redshift (often loaded from Aurora or S3). The authorization that must commit in milliseconds does not . A common pattern AWS describes: RDS or Aurora for the application, AWS Glue or AWS Database Migration Service to move data into Redshift. If a stem asks where to run the nightly rollup, Redshift. If it asks where to record the capture, Aurora or RDS.
ElastiCache is a cache, not a system of record
Amazon ElastiCache (Valkey, Memcached, Redis OSS; serverless or node-based) is an ephemeral in-memory cache for microsecond reads and sub-millisecond writes of frequently accessed data. The decision guide is explicit: use it to improve read performance , not to replace the database.
Northwind may cache merchant fee schedules or session tokens in ElastiCache in front of DynamoDB or Aurora. If a node is replaced or a cache is flushed, the system of record (SoR) must still have the data. If the stem requires persistence with sub-millisecond reads as a primary database, look at Amazon MemoryDB , not ElastiCache. The in-memory caching chapter of this guide goes deeper on engine choice; this section only locks the SoR versus cache boundary that Task 2.5 database selection depends on.
Trap: “put the ledger in Redis so it is fast.” Speed without durability and backup/restore semantics is not a payments architecture.
OpenSearch is search and analytics
Amazon OpenSearch Service deploys OpenSearch (or legacy Elasticsearch OSS up to 7.10) for log analytics , monitoring, clickstream , full-text search, and vector/k-NN retrieval. DynamoDB, DocumentDB, and other stores often stream or zero-ETL into OpenSearch. That does not make OpenSearch the cardholder data environment.
Northwind indexes authorization error logs and merchant-portal search in OpenSearch. Investigators still pull the signed ledger from Aurora. Mixing those roles is a distractor: “store settlements in OpenSearch so we can search them.”
Self-managed on EC2 is the wrong default
The decision guide’s rehost path is honest: install the engine on Amazon EC2 , migrate data, and keep operating the way you did on premises. You still own upgrades, patches, backups, capacity, performance, and availability . Re-platform to RDS, or refactor to Aurora, DynamoDB, Neptune, or DocumentDB, removes that undifferentiated work.
On SAP-C02, EC2 as the database host is justified when the stem forces it: an engine or extension RDS/Aurora do not offer, OS-level agents the compliance team will not move, or a short-term rehost with an explicit later modernization. “We always control the OS” is not a Professional default when Keyspaces, Timestream, Neptune, or RDS already match the data model.
Northwind should not run self-managed Cassandra on EC2 when Keyspaces exists, self-managed MongoDB when DocumentDB exists, or a single-AZ MySQL on EC2 when Aurora Multi-AZ exists—unless the item states a constraint those services cannot meet.
Putting the four scenarios in one company
Northwind’s map:
Global payments / ledger: Aurora (often Global Database) or RDS if the engine must be Oracle or SQL Server.
Session store: DynamoDB Global Tables, optional Regional DAX, ElastiCache only as a cache.
Graph fraud: Neptune for device-card-merchant rings; do not fake this with Redshift or a heroic SQL recursion.
Time-series IoT: Timestream for terminal telemetry; do not park it in the OLTP cluster.
Add DocumentDB if the catalog is document-shaped, Keyspaces if Cassandra is already the standard, OpenSearch for logs and search, Redshift for BI. That is purpose-built design. One EC2 database for all four is the answer you eliminate first.
- Selection traps
- Using Redshift for row-level authorizations because it “speaks SQL.”
Using ElastiCache as the only copy of session or payment data.
Using OpenSearch as the settlement system of record.
Using Aurora for multi-hop fraud graphs.
Using Neptune for time-series IoT.
Using Timestream for ACID settlement.
Defaulting to self-managed EC2 whenever the company already has DBAs.
Forcing every JSON payload into RDS third-normal-form when DocumentDB matches the queries.
Telling a brand-new AWS customer in 2026 to onboard Timestream for LiveAnalytics as if the 20 June 2025 availability change had not happened, instead of naming Timestream for InfluxDB.