Data Store Management

An order written once and read back by its ID is online transaction processing (OLTP); a query that scans a quarter of sales to total revenue by region is online analytical processing (OLAP). That single distinction, point lookups and small high-concurrency writes versus large aggregate scans over columns, sorts almost every store before data shape ever enters the picture: OLTP points at Amazon RDS, Aurora, or DynamoDB, OLAP at Amazon Redshift or query-in-place over an Amazon S3 data lake. At 26% of the exam, this is the second-largest domain after Data Ingestion and Transformation (34%), and the access-pattern lens is the model that ties its four parts together. Cataloging, lifecycle, and schema design are not separate disciplines; each one is the same question asked again, how will this data be read, applied to metadata, to cost over time, and to physical layout. The classic trap is letting service familiarity decide: a scenario that describes high-concurrency key lookups is answered by DynamoDB even when the candidate knows relational databases better.

First, Data Store Selection picks the engine from the access pattern and data shape: relational, key-value, columnar warehouse, lake, in-memory, graph, document, or vector. Second, Data Cataloging records what that data is so engines can find it: the AWS Glue Data Catalog is the shared Hive-compatible metastore that Athena, Amazon EMR, and Redshift Spectrum all read, with crawlers and Athena partition projection keeping partitions current, and SageMaker Catalog (the business catalog, formerly Amazon DataZone) layered on top for people. Third, Data Lifecycle Management controls cost and durability over time: S3 storage classes and Lifecycle rules walk the cost ladder automatically, DynamoDB TTL expires cold rows for free, and Redshift COPY and UNLOAD move data in bulk between lake and warehouse. Fourth, Data Modeling and Schema Evolution shapes the physical layout to the read path (Redshift distribution and sort keys, DynamoDB composite keys and indexes, lake partitioning) and keeps it changeable as requirements move, with Apache Iceberg turning schema and partition changes into metadata operations.

The exam consistently rewards matching the data's natural shape to the store designed for it rather than forcing everything into one familiar engine: graph relationships go to Amazon Neptune, embeddings to a vector index, wide-column to Amazon Keyspaces, and high-concurrency key access to DynamoDB, even when a relational database could be bent to the task. The same instinct favors the S3 data lake as the cheap, schema-on-read default for storing everything, then adds a warehouse or an open table format only where curated performance or correctness demands it. Apache Iceberg on S3 (managed as Amazon S3 Tables) is the default when many engines must read and write the same lake tables with ACID transactions and row-level updates, because it buys the warehouse's correctness at the lake's cost without locking you into one engine.