AWS DEA-C01 Cheat Sheet: Ingestion, Lakehouse, and Governance

Keep this cheat sheet open while drilling questions. DEA‑C01 rewards “production data platform realism”: correct service selection, replayability/backfills, partitioning/file formats, monitoring and data quality, and governance-by-default.

CDC: Change data capture, where source-system changes are emitted as events for downstream ingestion.

ETL: Extract, transform, and load workflow for moving and reshaping data into a target system.

Lake Formation: AWS governance layer for permissions and controls on S3-based data lakes.

MWAA: Managed Workflows for Apache Airflow, the AWS managed orchestration service for Airflow DAGs.

Data flow chooser

Use this when the question is really about where the pipeline should land, transform, govern, and publish.

    flowchart LR
	  SRC["Sources"] --> ING["Ingest: batch, stream, or CDC"]
	  ING --> RAW["Raw S3 landing"]
	  RAW --> ETL["Transform: Glue, EMR, Lambda"]
	  ETL --> CUR["Curated S3 / warehouse"]
	  CUR --> GOV["Governance: Lake Formation + catalog + permissions"]
	  CUR --> OBS["Observe: CloudWatch, CloudTrail, Macie"]

DEA-C01 answer sequence

Use this when the stem mixes sources, ingestion, storage, governance, and consumption.

    flowchart TD
	  S["Scenario"] --> I["Identify the source shape"]
	  I --> P["Pick batch, streaming, or CDC"]
	  P --> L["Land in durable storage first"]
	  L --> T["Transform with the right engine"]
	  T --> G["Apply catalog + permissions + governance"]
	  G --> C["Choose the serving layer"]
	  C --> M["Monitor quality, cost, and replayability"]

Quick facts (DEA-C01)

I verified these current AWS exam facts on May 24, 2026.

Domain weights and review priority

DEA-C01 is an implementation exam. Prefer answers that make pipelines repeatable, observable, governed, and recoverable; reject answers that only move data once without replay, quality checks, ownership, or cost controls.

Data engineering proof stack

DEA-C01 questions usually test whether a pipeline can survive real data-platform pressure, not whether you can name a single analytics service. Before choosing the answer, walk the scenario through this stack:

1. Source contract: identify batch, stream, CDC, API, file, database, SaaS, or event source behavior, including schema and arrival guarantees.
2. Durable landing: preserve raw or minimally transformed data when replay, audit, or backfill matters.
3. Processing semantics: choose the engine from volume, velocity, transformation complexity, latency, state, ordering, and cost.
4. Data shape: control file format, compression, partitioning, small-file behavior, schema evolution, table format, and catalog metadata.
5. Quality path: validate freshness, completeness, duplicates, nulls, schema drift, bad records, and quarantine/replay behavior.
6. Governance boundary: apply IAM, Lake Formation, KMS, Macie, CloudTrail, logging, privacy controls, and cross-account sharing deliberately.
7. Operations evidence: prove success with job history, metrics, logs, lineage, freshness checks, cost signals, and alert ownership.

If an answer moves data successfully but cannot replay, explain freshness, isolate bad records, or prove governed access, it is usually too thin for Data Engineer - Associate.

Official task compression

Data Ingestion and Transformation covers batch, streaming, CDC, APIs, scheduling, fan-in/fan-out, replayability, transformation, orchestration, code, and IaC. Preserve raw data, handle duplicates, support replay, and choose the transform engine from volume, velocity, variety, latency, and operational cost.

Data Store Management covers store choice, cataloging, lifecycle, schema evolution, Redshift/S3 movement, open table formats, and vector concepts. Storage decisions are access-pattern decisions: query engine, file format, partitioning, catalog, lifecycle, schema evolution, and governance all interact.

Data Operations and Support covers automation, analysis, monitoring, logs, troubleshooting, data quality, skew, sampling, cost/performance, and operational evidence. A pipeline is not production-ready until freshness, quality, cost, failures, lineage, and alerts are observable.

Data Security and Governance covers IAM, Lake Formation, KMS, masking, audit logs, privacy, data sharing, sovereignty, and controlled access. Prefer least privilege, fine-grained lake permissions, encryption, auditability, PII detection, and Region controls over informal bucket sprawl.

