AWS Certified Data Engineer – Associate DEA-C01 Exam Course

A compressed, exam-focused course built from the improved 1,040-question DEA-C01 practice bank and aligned to the current AWS exam guide. Use it as a start-to-finish learning path, a decision guide, and a final revision sheet.

1. Exam Overview

What the certification validates

The AWS Certified Data Engineer – Associate (DEA-C01) exam tests whether you can implement data pipelines and data stores on AWS, then monitor, troubleshoot, secure, govern, and optimize them. The exam is not only about naming services. Most questions describe a workload and ask for the best fit based on latency, scale, replayability, operational effort, cost, access pattern, security, or governance.

Current exam format

Blueprint version note

The current AWS documentation includes DEA-C01 guide Version 1.1, published on December 12, 2025. The revision consolidates skills and adds or emphasizes newer areas such as:

• Amazon Aurora use cases
• Amazon MemoryDB for Redis for fast key/value access
• Apache Iceberg and Amazon S3 Tables
• Vector indexes such as HNSW and IVF
• Amazon Bedrock knowledge-base and LLM-assisted processing concepts
• Amazon SageMaker Catalog lineage and governed-access concepts
• Amazon SageMaker Unified Studio domains, domain units, and projects
• Amazon Q, Amazon Kendra, and AWS Data Exchange as in-scope services

AWS removed AWS Cloud9, AWS CodeCommit, and AWS Schema Conversion Tool (AWS SCT) from the current in-scope services list. However, the current Domain 2 task page still references schema conversion examples such as AWS SCT and AWS DMS Schema Conversion. Know the migration concept, prioritize DMS Schema Conversion, and do not overinvest in old SCT-specific details.

How to think during the exam

For each scenario, identify the requirement that controls the answer:

1. Data movement: streaming, micro-batch, batch, CDC, file transfer, or API.
2. Latency: seconds, minutes, hourly, nightly, or ad hoc.
3. Replay: must consumers re-read events after a defect or outage?
4. Processing model: per-event, distributed batch, stateful stream, warehouse SQL, or containerized custom workload.
5. Storage access pattern: object lake, analytical warehouse, relational transactions, low-latency key/value, search, graph, document, Cassandra-compatible, or vector similarity.
6. Operations: managed/serverless preference versus configuration control.
7. Security and governance: least privilege, encryption, catalog, lineage, audit, PII, sovereignty, and cross-account access.
8. Failure handling: retries, backoff, queue buffering, dead-letter queue, quarantine, alarms, and logs.

The wrong answers are often real AWS services used at the wrong layer. Eliminate options that solve a different problem.

2. Exam Domains

Recommended study-time distribution

Spend roughly the same percentage of your preparation time as the exam weight, but give additional review time to cross-domain topics:

• Amazon S3, AWS Glue, Amazon Redshift, DynamoDB, Athena, Lambda
• Kinesis Data Streams, Kinesis Data Firehose, Amazon MSK, DMS
• SQS, SNS, EventBridge, Step Functions, MWAA
• Glue Data Catalog, Lake Formation, SageMaker Catalog, Unified Studio
• CloudWatch, CloudTrail, CloudTrail Lake, AWS Config
• IAM, KMS, Secrets Manager, Parameter Store, PrivateLink

3. Start-to-Finish Study Path

Phase 1 — Build the data-engineering mental model

Learn to map a requirement to a layer:

Phase 2 — Master the highest-frequency service decisions

Prioritize these comparisons:

1. Kinesis Data Streams vs Firehose vs MSK
2. Glue vs EMR vs Lambda vs Flink vs Redshift SQL
3. EventBridge vs Step Functions vs MWAA vs Glue workflow
4. SQS vs SNS
5. S3 vs Redshift vs DynamoDB vs Aurora/RDS
6. Glue Data Catalog vs crawler vs Lake Formation vs SageMaker Catalog
7. CloudWatch vs CloudTrail vs AWS Config
8. Redshift Spectrum vs federated query vs data sharing vs materialized view
9. S3 Lifecycle vs S3 Versioning vs Object Lock-style retention protections
10. Bucket permission vs KMS-key permission for cross-account encrypted data

Phase 3 — Study each blueprint task methodically

Use Section 4 as your main course. Do not memorize only the service names. For every service, learn:

• the workload it is designed for;
• the signal words that suggest it;
• the strongest competing service;
• why the competitor fails in that specific scenario.

