5 Data Pipeline Patterns the AWS DEA-C01 Exam Loves to Test

The AWS Certified Data Engineer Associate (DEA-C01) doesn't test services in isolation. It tests patterns — recurring architectural shapes that show up in scenario after scenario, each with a canonical AWS implementation. Learn the five patterns below and you'll recognize the skeleton inside nearly every ingestion, transformation, and storage question on the exam.

If you're a developer moving into data engineering, this is also the fastest way to think like one: patterns first, services second.

Pattern 1: Stream-to-Lake (Real-Time Ingestion, Durable Landing)

The shape: continuous event data → buffer → durable raw storage → downstream processing.

The AWS implementation: Kinesis Data Streams (or MSK for Kafka workloads) capturing events, Kinesis Data Firehose delivering to S3 with optional Lambda transformation in flight. Raw data lands in S3 partitioned by date/hour, in Parquet.

Why the exam loves it: it tests three decisions at once — stream service selection (Streams for ordering and replay, Firehose for managed delivery, MSK for Kafka compatibility), the transformation point (Lambda in Firehose for light transforms vs. downstream Glue for heavy ones), and the storage format (Parquet over CSV for columnar efficiency and Athena query cost).

The scenario trigger: any question with "real-time," "millions of events," and "durable storage for analytics." The exam's favorite variant adds "with minimal operational overhead" — which selects Firehose over self-managed Streams consumers every time.

The trap: candidates pick Kinesis Data Analytics (Flink) when the scenario only needs delivery, not stream processing. Analytics is for computing on the stream; Firehose is for landing it. Read whether the scenario transforms in flight or just stores.

Pattern 2: CDC-to-Warehouse (Change Data Capture for Operational Analytics)

The shape: operational database → capture row-level changes → replicate to analytics store → BI queries.

The AWS implementation: AWS DMS with ongoing replication (CDC) from the source database (RDS, Aurora, or on-premises via heterogeneous migration) into S3 or Redshift. DMS handles the initial full load plus continuous change capture; the target is modeled for analytics.

Why the exam loves it: it tests the migration-vs-replication distinction. DMS migration is one-time; DMS ongoing replication is CDC. The exam scenario almost always says "with minimal downtime" and "keep the analytics database current" — both phrases point to ongoing replication, not a one-time dump.

The scenario trigger: "migrate from on-premises Oracle to Aurora with minimal downtime" or "replicate order data to Redshift for reporting in near-real time." Know that DMS supports both homogeneous (Oracle→Oracle) and heterogeneous (Oracle→Aurora PostgreSQL) — the exam tests whether you reach for DMS before proposing manual ETL.

The trap: choosing S3 + Athena when the scenario demands repeated complex queries over structured data — that's Redshift's home turf. CDC-to-warehouse ends in a warehouse when the workload is BI; it ends in S3 when the workload is a data lake.

Pattern 3: Event-Driven Micro-ETL (Serverless Per-Record Processing)

The shape: file or event lands → trigger → lightweight transform → next stage, all serverless, all event-driven.

The AWS implementation: S3 Event Notifications → Lambda (validate, enrich, convert format) → destination (another S3 prefix, DynamoDB, or SQS for downstream buffering). Orchestrated ad hoc or coordinated with Step Functions when multi-step.

Why the exam loves it: it's the purest test of serverless thinking. The exam checks whether you know Lambda's role (per-record, short-duration transforms — remember the 15-minute timeout ceiling), S3 event notification mechanics (prefix/suffix filters to avoid recursive triggers — a classic exam trap: Lambda writing back to the same prefix it watches), and when to add SQS (buffering when downstream can't keep up, DLQ for poison messages).

The scenario trigger: "process uploaded CSV files," "images need thumbnailing on upload," "validate records as they arrive." Small, frequent, event-shaped work.

The trap: the recursive-trigger scenario. "A Lambda function processes S3 uploads but runs repeatedly" — the cause is the function writing output to the watched prefix. The fix: separate input/output prefixes or suffix filters. This exact scenario appears on the exam in multiple disguises.

Pattern 4: Orchestrated Batch ELT (Scheduled Heavy Transformation)

The shape: raw data staged in S3 → scheduled orchestration → distributed transformation → curated data products.

The AWS implementation: data lands in S3 (raw zone); Step Functions or MWAA (managed Airflow) orchestrates; Glue (serverless Spark ETL with crawlers and the Data Catalog) or EMR (for workloads needing cluster control) transforms; results land in the curated zone or Redshift. Glue job bookmarks ensure only new data is processed on reruns.

Why the exam loves it: it tests the ELT mindset — land first, transform with elastic compute — and the orchestration decision. Step Functions for serverless workflow coordination with error handling; MWAA when the scenario mentions Airflow DAGs or complex cross-team scheduling. The exam also tests idempotency and reruns: job bookmarks, partitioned outputs, and why rerunning a failed job shouldn't duplicate data.

The scenario trigger: "nightly ETL," "transform terabytes," "coordinate multiple processing steps with dependencies and retries." Batch + heavy + scheduled = this pattern.

The trap: picking EMR when Glue suffices. The exam's cost-conscious phrasing — "with minimal operational overhead" — selects Glue's serverless model; EMR is for when you need Hadoop-ecosystem control or custom cluster configurations the scenario explicitly requires.

Pattern 5: Governed Lakehouse (Storage + Access Control + Discovery)

The shape: centralized S3 data lake → fine-grained permissions → cataloged discovery → multi-engine query.

The AWS implementation: S3 as the lake (raw/curated zones, lifecycle policies moving cold data to cheaper tiers); Lake Formation for fine-grained access control (database/table/column-level grants, LF-tags for attribute-based access); Glue Data Catalog as the metadata layer; Athena, Redshift Spectrum, and EMR all querying the same data.

Why the exam loves it: it tests governance as architecture. The exam scenarios here sound like compliance problems — "analysts should see only their region's data," "PII columns must be restricted" — and the answer is Lake Formation's granular permissions, not bucket policies or IAM alone. It also tests the catalog concept: without the Data Catalog, the lake is a swamp; crawlers and table definitions are what make data discoverable.

The scenario trigger: "multiple teams query shared data," "column-level security," "audit who accessed what." Governance vocabulary in the scenario means Lake Formation in the answer.

The trap: answering IAM when the question needs Lake Formation. IAM controls who can reach the lake; Lake Formation controls what they can see inside it. The exam tests that layering deliberately.

How to Study Patterns, Not Services

For each pattern above, draw the architecture on paper: boxes, arrows, service names. Then cover the service names and reconstruct them from the scenario triggers. That exercise — trigger → pattern → services — is the exact cognitive motion the exam demands.

Then validate against real exam-style scenarios with a free DEA-C01 practice test: 190+ questions with instant explanations and no signup. Study4Pass builds its questions around the same scenario patterns, so every wrong answer teaches you a trigger you misread. Drill until the patterns are reflex — on exam day, recognition speed is the difference between finishing comfortably and racing the clock.

Five patterns, one exam. Master the shapes and the services place themselves.