Amazon DEA-C01: Data Storage and Lake Architecture — Study Guide

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Part of the Amazon Data Engineer Associate DEA-C01 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

This domain covers how AWS storage services and database engines support large-scale data ingestion, durable archival, query performance, and secure governance in modern data platforms. Data engineers must balance cost, access latency, durability, and fine-grained access control while integrating services such as S3, Lake Formation, Redshift, and DynamoDB into pipelines. Understanding storage-class trade-offs, lifecycle automation, managed vs. local storage, and partitioning patterns prevents performance and cost surprises in production.

Amazon S3 storage classes and lifecycle policies

S3 offers multiple storage classes and lifecycle controls to optimize cost and access patterns. Configure storage class at upload (console or CLI: aws s3 cp file s3://bucket/key –storage-class INTELLIGENT_TIERING) or use bucket lifecycle rules (aws s3api put-bucket-lifecycle-configuration –bucket my-bucket –lifecycle-configuration file://lifecycle.json). Intelligent-Tiering automatically moves objects between frequent and infrequent tiers and has a small monitoring fee; enable it for unknown or changing access patterns. Use lifecycle rules to transition objects to GLACIER or DEEP_ARCHIVE for long-term retention and to expire/delete old versions.

Decision criteria and trade-offs:

Intelligent-Tiering: low operational overhead for variable access, monthly monitoring charge per object; best when access pattern is unpredictable.
Glacier vs Glacier Deep Archive: Glacier provides faster standard and expedited retrieval options with higher storage cost; Deep Archive is cheapest for years-long retention with bulk/standard retrieval times (hours).
Standard-IA vs Intelligent-Tiering: Standard-IA has 30-day minimum charge and retrieval fees — avoid for frequently accessed data or short-lived objects.

Operational notes:

Enable versioning (aws s3api put-bucket-versioning –bucket my-bucket –versioning-configuration Status=Enabled) and object lock (aws s3api put-object-lock-configuration –bucket my-bucket –object-lock-configuration file://lock.json) for immutability; enabling MFA Delete requires special CLI operations and the bucket owner account with MFA.
Lifecycle transitions apply to object versions and can be scoped by prefix/tags; use abort-incomplete-multipart-upload to avoid storage leaks.

Data lake design with S3 and Lake Formation

Design a data lake with S3 as the central object store and Lake Formation for centralized access control and cataloging. Register S3 locations as Lake Formation resources, set up an AWS Glue Data Catalog, and use Lake Formation grants for databases/tables (aws lakeformation grant-permissions –principal arn:aws:iam::123456789012:user/analyst –permissions SELECT –resource ‘{…}’). Lake Formation can enforce fine-grained controls: column-level, row-level (filter expressions), and cell-level masking using LF-tags and data filters applied to Glue/Athena queries.

Key configuration and governance patterns:

Register location: use the Lake Formation console to register s3://bucket/path and attach an IAM role that allows Lake Formation to crawl/read.
Fine-grained policies: define LF-tags and attach them to tables/columns; grant permissions with column-list to restrict columns, and use row-filter expressions to limit rows returned for a principal.
Remember that Lake Formation permissions can override or block IAM S3 permissions for Glue/Athena access—grant both Lake Formation and S3-level access where required.

Decision points:

Use Lake Formation when you need centralized cataloging, LF-tags, and fine-grained enforcement across multiple analytics engines.
For simple access control or external tool access, consider S3 bucket policies and IAM, but be careful: analytics engines governed by Lake Formation may ignore IAM-only grants.

Amazon Redshift architecture and storage

Redshift separates compute and managed storage on RA3 nodes versus local SSD-backed DS2 nodes. RA3 nodes use Redshift Managed Storage (RMS) where data resides on Amazon S3 managed by the cluster; choose RA3 for scalable storage with consistent query performance and the ability to pay for compute separately. DS2 nodes store data on instance-local disks which require careful sizing and resizing when data grows.

Configuration and operational details:

Create RA3 cluster via console or CLI: aws redshift create-cluster –cluster-identifier my-cluster –node-type ra3.xlplus –number-of-nodes 2 –master-username admin –master-user-password Passw0rd.
COPY command: must run under a cluster with an IAM role attached that grants S3 read access. Attach role at cluster creation or modify cluster to add iam roles; the role ARN (arn:aws:iam::acct:role/RedshiftS3Role) is referenced in COPY as credentials ‘aws_iam_role=arn:…’.
Monitor WLM queues, short query acceleration, automatic vacuuming, and use SORT/ENCODE to optimize storage and performance.

Comparison (RA3 vs DS2):

RA3: decoupled storage, automatic data tiering to S3, lower storage management, best for growing datasets.
DS2: local SSD storage, lower latency for local data but limited capacity and harder to scale.

DynamoDB and purpose-built database selection

Choose DynamoDB for high-scale key-value and document workloads requiring single-digit millisecond latency. Table design hinges on partition key (and optional sort key) selection: use high-cardinality, well-distributed keys to avoid hot partitions. For sequential or timestamp-based keys, implement random prefixing (sharding) or use UUIDs to spread writes. Use on-demand capacity to avoid provisioning but consider provisioned capacity with autoscaling for predictable workloads and to leverage adaptive capacity on hot partitions.

Practical configuration notes:

Create table CLI: aws dynamodb create-table –table-name Events –attribute-definitions AttributeName=pk,AttributeType=S AttributeName=sk,AttributeType=S –key-schema AttributeName=pk,KeyType=HASH AttributeName=sk,KeyType=RANGE –billing-mode PAY_PER_REQUEST.
Use GSIs for alternate access patterns, enable TTL for automatic expiry, and use DynamoDB Streams + Lambda for change-data-capture patterns.
For caching read-heavy workloads, add DAX; for complex queries or relational needs, choose Aurora or Redshift Spectrum depending on query complexity and consistency needs.

Decision criteria for engine selection:

Use DynamoDB for predictable single-table access patterns and massive scale with low latency.
Use Redshift for complex analytics and large-scale OLAP.
Use Aurora for transactional relational workloads.

Common Pitfalls and Decision Criteria

Using S3 Standard-IA for frequently accessed data — Standard-IA has a minimum 30-day charge; use Standard or Intelligent-Tiering for short-lived or frequently accessed objects.
Forgetting Lake Formation permissions override IAM S3 permissions for Glue/Athena — grant both Lake Formation and S3 access when using Glue/Athena and verify effective permissions in the Lake Formation console.
Redshift COPY requires an IAM role attached to the cluster, not just user permissions — attach an S3-access IAM role to the cluster and reference its ARN in COPY operations.
DynamoDB hot partitions from sequential keys — avoid monotonic keys; use hashed keys, random prefixes, or UUIDs and consider on-demand or autoscaled provisioned capacity.
Enabling S3 Object Lock and MFA Delete incorrectly — object lock requires versioning enabled and proper permissions; MFA Delete can only be enabled/disabled using the CLI with MFA and has strict bucket-owner requirements.
Improper lifecycle transitions without testing retrieval costs and times — test retrieval workflows for Glacier classes to avoid surprise retrieval latency and charges.

Practical Problem: Use-Case Scenario

Acme Media must store 50 TB of raw video ingest, provide analysts query access to transformed metadata, and enforce row- and column-level access for different business units while minimizing storage cost.

Ingest raw video to S3 using multipart upload, tag objects by ingestion date and dataset, use Intelligent-Tiering for initial unknown access patterns.
Configure lifecycle rules to transition media to GLACIER or DEEP_ARCHIVE after a configurable retention period (ensure 30+ day alignment for Standard-IA if considered).
Register S3 locations in Lake Formation, build Glue crawlers to populate the Data Catalog, and grant LF-tag-based row- and column-level permissions to business units.
Store curated metadata in Redshift RA3 for analytics; attach an IAM role to the cluster for COPY from S3 and use VACUUM/ANALYZE operations in maintenance windows.
Use DynamoDB with hashed UUID keys for a high-throughput lookup table of video manifests and enable on-demand capacity to absorb traffic spikes.

Rationale: This approach isolates cold storage cost with Glacier classes, uses Intelligent-Tiering for unknown patterns, applies Lake Formation for secure, fine-grained access control across analytics engines, and selects RA3 for scalable analytics storage while DynamoDB handles low-latency operational lookups.

← Data Ingestion and Collection · All domains · Data Cataloging and Metadata Management →

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