Phase 4 — Practice architecture elimination

Before choosing an answer, remove options that:

• solve notification when the question asks for buffering;
• solve delivery when the question asks for replay;
• solve storage when the question asks for orchestration;
• solve schema discovery when the question asks for authorization;
• solve durability when the question asks for encryption;
• solve API auditing when the question asks for configuration history;
• solve batch analytics when the question asks for millisecond operational access.

Phase 5 — Revise current-version additions

Give targeted review time to:

• Apache Iceberg and Amazon S3 Tables
• HNSW and IVF vector indexes
• Aurora PostgreSQL vector use cases
• MemoryDB for Redis
• Bedrock knowledge bases and LLM-assisted processing
• SageMaker Catalog lineage and project-based access
• SageMaker Unified Studio domains, domain units, and projects

Phase 6 — Final simulation strategy

When practicing:

• complete mixed-domain sets;
• justify why the best wrong answer fails;
• flag questions where two answers look possible;
• identify the requirement word that breaks the tie;
• revisit weak decisions, not only wrong questions.

4. Core Concepts by Domain

Domain 1: Data Ingestion and Transformation — 34%

This is the largest domain. Expect scenarios that combine source type, latency, replay, processing choice, scheduling, failure recovery, and deployment.

Task 1.1 — Perform data ingestion

Streaming ingestion

Replayability rule

Replay requirement → think Kinesis Data Streams or Kafka/MSK, not Firehose.

Firehose is excellent for managed destination delivery. It is not the default answer when the scenario explicitly says consumers need to re-read the last several hours after fixing processing logic.

Fan-in and fan-out

• Fan-in: many producers write into a shared ingestion path.
• Fan-out: multiple consumers read the same stream for different purposes.
• Kinesis enhanced fan-out is relevant when consumers need dedicated read throughput and low-latency delivery without competing for shared stream read throughput.
• An SQS queue distributes messages among competing consumers. It does not automatically give every independent analytics application its own copy of every record.

Throttling and rate limits

Recognize these signals:

• HTTP 429 responses from APIs
• Kinesis ProvisionedThroughputExceeded
• DynamoDB hot partitions or throttled requests
• RDS connection exhaustion
• downstream systems overloaded by Lambda concurrency

Use:

• exponential backoff with jitter;
• bounded retries;
• appropriate stream capacity or shard scaling;
• well-distributed partition keys;
• controlled Lambda concurrency;
• buffering with SQS when bursts must be absorbed.

Do not retry immediately in a tight loop. That amplifies the failure.

Batch and file ingestion

Events versus schedules

Trap: An S3 event cannot guarantee a daily run when no object arrives. A time schedule cannot provide immediate object-by-object responsiveness without polling.

APIs and connectivity

Know these concepts:

• consuming external data APIs;
• building data APIs for downstream consumers;
• Amazon API Gateway as an API front door;
• JDBC and ODBC connectivity to data sources;
• IP allowlists where a source requires them;
• retries, rate limits, authentication, and secret storage.

Task 1.2 — Transform and process data

Select the processing engine

Glue versus EMR versus Lambda

Use this elimination rule:

• Choose Lambda for a small event handler.
• Choose Glue for managed serverless ETL, especially Spark over S3 and catalog-integrated workflows.
• Choose EMR when you need distributed open-source frameworks with deeper cluster-level control.
• Choose Flink when the computation is continuously stateful over streams.

Trap: Do not choose EMR merely because the word “data” appears. Do not choose Lambda for a massive distributed join. Do not choose Glue for a requirement that explicitly demands detailed cluster bootstrap control.

File formats and partitioning

CSV is readable but expensive for repeated analytics scans. Apache Parquet is columnar and typically reduces scanned bytes when queries read only a subset of columns.

For Athena and data-lake analytics:

• convert large analytical datasets to Parquet;
• compress appropriately;
• partition by common selective filters such as date, region, or source;
• avoid excessive tiny files;
• avoid partitioning by extremely high-cardinality fields when it creates too many small partitions.

Volume, velocity, and variety

These dimensions help decide batch versus streaming, storage layout, processing engine, and cost model.

LLM-assisted processing

The revised guide includes integrating LLMs for data processing. The expected reasoning is practical:

