Overview
Data Store Management has four task statements. Task 2.1 covers choosing a store for cost, performance and access pattern across Amazon Redshift, Amazon EMR, AWS Lake Formation, Amazon RDS, DynamoDB, Kinesis Data Streams and Amazon MSK, plus migration with AWS Transfer Family, Redshift federated queries and Spectrum, locking, Apache Iceberg tables and vector indexes such as HNSW and IVF. Task 2.2 covers technical and business catalogs: the AWS Glue Data Catalog, crawlers, partition synchronization, Glue connections and Amazon SageMaker Catalog.
Task 2.3 covers the data lifecycle: COPY and UNLOAD between Amazon S3 and Redshift, S3 Lifecycle transitions and expiration, versioning, DynamoDB TTL, legally required deletion and resiliency. Task 2.4 covers schema design, schema evolution, conversion with AWS DMS Schema Conversion, lineage, partitioning, compression and vectorization for Amazon Bedrock knowledge bases.
How it's tested
Domain 2 scenarios describe a workload's access pattern, query style, data volume, retention rule or schema change and ask for the store, catalog step, lifecycle rule or table design that fits. Answers often turn on one detail: key-value lookups at single-digit millisecond latency, ad hoc SQL over S3, a seven-year retention mandate, or a new column arriving in source files.
-
Match the store
An access pattern and latency or cost target are given, and you choose Redshift, DynamoDB, RDS, Aurora, MemoryDB or S3 with Athena.
-
Fix the catalog
Queries miss new data or schemas drift, and you pick a crawler schedule, partition projection, MSCK REPAIR TABLE or an explicit partition command.
-
Set the lifecycle
A retention, archive or deletion rule is described, and you configure S3 Lifecycle transitions, expiration, versioning or DynamoDB TTL.
A team keeps raw logs in S3 Standard. Logs are queried heavily for 30 days, rarely for a year, and must be deleted after seven years. An S3 Lifecycle policy that moves objects to S3 Standard-IA after 30 days, to S3 Glacier Deep Archive after 365 days, and expires them after 2,555 days meets every rule automatically. S3 Intelligent-Tiering would also cut cost but would never enforce the deletion requirement.
Task statements 4
Official task statements from the Amazon Web Services outline, in outline order.
2.1 Choose a data storeMatching stores to cost, performance and access patterns, plus migration, locks, Iceberg and vector indexes.
- What it means
- This task statement covers selecting and configuring storage for cost, performance and access patterns across Amazon Redshift, Amazon EMR, AWS Lake Formation, Amazon RDS, DynamoDB, Kinesis Data Streams and Amazon MSK; fitting stores to use cases such as HNSW indexing in Aurora PostgreSQL and Amazon MemoryDB for fast key-value access; migration with AWS Transfer Family; remote access through Redshift federated queries, materialized views and Redshift Spectrum; managing locks; Apache Iceberg tables; and vector index types.
- What to understand
- Redshift suits analytical SQL over large structured datasets; Spectrum queries S3 data without loading it, and federated queries reach live RDS or Aurora data. Materialized views store precomputed results for repeated dashboards. DynamoDB serves key-based lookups at any scale, while MemoryDB gives durable in-memory speed. Aurora PostgreSQL with pgvector supports HNSW indexes, which favor recall and query speed, while IVF indexes cluster vectors and build faster with less memory. Apache Iceberg adds ACID transactions, time travel and schema evolution to S3 tables. Transfer Family accepts SFTP uploads straight into S3.
- How it shows up
- A workload's query style, latency and budget are described, and you choose the store, index type or remote-access feature.
- Common confusion
- Loading S3 data into Redshift tables when Redshift Spectrum could query it in place for occasional access.
2.2 Understand data cataloging systemsGlue Data Catalog, crawlers, partitions, connections and business catalogs.
- What it means
- This task statement covers using catalogs to consume data from its source, building a technical catalog with the AWS Glue Data Catalog or an Apache Hive metastore, discovering schemas with AWS Glue crawlers, keeping partitions synchronized, creating Glue connections to sources and targets, and managing a business data catalog in Amazon SageMaker Catalog.
- What to understand
- The Glue Data Catalog stores table definitions that Athena, Redshift Spectrum, EMR and Glue jobs share. Crawlers infer schemas and add partitions but cost money each run, so scheduled or event-driven crawls are common. When new partitions land, Athena cannot see them until the catalog learns of them through a crawler, MSCK REPAIR TABLE, ALTER TABLE ADD PARTITION, or partition projection. Glue connections hold JDBC details for databases inside a VPC. SageMaker Catalog adds business glossaries, metadata forms and subscription workflows for data consumers.
- How it shows up
- Queries return missing or stale data, or a team needs discoverable datasets, and you pick the catalog action.
- Common confusion
- Expecting Athena to see new S3 partitions automatically without a crawler, repair command or partition projection.
2.3 Manage the lifecycle of dataRedshift loads and unloads, S3 Lifecycle, versioning, TTL, deletion and resiliency.
- What it means
- This task statement covers moving data between Amazon S3 and Amazon Redshift with load and unload operations, using S3 Lifecycle policies to change storage classes and expire objects, managing S3 versioning and DynamoDB Time to Live, deleting data to meet business and legal requirements, and protecting data with suitable resiliency and availability.
- What to understand
- COPY loads Redshift fastest when input is split into several similar-sized, compressed files, ideally a multiple of the slice count. UNLOAD writes query results to S3, optionally as Parquet. Lifecycle rules transition objects through Standard-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval and Glacier Deep Archive, and can expire current and noncurrent versions. DynamoDB TTL deletes expired items in the background without consuming write throughput. S3 Object Lock supports retention mandates, and cross-Region replication or Redshift snapshots support recovery.
- How it shows up
- A retention, archive, deletion or recovery need is described, and you pick the lifecycle rule, load method or protection feature.
- Common confusion
- Forgetting that versioned buckets keep noncurrent versions, so expiration rules must also target noncurrent objects.
2.4 Design data models and schema evolutionSchemas for Redshift, DynamoDB and Lake Formation, schema change, conversion, lineage and optimization.
- What it means
- This task statement covers designing schemas for Amazon Redshift, DynamoDB and Lake Formation tables, handling changes in data characteristics, converting schemas with AWS DMS Schema Conversion, establishing lineage with Amazon SageMaker ML Lineage Tracking and SageMaker Catalog, applying indexing, partitioning and compression best practices, and describing vectorization for an Amazon Bedrock knowledge base.
- What to understand
- Redshift performance depends on distribution style (AUTO, EVEN, KEY, ALL) and sort keys that match common filters and joins. DynamoDB design starts from access patterns: a high-cardinality partition key, a sort key for ranges, and global secondary indexes for other queries. Data lakes partition by columns used in filters, such as date, and avoid floods of tiny files. Schema evolution is easier with Parquet, Avro or Iceberg. DMS Schema Conversion translates engines such as Oracle to PostgreSQL. Vectorization chunks text and stores embeddings for retrieval.
- How it shows up
- A query pattern, schema change or migration is described, and you choose the key design, partition scheme or conversion tool.
- Common confusion
- Using a low-cardinality attribute such as order status as a DynamoDB partition key, which creates hot partitions.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Redshift Spectrum
Query S3 data from Redshift through external tables.
- Remember
- No loading needed.
- Tested as
- Remote access questions.
- Trap
- Loading cold data just to query it once a month.
-
Redshift federated query
Query live data in RDS or Aurora PostgreSQL and MySQL from Redshift.
- Remember
- Avoids copying operational data.
- Tested as
- Integration questions.
- Trap
- Confusing it with Spectrum, which reads S3.
-
Materialized views
Stored query results that refresh on demand or automatically.
- Remember
- Speeds repeated dashboard queries.
- Tested as
- Performance questions.
- Trap
- Expecting a regular view to read faster.
-
Distribution and sort keys
Control how Redshift spreads rows across nodes and orders them on disk.
- Remember
- KEY on the join column, ALL for small dimensions.
- Tested as
- Table design questions.
- Trap
- Using EVEN for two large tables joined constantly.
-
DynamoDB key design
Partition key spreads load; sort key enables range queries.
- Remember
- High cardinality avoids hot partitions.
- Tested as
- Schema questions.
- Trap
- Scanning the table instead of adding a GSI.
-
Glue crawlers
Infer schemas and register tables and partitions.
- Remember
- Schedule them or trigger them on events.
- Tested as
- Catalog questions.
- Trap
- Crawling unchanged data too often.
-
Partition projection
Athena computes partitions from table properties instead of catalog lookups.
- Remember
- Fits predictable, highly partitioned layouts.
- Tested as
- Partition sync questions.
- Trap
- Assuming a crawler is the only option.
-
S3 Lifecycle
Rules that move objects between storage classes and expire them.
- Remember
- Add separate rules for noncurrent versions.
- Tested as
- Retention questions.
- Trap
- Using Intelligent-Tiering to enforce deletion.
-
DynamoDB TTL
Per-item expiry timestamp that triggers background deletion.
- Remember
- Deletes do not consume write capacity.
- Tested as
- Lifecycle questions.
- Trap
- Writing a scheduled Lambda to delete old items.
-
Apache Iceberg
Open table format with ACID, time travel and schema evolution on S3.
- Remember
- Supports row-level updates and deletes in a lake.
- Tested as
- Open table format questions.
- Trap
- Rewriting whole partitions to change a few rows.
-
HNSW vs. IVF
Graph-based versus cluster-based vector indexes.
- Remember
- HNSW: higher recall, more memory; IVF: faster builds.
- Tested as
- Vector store questions.
- Trap
- Treating the two as interchangeable.
-
Redshift COPY and UNLOAD
Parallel bulk load from S3 and export to S3.
- Remember
- Split input files to match slices.
- Tested as
- Load questions.
- Trap
- Using single-row INSERT statements for bulk loads.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Analytical and operational stores
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Amazon Redshift | Columnar data warehouse | Complex SQL over large data | Using it for single-item lookups |
| Amazon DynamoDB | Serverless key-value and document store | Predictable key access at any scale | Expecting ad hoc joins |
| Amazon RDS / Aurora | Managed relational databases | Transactional workloads | Running heavy analytics on the primary |
| S3 with Athena | Serverless SQL over files | Pay per data scanned | Querying unpartitioned CSV |
| Amazon MemoryDB | Durable in-memory database | Microsecond reads | Choosing it for cheap archival |
Making new partitions visible
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Glue crawler | Scans S3 and updates the catalog | Also detects schema changes | Running it every few minutes |
| MSCK REPAIR TABLE | Athena command that loads Hive-style partitions | Manual or scripted | Slow on very many partitions |
| ALTER TABLE ADD PARTITION | Registers specific partitions | Precise, scriptable | Forgetting to call it after loads |
| Partition projection | Partitions calculated at query time | No catalog updates needed | Using it for unpredictable layouts |
Querying data outside Redshift tables
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Redshift Spectrum | External tables over S3 | Reads files in place | Pointing it at RDS |
| Federated query | Live reads from RDS and Aurora | Operational data, no copy | Pointing it at S3 files |
| Materialized view | Precomputed stored result | Fast repeated reads | Forgetting refresh requirements |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Load everything into Redshift
- What candidates pick
- COPY two years of archived logs into Redshift to run one quarterly report.
- Why it looks right
- Redshift is the warehouse.
- Why it's wrong
- Redshift Spectrum queries the S3 files in place, so cluster storage and load time are not spent on rarely used data.
Clue to watch for Infrequent queries over large data already in S3.
-
Crawler every few minutes
- What candidates pick
- Schedule a Glue crawler every five minutes so Athena sees new hourly partitions.
- Why it looks right
- Crawlers are the standard catalog tool.
- Why it's wrong
- Partition projection or an ADD PARTITION call registers predictable partitions without repeated crawler cost and delay.
Clue to watch for Partitions follow a known date pattern.
-
Intelligent-Tiering for deletion
- What candidates pick
- Enable S3 Intelligent-Tiering to meet a seven-year deletion rule.
- Why it looks right
- It manages storage automatically.
- Why it's wrong
- Intelligent-Tiering moves objects between access tiers but never deletes them; only an expiration rule enforces removal.
Clue to watch for A hard deletion deadline is stated.
-
Scheduled delete jobs
- What candidates pick
- Run a nightly Lambda that scans and deletes expired DynamoDB items.
- Why it looks right
- Gives full control over deletion.
- Why it's wrong
- DynamoDB TTL removes expired items automatically without consuming write capacity, so the scan and custom code are unnecessary.
Clue to watch for Items should disappear after a fixed age.
-
Federated query for files
- What candidates pick
- Use Redshift federated query to read Parquet files in S3.
- Why it looks right
- Both features reach data outside Redshift.
- Why it's wrong
- Federated query targets live RDS and Aurora databases; S3 files are queried through Spectrum external tables.
Clue to watch for The source is files in S3 rather than an operational database.
-
Rewriting partitions for small deletes
- What candidates pick
- Rewrite entire Parquet partitions to apply a few privacy deletion requests.
- Why it looks right
- Parquet files are immutable.
- Why it's wrong
- An Apache Iceberg table supports row-level deletes and updates with ACID guarantees, avoiding full partition rewrites.
Clue to watch for Frequent small updates or deletes in S3 data.
Answer framework
Use these steps when a Domain 2 question asks where data should be stored, how it is cataloged, or how long it is kept.
- Start from the access pattern: key lookups point to DynamoDB or MemoryDB, transactional SQL to RDS or Aurora, large analytical SQL to Redshift, and occasional queries over files to S3 with Athena.
- Check whether data can stay where it is through Redshift Spectrum, federated queries or materialized views before planning a migration.
- Make the data discoverable by registering tables and partitions in the Glue Data Catalog, choosing crawlers, partition projection or explicit partition commands.
- Apply lifecycle rules from the retention requirement, using S3 transitions and expiration, noncurrent version rules, DynamoDB TTL or Object Lock.
- Design keys and layout for the queries: Redshift distribution and sort keys, DynamoDB partition keys and indexes, and lake partitions with compressed columnar files.
Practice question
Want more like this? The DEA-C01 practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Build a decision table first. List each store in rows and score it on query style, latency, scale, cost model and typical exam keyword, for example key-value at any scale for DynamoDB or petabyte SQL analytics for Redshift. Add Aurora PostgreSQL with pgvector and MemoryDB, since the current guide names both.
Then work hands-on with the catalog. Upload partitioned Parquet to S3, crawl it, query it in Athena, add a new partition, and watch it stay invisible until you run MSCK REPAIR TABLE or switch to partition projection. Create an Iceberg table in Athena and run an UPDATE so you see the difference from plain Parquet.
Finish with lifecycle and modeling. Write a Lifecycle configuration in JSON with transitions and noncurrent version expiration, and set a TTL attribute on a DynamoDB table. Load a Redshift table with COPY from split, compressed files, try KEY and ALL distribution on a join, and check the query plan. When reviewing practice questions, underline the phrase that rules out the wrong stores: retention period, latency, query frequency or update pattern.
FAQ
What share of the DEA-C01 exam is Domain 2?
Data Store Management is 26% of scored content, roughly 13 of the 50 scored questions, across four task statements.
Do I need to know vector databases for DEA-C01?
Yes, at a design level. The current guide lists HNSW indexing in Aurora PostgreSQL, vector index types such as HNSW and IVF, and vectorization for Amazon Bedrock knowledge bases.
What is the difference between the Glue Data Catalog and SageMaker Catalog?
The Glue Data Catalog is a technical metastore of table schemas and partitions. Amazon SageMaker Catalog is a business catalog with glossaries, metadata and subscription-based access for data consumers.
Which S3 storage classes should I know?
Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval, Glacier Flexible Retrieval and Glacier Deep Archive, with their retrieval times and minimum storage durations.
How much Redshift table design is tested?
Expect questions on distribution styles, sort keys, COPY best practices, UNLOAD, Spectrum, federated queries, materialized views and locking during concurrent writes.
Is Apache Iceberg really on the exam?
Task 2.1 names managing open table formats, with Apache Iceberg as the example. Know ACID transactions, time travel, schema evolution and row-level changes.
How does AWS DMS Schema Conversion fit here?
It converts database schemas and code objects between engines, such as Oracle to Amazon Aurora PostgreSQL, before or alongside data migration with AWS DMS.
Other Data & Analytics certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
You have reviewed store selection, catalogs, lifecycle rules and schema design. See whether you can pick the right store and table layout when a scenario lists access, latency and retention needs.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the DEA-C01 AI tutor Get any concept explained your way