Data Ingestion and Transformation Study Guide — DEA-C01

34% of the exam · domain 1 of 4 · AWS Data Engineer Associate · Free Data Ingestion and Transformation practice questions

0 of 46 topics covered
What the exam asks here — tap to tick off0 / 12 covered
Domain 1 of 4

Data Ingestion and Transformation

This domain accounts for 34% of the AWS DEA-C01 exam — the single largest domain. It tests your ability to design, build, and optimize data ingestion pipelines (both batch and streaming), apply transformations at scale, and orchestrate complex workflows. Expect questions on selecting the right AWS service for a given requirement, understanding service limits and defaults, and troubleshooting pipeline failures. Scenario-based questions dominate: you will be given a business constraint (latency, cost, throughput, ordering) and asked to choose and configure the correct combination of AWS services.


AWS Glue

AWS Glue is a fully managed serverless ETL service. It has several distinct components the exam tests separately.

Glue Crawlers

A crawler scans data stores (S3, JDBC, DynamoDB) and automatically infers schema, creating or updating tables in the Glue Data Catalog. Crawlers use classifiers to determine format. Default behavior: a crawler creates one table per S3 folder (prefix). Crawlers can be scheduled or triggered on demand.

  • Partition detection: Crawlers recognize Hive-style partitions (year=2024/month=01/) and add them as partition keys in the catalog.
  • Incremental crawls: Only crawl new/changed files using the "crawl new folders only" setting.

Glue Data Catalog

The Data Catalog is a central metadata repository — a managed Apache Hive Metastore compatible with Athena, EMR, and Redshift Spectrum. Each AWS account has one Data Catalog per region. It stores databases, tables, partitions, and connections.

Glue Jobs

Glue Jobs execute ETL scripts in Apache Spark (Python/Scala) or Python shell. Three job types:

Job TypeUse CaseMax DPUsNotes
SparkLarge-scale transformations100 (default)Distributed, best for >1 GB
Spark StreamingMicro-batch from Kinesis/Kafka100Continuous job type
Python ShellLightweight scripts, single node1 or 0.0625No Spark overhead

DPU (Data Processing Unit): 4 vCPUs + 16 GB RAM. Default Spark job = 10 DPUs. You pay per second (minimum 1 minute).

Job bookmarks: Track processed data to avoid reprocessing. Works for S3 and JDBC sources. Enable per-job.

Glue Studio and DataBrew

FeatureGlue StudioGlue DataBrew
InterfaceVisual drag-and-drop ETL graphVisual data preparation (no-code)
Target userDevelopersAnalysts / data stewards
OutputGlue job (Spark)Recipes applied to datasets
ProfilingNoYes — data quality statistics
Schema changesManual node configAutomatic via recipes

Common traps

  • Crawlers do not automatically update partition metadata after new data lands — use MSCK REPAIR TABLE in Athena or re-run the crawler, or use Glue partition indexing.
  • Glue Job bookmarks track jobs, not crawlers.
  • Python Shell jobs cannot use Glue's DynamicFrames — only DataFrames.
  • Glue DataBrew does not run Spark — it's a separate profiling/recipe service; don't confuse it with a Glue job.
  • Glue catalog is regional — cross-region access requires catalog federation or resource-based policies.

Worked scenario: A data team needs non-technical analysts to clean and normalize a CSV dataset in S3 without writing code, then output to Parquet. → Glue DataBrew (visual recipes, no-code, supports Parquet output). Not Glue Studio (requires understanding ETL nodes).


Amazon Kinesis Data Streams

Amazon Kinesis Data Streams (KDS) provides real-time, durable streaming with configurable retention and shard-based throughput.

Shards and Throughput

  • 1 shard = 1 MB/s write, 2 MB/s read (shared across all standard consumers on that shard — not per consumer)
  • Enhanced Fan-Out (EFO): Each registered consumer gets 2 MB/s per shard via HTTP/2 push — independent of other consumers. Reduces latency to ~70 ms vs ~200 ms for standard polling.
  • Partition key: Determines which shard a record goes to (MD5 hash). Use high-cardinality keys to avoid hot shards.

Retention and Limits

ParameterDefaultMaximum
Retention24 hours365 days
Record size—1 MB
PutRecord TPS per shard1,000 records/s—
GetRecords per shard (standard)5 reads/s—

On-demand mode: Auto-scales shards; no capacity planning. Scales up to 200 MB/s write, 400 MB/s read. Billed per GB ingested/retrieved — more expensive at steady high throughput. Provisioned mode: Manual shard management, cheaper at predictable load.

Common traps

  • ProvisionedThroughputExceededException on reads in standard mode often means too many consumers — fix with EFO, not adding shards.
  • Increasing shards does not automatically increase consumer read throughput if they are polling the same shard (standard mode limit is shared across all standard consumers on that shard).
  • Sequence numbers guarantee ordering per shard, not across shards.
  • Resharding (splitting/merging) is not instantaneous — parent shards remain readable until their data expires.

Sign in free to read the full guide

13 more sections (about 2,919 words) continue below. The first domain's study guide is free for every DEA-C01 learner with a free account.