• use Amazon Bedrock models in a controlled workflow for tasks such as summarization, categorization, enrichment, or extraction from unstructured text;
• validate generated output before downstream use;
• store prompts, outputs, metadata, and quality signals where traceability matters;
• do not assume a custom model must be trained from scratch.

Task 1.3 — Orchestrate data pipelines

Dead-letter queue and quarantine pattern

Use a DLQ or quarantine store when records repeatedly fail processing. Preserve:

• original payload or reference;
• failure reason;
• timestamp;
• pipeline stage;
• retry count;
• correlation identifier.

This allows investigation and controlled replay without blocking valid records.

Task 1.4 — Apply programming concepts

Know the following:

• use AWS SDKs and APIs instead of scraping the console;
• use AWS SAM for serverless application packaging;
• use AWS CloudFormation or AWS CDK for repeatable IaC deployment;
• use CI/CD services such as CodeBuild, CodeDeploy, and CodePipeline;
• use Lambda layers for shared dependencies when appropriate;
• mount EFS from Lambda when shared file-system access is required and properly configured;
• do not attach EBS volumes directly to Lambda;
• tune Lambda memory, timeout, concurrency, event-source batch size, and retry behavior;
• use logs and metrics during debugging;
• consider EC2 when unmanaged compute control is required;
• consider ECS/EKS for containerized processing.

Lambda concurrency rule

If a downstream database has limited connections, unlimited Lambda concurrency can create a failure storm. Configure a reasonable concurrency limit and tune the event-source behavior. Optimize the entire path, not only Lambda throughput.

Domain 2: Data Store Management — 26%

Domain 2 is about selecting the correct store and configuring it for the access pattern. The exam often gives several technically possible services, but only one is purpose-built for the requirement.

Task 2.1 — Choose a data store

Core data-store map

Amazon S3 and data-lake design

Use S3 as the default durable landing zone for raw files. Design for:

• clear prefixes and partitions;
• immutable raw zones where appropriate;
• curated zones with optimized formats;
• lifecycle rules;
• encryption;
• access controls;
• catalog registration;
• versioning or retention protections where recovery or auditability matters.

DynamoDB partition-key reasoning

A DynamoDB design starts from access patterns. Choose a partition key that distributes traffic well.

Hot partition warning: If most reads or writes use one value, throughput concentrates on one partition. Consider higher-cardinality keys, composite patterns, or controlled write sharding.

Do not choose DynamoDB for complex ad hoc analytical joins. Do not choose Redshift for customer-facing single-digit-millisecond operational lookups.

Amazon Redshift access patterns

Also understand distribution styles, sort keys, compression, and workload-driven table design. Optimize based on joins, filters, and scan patterns.

Locks

The blueprint includes managing locks to prevent access to data in services such as Redshift and RDS. Understand the purpose:

• preserve consistency during concurrent operations;
• identify blocking sessions;
• avoid unnecessary long-running transactions;
• troubleshoot lock contention rather than scaling unrelated resources.

Open table formats: Apache Iceberg and S3 Tables

Apache Iceberg is an open table format for large analytical tables. Think beyond “files in folders.” Iceberg adds table-level metadata and supports capabilities such as:

• schema evolution;
• partition evolution;
• transactional table operations;
• snapshot-oriented management;
• improved table maintenance patterns.

Amazon S3 Tables is a current in-scope service for managed tabular-storage patterns in S3. Exam questions may test when ordinary raw S3 objects are sufficient versus when managed table semantics are beneficial.

Vector indexes: HNSW and IVF

The updated blueprint expects recognition of vector indexes and vectorization concepts.

Use the requirement to reason about recall, latency, memory, build time, and scale. B-tree indexes are not the default solution for embedding similarity search.

A current example is vector indexing with Aurora PostgreSQL. Amazon Bedrock knowledge-base scenarios may involve chunking content, generating embeddings, and storing them in a vector-capable index for semantic retrieval.

Task 2.2 — Understand data cataloging systems

Catalog components

Catalog traps

• A crawler discovers schema. It does not authorize users.
• Lake Formation governs permissions. It is not simply a crawler.
• A folder structure is not automatically an Athena partition. Catalog metadata or partition projection must align with the layout.
• New S3 partitions might exist physically but remain invisible to queries until catalog metadata is synchronized.

Task 2.3 — Manage the lifecycle of data

Important lifecycle distinctions