DEA-C01 boundary cues

AWS frames DEA-C01 as a data engineering implementation exam. Use that boundary to reject overbuilt or off-scope answers:

• If the answer performs ML training or inference, it is probably outside the intended candidate scope unless the stem is only asking about data preparation for that downstream use.
• If the answer draws business conclusions from data, it is likely analyst work; DEA-C01 expects the data engineer to make the data reliable, queryable, governed, and observable.
• If the answer depends on language-specific syntax, be careful. The exam expects programming concepts for pipelines, not memorization of one language’s syntax details.
• If the answer chooses a store before identifying volume, variety, velocity, query pattern, governance, and lifecycle, it is probably guessing.
• If the answer fixes a failed pipeline without logs, metrics, job history, checkpoints, and replay/quarantine behavior, it is operationally incomplete.

Fast strategy (what the exam expects)

• If the requirement is replayable + backfillable, design for idempotency, checkpoints, and reprocessing (S3 as durable landing is common).
• If you see “best cost/performance for queries on S3”, think Parquet + partitioning + Athena/Redshift Spectrum, not raw CSV scans.
• If you see “govern access to S3 data across services”, think Lake Formation + Glue Data Catalog, not just IAM.
• If you see “batch vs streaming”, focus on latency, ordering, retention, and operational complexity.
• If you see “audit” or “governance”, include CloudTrail, central log storage, and controlled access to logs.
• If you see vectors in a data-engineering stem, stay grounded in data-store and retrieval design: storage, metadata filters, security, lifecycle, and access pattern before model behavior.

Question-type traps

Unanswered questions are incorrect and there is no penalty for guessing. With 65 questions in 130 minutes, your average budget is exactly 2 minutes per question; do not spend 6 minutes on one dense pipeline scenario before banking easier service-selection points.

Scenario eliminations

Production pipeline evidence chain

Use this chain when the stem asks for a durable data platform rather than a one-time transfer.

    flowchart LR
	  S["Source contract"] --> L["Raw durable landing"]
	  L --> C["Checkpoint and dedupe key"]
	  C --> V["Validation and quarantine"]
	  V --> T["Transform to curated format"]
	  T --> M["Catalog, partition, and lineage"]
	  M --> G["Govern access and keys"]
	  G --> O["Freshness, cost, and failure alarms"]

The strongest DEA-C01 answer usually shows where records came from, how the job can replay safely, how bad records are isolated, how consumers discover the table, and how operators prove freshness and access control.

Data-platform design checks

Storage and schema chooser

Operations evidence map

Final 20-minute recall (exam day)

Cue -> best answer (pattern map)

Must-memorize DEA defaults

Store and cost decision traps

Last-minute traps

• Assuming exactly-once semantics by default.
• Partitioning on high-cardinality columns that hurt performance.
• Relying only on IAM where Lake Formation is explicitly required.
• Shipping pipelines without backfill/replay design.

1) End-to-end data platform on AWS (mental model)

    flowchart LR
	  SRC["Sources<br/>(SaaS, DBs, apps, streams)"] --> ING["Ingest<br/>(DMS, AppFlow, Kinesis, MSK)"]
	  ING --> RAW["S3 data lake<br/>(raw/bronze)"]
	  RAW --> ETL["Transform<br/>(Glue, EMR, Lambda)"]
	  ETL --> CUR["S3 curated<br/>(silver/gold)"]
	  CUR --> CAT["Glue Data Catalog"]
	  CAT --> ATH["Athena<br/>(serverless SQL)"]
	  CUR --> RS["Redshift<br/>(warehouse)"]
	  ATH --> BI["QuickSight / BI"]
	  RS --> BI
	  CUR --> GOV["Lake Formation<br/>(permissions)"]
	  ING --> ORCH["Orchestrate<br/>(MWAA, Step Functions, EventBridge)"]
	  ORCH --> ETL
	  MON["Monitor + audit<br/>(CloudWatch, CloudTrail, Macie)"] --> ORCH
	  MON --> RS
	  MON --> ATH

