DEA-C01 — AWS Certified Data Engineer – Associate

Build the pipelines everything else runs on — ingest streams and batches, choose and model the store, orchestrate and monitor the whole line, and prove the data was governed from first byte to audit log.

65 questions · 50 scored · 130 min · scaled 100–1,000 · pass 720

Stage 21: Orient on the blueprint

What DEA-C01 actually asks, the four domains and their weights, and the service map a data engineer is expected to navigate without hesitating.

  • The DEA-C01 Exam: Blueprint, Logistics, Strategy — What the exam is actually testing and how it is built: the four content domains and what each one weighs, the kinds of judgement an associate-level data engineering question rewards, and the 50-scored-of-65 question split that changes how you pace yourself.
  • The Data Service Map — The whole in-scope estate laid out as one pipeline so later lessons have somewhere to land: what ingests, what transforms, what stores, what catalogs, what queries, what orchestrates, and what governs — and the handful of services that appear in all four domains.

Stage 22: Get the data in

Streaming and batch ingestion, the throughput and ordering decisions behind each, and the replay story when a consumer falls behind.

  • Ingestion Patterns — The first decision in any pipeline: streaming or batch, and what each commits you to. Throughput and latency targets, bounded versus unbounded data, replayability, the cost of getting it wrong in both directions, and the AWS service that matches each shape.
  • Streaming at Scale — Kinesis Data Streams, Managed Service for Apache Kafka, and Firehose as three different bargains: who owns the shard or partition, how ordering is guaranteed and at what granularity, what happens when a consumer falls behind, and when a fully managed delivery stream is the right answer instead.

Stage 23: Shape it and orchestrate it

Glue, Spark and EMR for transformation; Step Functions, MWAA and EventBridge for the schedule; and the programming idioms the exam puts on screen.

  • Transformation Engines — Glue, EMR, and the Spark underneath both: where a Glue job beats a cluster and where it does not, DPUs and executors as the same idea priced differently, the file-size and partition problems that dominate real pipeline cost, and why a slow job is usually a shuffle rather than a CPU.
  • Orchestrating the Pipeline — Turning a set of jobs into a dependable line: Step Functions, Managed Workflows for Apache Airflow, EventBridge and Glue workflows compared on the axes that actually decide between them — dependency complexity, failure semantics, retry and idempotency, cost at idle, and who maintains the DAG.
  • Programming Concepts on the Exam — Task statement 1.4, which readers under-prepare because it looks like a coding question and is not. SQL that the exam expects you to read, infrastructure as code, Git flow and CI/CD for pipelines, the SDK patterns that appear in stems, and optimising a query by reading its plan.

Stage 24: Decide where it lives

Choosing the store against the access pattern, cataloging it so it can be found, moving it through its lifecycle, and evolving a schema without breaking readers.

  • Choosing a Data Store — The decision the exam asks most often. Access pattern before product: S3 and the lake, Redshift and the warehouse, DynamoDB for key-value at scale, RDS and Aurora for relational workloads, and the specialised stores — with the constraints (latency, query shape, cardinality, cost at rest) that eliminate the wrong three.
  • Cataloging and Discovery — Data nobody can find is data nobody uses. The Glue Data Catalog as the shared metadata layer, crawlers and classifiers and where they get schema wrong, partition indexes and why a query gets slower as the table grows, Lake Formation as the permissions layer over the catalog, and DataZone for discovery across teams.
  • Lifecycle and Tiering — Moving data through its useful life without a script: S3 storage classes and the retrieval bargain each one strikes, lifecycle configuration and the traps in transition rules, Intelligent-Tiering versus explicit policy, Redshift and DynamoDB retention mechanics, and backup and recovery as a design input rather than an afterthought.
  • Data Modeling and Schema Evolution — Designing a model that survives contact with change: star and snowflake schemas and when normalising costs more than it saves, DynamoDB single-table design driven by access patterns, the open table formats (Iceberg, Hudi, Delta Lake) and what they actually buy, and evolving a schema without breaking every reader downstream.

Stage 25: Run the line

Automating the pipeline, querying it with Athena and Redshift, watching it with CloudWatch and lineage, and proving the data is fit to use.

  • Automating Data Processing — Making the line run without a human in it: scheduling and event triggers, Lambda inside a data pipeline and the places it does not belong, Glue job bookmarks and incremental processing, concurrency and the quota ceilings you meet at scale, and the automation that handles its own failures.
  • Analyzing Data — Getting answers out: Athena over the lake and what makes a query cheap or ruinous, Redshift Spectrum and the federated query story, materialised views and result caching, OpenSearch for search and log analytics, and QuickSight as the consumer whose needs shape everything upstream.
  • Maintaining and Monitoring — Knowing the pipeline broke before the business tells you: CloudWatch metrics, logs and alarms for data services, the Glue and EMR observability surfaces, lineage and traceability, cost monitoring as an operational signal, and the troubleshooting order that finds a cause instead of a symptom.
  • Ensuring Data Quality — The task statement with the least obvious service answer, because quality is a design problem first. The failure modes that reach production, completeness and consistency and freshness as measurable things, Glue Data Quality and Deequ, where a quality gate belongs in the line, and what to do when bad data has already landed.

Stage 26: Govern it, then walk in ready

Authentication and authorization over data, encryption and masking, audit-ready logs and privacy duties — then question anatomy and the full mock in the Exam Hall.

  • Authentication and Authorization over Data — Who you are and what you may touch, at data granularity. IAM roles and role chaining for pipelines, IAM Identity Center for human access, Lake Formation permissions down to column and row, Redshift and Athena access models, and the resource policies that catch people out on cross-account reads.
  • Encryption and Masking — Protecting the data itself: encryption at rest across S3, Redshift, DynamoDB and RDS, encryption in transit and where it is not automatic, KMS keys and who can use them, and the masking and tokenisation choices — dynamic masking, column-level redaction, and detecting sensitive data before it spreads.
  • Audit Logs and Privacy — Proving it afterwards. CloudTrail management and data events over data stores, the service-native logs that answer questions CloudTrail cannot, centralising and querying logs for an audit, and the privacy duties — residency, retention, deletion requests, and lineage as evidence — that turn governance from a policy document into a pipeline requirement.
  • Walk In Ready — The capstone: reading a question for the constraint that actually decides it, the keyword reflexes that map a stem to a service, the traps that sink competent engineers, and a final-week plan that ends with the full mock.