• Lifecycle transition changes storage class.
• Lifecycle expiration deletes according to age-based policy.
• Versioning preserves recoverable object versions.
• DynamoDB TTL marks items for automatic expiration; do not treat it as an immediate synchronous deletion guarantee.
• Retention protection prevents inappropriate deletion; use appropriate controls and tightly scoped permissions for audit archives.

Task 2.4 — Design data models and schema evolution

Schema evolution

Design for compatible change:

• additive optional fields are often easier to support than breaking changes;
• historical records may not contain newly introduced fields;
• preserve backward compatibility where possible;
• version schemas when changes are significant;
• test readers and writers independently;
• keep lineage and catalog metadata current.

Schema conversion

Recognize migration scenarios that require converting a source schema for a target database. The current blueprint task page references AWS DMS Schema Conversion and legacy AWS SCT examples. Focus on the migration purpose:

• assess compatibility;
• convert supported schema objects;
• identify manual remediation;
• combine schema work with data migration or CDC when required.

Data lineage

Lineage answers questions such as:

• Where did this dataset originate?
• Which transformation generated this field?
• Which pipelines depend on this table?
• What will break if a schema changes?
• Which approved data product is the trusted source?

Amazon SageMaker Catalog and SageMaker lineage capabilities are relevant current concepts.

Domain 3: Data Operations and Support — 22%

Domain 3 tests whether you can keep pipelines useful after deployment. Expect automation, SQL analysis, dashboards, logs, metrics, alerts, debugging, and data-quality questions.

Task 3.1 — Automate data processing by using AWS services

Use:

• EventBridge Scheduler for recurring invocations;
• EventBridge events for event routing;
• Lambda for event-driven automation;
• Step Functions or MWAA for orchestration;
• Glue, EMR, and Redshift features for processing;
• SDK calls for supported programmatic control;
• Athena for serverless SQL over S3;
• Glue DataBrew for visual preparation and profiling;
• SageMaker Unified Studio for governed data and analytics workspaces;
• APIs for reusable data access paths.

Console-scraping trap

When a service API or SDK exists, use it. Scraping console HTML is brittle and unsupported.

Task 3.2 — Analyze data by using AWS services

SQL analysis

Understand:

• filtering;
• grouping;
• aggregation;
• joins;
• window functions;
• rolling averages;
• pivoting;
• reusable views;
• materialized results versus logical views.

A seven-day rolling average normally requires a window function over an ordered date range, not only GROUP BY.

Athena versus Redshift analysis

Provisioned versus serverless

Avoid assuming serverless is always cheaper or provisioned is always faster. Match the workload.

Visualization and preparation

Know the role of:

• Glue DataBrew for visual profiling and preparation;
• QuickSight-style business visualization concepts;
• notebooks for exploration;
• SageMaker Data Wrangler where data-preparation scenarios reference it;
• SageMaker Unified Studio for governed collaborative workflows.

The current AWS documentation may show Amazon QuickSuite in the in-scope service list while domain skill examples still reference Amazon QuickSight. Focus on visualization and analytics decision-making rather than product-name trivia.

Task 3.3 — Maintain and monitor data pipelines

Observability map

CloudTrail versus AWS Config versus CloudWatch

• CloudTrail: API activity — who called what and when.
• AWS Config: configuration state and change history.
• CloudWatch metrics and alarms: operational conditions.
• CloudWatch Logs: application and service logs.
• Logs Insights: search and aggregate CloudWatch Logs.

This distinction appears repeatedly in realistic exam scenarios.

Spark and Glue troubleshooting

When a distributed job slows down or fails:

1. inspect logs and metrics;
2. locate the slow stage;
3. check skewed keys and partition sizes;
4. inspect executor memory and shuffle behavior;
5. check tiny files, serialization, retries, and downstream throttling;
6. verify source and destination connectivity;
7. tune resources only after identifying the bottleneck.

Data skew

A skewed join key sends a disproportionate amount of data to a subset of workers. Symptoms include:

• one or a few tasks running much longer than the rest;
• uneven shuffle partitions;
• executor memory pressure;
• a slow final stage despite many idle workers.

Mitigation depends on the workload: repartitioning, key salting, broadcast joins for suitable small tables, pre-aggregation, filtering earlier, or redesigning the operation.

Task 3.4 — Ensure data quality

Quality dimensions

Quality patterns