High-yield framing: DEA‑C01 is about the pipeline + platform, not just one service.

2) Ingestion patterns (Domain 1)

Batch vs streaming vs CDC (picker)

Streaming and CDC traps

Triggers and scheduling (high yield)

3) ETL and processing choices (Domain 1)

Glue vs EMR vs Lambda vs Redshift (fast picker)

File formats (exam-friendly rules)

• Use Parquet/ORC for analytics on S3 (columnar + compression).
• Avoid raw CSV/JSON at scale for Athena/Redshift Spectrum scans (cost and performance).

4) Catalogs, partitions, and schema drift (Domain 2)

Glue Data Catalog (what it does)

• Central metadata store for S3 data (databases/tables/partitions).
• Enables engines like Athena, EMR, and Redshift Spectrum to interpret schema.

Crawlers vs explicit DDL

High-yield rule: keep partitions in sync (MSCK REPAIR / partition projection / crawler updates), or queries “miss” new data.

Open table formats, vectors, and catalogs

5) Storage and analytics service selection (Domain 2/3)

Athena vs Redshift (exam picker)

Redshift data loading (high yield)

• Use COPY from S3 for fast loads (parallel, columnar-friendly).
• Use UNLOAD to export query results back to S3.

6) SQL patterns (Domain 1/3)

Partition pruning (Athena mindset)

If your table is partitioned by dt, always filter by it:

1SELECT *
2FROM curated.events
3WHERE dt = '2025-12-12'
4  AND event_type = 'purchase';

CTAS for repeatable outputs (Athena)

1CREATE TABLE curated.daily_sales
2WITH (format='PARQUET', partitioned_by=ARRAY['dt'])
3AS
4SELECT dt, customer_id, SUM(amount) AS total
5FROM raw.sales
6GROUP BY dt, customer_id;

7) Orchestration and reliability (Domain 1/3)

MWAA vs Step Functions (fast picker)

    flowchart LR
	  E["EventBridge schedule"] --> W["Workflow start"]
	  W --> I["Ingest"]
	  I --> V{"Valid?"}
	  V -->|yes| T["Transform"]
	  V -->|no| Q["Quarantine + alert"]
	  T --> C["Catalog/partitions update"]
	  C --> P["Publish dataset"]
	  P --> N["Notify (SNS)"]

High-yield reliability rules:

• Design for retries + duplicates (at-least-once is normal).
• Make steps idempotent (safe re-runs).
• Track freshness/latency SLIs (what matters to users).

8) Monitoring and troubleshooting (Domain 3)

What to monitor

• Pipeline health: failures, retries, runtime, backlog/lag
• Freshness: “is today’s partition present?”
• Cost: scan volume (Athena), cluster usage (EMR/Redshift), data transfer
• Security/audit: access logs, permission changes

Common AWS tooling:

• CloudWatch (metrics/logs/alarms, Logs Insights)
• CloudTrail (API calls; audit)
• Macie (PII discovery; policy violations)

Troubleshooting map

9) Data quality (Domain 3)

Data quality dimensions (memorize)

High-yield pattern: run checks in-pipeline, quarantine bad records, and alert.

10) Security and governance (Domain 4)

Lake Formation (why it’s a big deal)

Lake Formation helps you manage fine-grained permissions for data in S3 across engines like Athena/EMR/Redshift Spectrum, using a consistent governance model.

Encryption and key points

• Prefer SSE-KMS for S3 and service-level encryption for analytics services.
• Use TLS for encryption in transit.
• Don’t log secrets or raw PII; keep logs access-controlled.

Audit readiness checklist

• CloudTrail enabled and centralized (optionally CloudTrail Lake for queries)
• CloudWatch Logs retention + encryption set
• Access to logs is restricted (separation of duties)
• Data sharing has explicit approvals and is traceable

Governance and privacy chooser

Next steps

• Use Resources to stay anchored to the official exam guide and core analytics docs.
• Use the FAQ to confirm expected depth, candidate profile, and service coverage.
• Turn your weak rows into replayable scenario prompts and drill them under time.

Quiz