• validate during processing;
• define explicit rules;
• quarantine malformed or invalid records;
• preserve error context;
• alert on threshold breaches;
• sample large datasets for fast initial assessment;
• run full checks for critical controls where required;
• reconcile counts and aggregates between stages;
• track quality trends over time.

Trap: S3 Versioning preserves object history but does not validate field values. A DLQ or quarantine path is better than silently dropping invalid records.

Domain 4: Data Security and Governance — 18%

Domain 4 is smaller but highly scoreable if you master the distinctions. Security questions often test two permission layers, least privilege, or the difference between authentication, authorization, encryption, and auditing.

Task 4.1 — Apply authentication mechanisms

IAM roles first

Use roles with temporary credentials for AWS workloads:

• Lambda execution role;
• Glue job role;
• Step Functions execution role;
• EC2 instance profile;
• service role for managed integrations;
• cross-account role when appropriate.

Do not embed long-lived administrator access keys in code. Do not share root credentials.

Secrets

Network access

• Use VPC security groups to allow only required ports and sources.
• Use private subnets and controlled routing where appropriate.
• Use AWS PrivateLink interface VPC endpoints for private access to supported services without traversing the public internet.
• Use S3 Access Points where they simplify controlled access patterns.
• Use IP allowlists only when required by the source or partner; do not treat them as a replacement for IAM and encryption.

Managed versus unmanaged services

A managed service reduces operational responsibility but may reduce low-level control. Choose according to the requirement. If a scenario repeatedly says “minimal operational overhead,” prefer the managed or serverless fit that still meets the technical need.

SageMaker Unified Studio governance concepts

Understand:

• domains;
• domain units;
• projects;
• governed collaboration boundaries;
• controlled access to data assets.

Task 4.2 — Apply authorization mechanisms

Least privilege

Grant only:

• the necessary actions;
• on the necessary resources;
• for the necessary principals;
• under the necessary conditions.

Example: A Lambda function that reads one S3 landing prefix should receive scoped s3:GetObject permissions for that prefix, not AdministratorAccess.

Lake Formation

Use AWS Lake Formation for centralized fine-grained permissions over governed data-lake access. It can manage access patterns involving services such as Athena, Redshift, EMR, and S3-backed data.

Authorization models

Task 4.3 — Ensure data encryption and masking

Encryption at rest

For controlled S3 encryption with key-policy and audit requirements, use SSE-KMS with an appropriate AWS KMS key design.

Encryption in transit

Use TLS for sensitive data moving across networks. Durability, versioning, and lifecycle rules do not encrypt network traffic.

Cross-account SSE-KMS access

Encrypted cross-account access usually requires permissions at both layers:

1. access to the data resource, such as S3 object permissions;
2. permission to use the KMS key for the required cryptographic action.

Trap: A bucket policy alone is insufficient when the receiving principal cannot decrypt the object.

Masking and anonymization

Use masking, tokenization, or anonymization when non-production or analytical consumers do not need direct identifiers. Do not copy raw production identifiers into lower-trust environments without justification.

Task 4.4 — Prepare logs for audit

Use:

• CloudTrail for API-call evidence;
• CloudWatch Logs for application logs;
• CloudTrail Lake for centralized CloudTrail event queries;
• Athena for SQL over archived logs in S3;
• Logs Insights for CloudWatch-log exploration;
• OpenSearch for indexed full-text search and dashboards;
• EMR for large-scale log-processing cases;
• controlled S3 log archives with retention protections and tightly scoped permissions.

Task 4.5 — Understand data privacy and governance

PII identification

Use Amazon Macie to discover sensitive data in S3. Lake Formation can complement this by governing access to cataloged lake data.

Data sovereignty

Data sovereignty means controlling where regulated data is stored, copied, backed up, and replicated. Check:

• primary Region;
• backup Region;
• replication destination;
• disaster-recovery copies;
• cache or edge behavior where relevant;
• cross-account shares;
• export workflows.

Do not casually introduce copies in disallowed Regions.

AWS Config

Use AWS Config to review configuration changes over time, such as when an S3 encryption setting changed. Use CloudTrail when the key question is which API call or principal performed the action.

Governed sharing

Recognize:

• Redshift data sharing;
• Lake Formation permissions;
• SageMaker Catalog projects;
• ownership and approval workflows;
• business catalog discovery;
• lineage;
• explicit data-sharing patterns.

5. Service Selection Guide

Ingestion and transport

Processing

Orchestration