AWS Data Engineer Associate (DEA-C01) Practice Test

This practice set follows the AWS Certified Data Engineer – Associate blueprint: ingest and transform (Kinesis, MSK, Glue, EMR), data stores (S3 layout, Redshift, DynamoDB), operations (CloudWatch, Step Functions, EventBridge), and security/governance (Lake Formation, KMS, IAM trust policies).

Questions are scenario-based: partition design that will not explode the Glue catalog, Lambda vs Glue vs EMR for a given job size, when Redshift Serverless is the wrong warehouse, and how to grant cross-account lake access without opening the bucket to the world.

Read alongside the AWS tutorials, cost and SQL tools, and interview prep. Start the interactive quiz on this page for instant feedback.

Not affiliated with Amazon Web Services. Verify current exam guide, domains, and pricing on AWS Training and Certification.

Sample questions with explanations

The items below are from this bank so a reader (and an ads crawler) can study real stems without running JavaScript. The interactive quiz on this page has the full set, timed exam mode, and per-topic scoring.

1. A clickstream pipeline produces ~30 MB/s of JSON events. The downstream team wants events landed in S3 as Parquet partitioned by event date with at least 1-minute freshness, and they need exactly-one delivery to a Redshift staging table. The engineering team wants the lowest-ops solution. Which design best meets all requirements?

Why: Kinesis Data Streams (KDS) gives durable, replayable, per-shard ordered storage of the raw events. Kinesis Data Firehose can consume directly from a KDS stream, perform dynamic partitioning on `eventDate`, convert JSON to Parquet via Glue Data Catalog, and deliver to S3 with ~60s buffering — matching the 1-minute freshness goal with no servers to manage. Firehose's Redshift delivery mode uses S3 as an intermediate store and issues a `COPY` with a manifest, and Firehose tracks delivery offsets so duplicates are deduplicated on retries — giving effectively exactly-once into the staging table while remaining fully managed. b wrong: producing straight to Firehose loses the replayable stream. More importantly, a Lambda-per-object `COPY` provides no exactly-once guarantee — a Lambda retry or concurrent invocation can re-COPY the same manifest, causing duplicates unless you build your own idempotency layer. c wrong: MSK + self-managed Kafka Connect is significantly higher ops than KDS+Firehose for this volume, and a Glue MERGE every minute is fine for upserts but overkill and more expensive than Firehose's native Redshift delivery for append-only staging. d wrong: a custom KCL consumer on EC2 reintroduces the server fleet the team wanted to avoid, and issuing Redshift `INSERT` statements per record is an anti-pattern — Redshift is columnar and requires `COPY` for bulk loads to avoid leader-node bottlenecks.

2. An AWS Glue Spark job reads daily CSV uploads from `s3://raw/orders/` and writes Parquet to `s3://curated/orders/`. Each run currently reprocesses every file in the prefix, which is slow and expensive. You want only new files processed on each run with minimal code change. Which approach is the best fit?

Why: Glue job bookmarks are specifically designed for this use case: Glue persists per-source state (S3 object keys already processed, or last-committed JDBC value) keyed by `transformation_ctx`. When bookmarks are enabled and you read via `from_catalog` or `from_options` with a `transformation_ctx`, Glue automatically skips previously processed objects and calls `job.commit()` persists the new high-water mark. This is a one-line change per source. b wrong: a file-shuffling pattern works but is brittle — it requires a separate Lambda, adds failure modes (partial moves), and couples your ingestion to an S3 side effect. It's more moving parts than bookmarks, not fewer. c wrong: a Python shell job is single-node and not appropriate for Spark-scale CSV-to-Parquet conversion. A 24h window is also not equivalent to bookmarks — it re-reads everything inside the window and misses late-arriving files outside it. d wrong: filtering on `ingest_date` only works if the column exists in the data and is trustworthy, and it still requires Spark to read every file to apply the filter — partition pruning happens at the Hive partition level, not the column level of the DataFrame after load.

3. A Redshift cluster has a `fact_orders` table (2B rows) joined to `dim_customer` (80M rows) on `customer_id`. The query planner shows DS_BCAST_INNER on `dim_customer` and queries take 40+ minutes. Distribution and sort keys are currently `DISTSTYLE EVEN` on both tables. Which change will most improve join performance?

Why: A co-located join requires both tables to be distributed on the join key so matching rows live on the same compute slice. Setting `DISTKEY(customer_id)` on both sides lets Redshift do a local hash join per slice with no network shuffle, changing the plan from `DS_BCAST_INNER` (broadcast the inner table to every slice) to `DS_DIST_NONE`. For a 2B-row fact joined to an 80M-row dim, that's typically a 10x+ speedup. b wrong: `DISTSTYLE ALL` replicates the entire table to every node. On a 2B-row fact that's prohibitive on storage and write cost. `ALL` is appropriate for small, slowly-changing dims (think <5M rows), not fact tables. c wrong: distributing the fact on `order_id` and leaving the dim on `EVEN` doesn't co-locate the join keys, so Redshift still has to redistribute or broadcast one side. The broadcast cost is unchanged. d wrong: bigger nodes don't eliminate the O(N) network cost of broadcasting 80M rows to every slice on every query. The fix is a distribution choice, not a hardware choice.

4. You must orchestrate a nightly pipeline with 6 Glue jobs, 2 Lambda transforms, an EMR step, and a final Redshift `COPY`, with per-step retries and email alerts on failure. The team has no Airflow experience and wants the lowest operational overhead and predictable cost. Which orchestrator best fits?

Why: Step Functions Standard Workflows are the native AWS orchestrator and the right choice here: (1) first-class service integrations for Glue `StartJobRun.sync`, Lambda, EMR steps, and the Redshift Data API mean no custom polling code; (2) per-state `Retry` and `Catch` blocks handle retries and failure routing declaratively; (3) failure branches to SNS for email alerting is one state; (4) Standard is priced per state transition and is cheap for nightly batch at this scale; (5) no infrastructure to manage, unlike MWAA which has an always-on environment cost. b wrong: MWAA is powerful but introduces a ~$300+/month minimum environment cost and an Airflow learning curve the team doesn't have. For a single nightly DAG of this size it's over-provisioned. c wrong: a single Lambda orchestrating long-running services hits the 15-minute Lambda timeout the moment EMR or Glue takes longer, and you lose per-step observability. Manual try/except is a poor substitute for declarative retries. d wrong: Express Workflows have a 5-minute maximum duration and are designed for high-volume short-lived workflows (e.g., per-request orchestration), not nightly batch that runs for 30+ minutes. Activity workers also require self-hosted pollers, raising ops.

5. A data lake on S3 is cataloged in Glue. The security team requires: analysts can query only non-PII columns of `customers` (exclude `ssn`, `email`), and only rows where `region = 'EU'`. They must enforce this across Athena, Redshift Spectrum, and EMR Spark. Which combination of actions correctly implements this? (Select all that apply.)

Why: Lake Formation is the only AWS-native way to enforce column- and row-level access uniformly across Athena, Redshift Spectrum, and EMR Spark. (a) Column-level SELECT grants (or, equivalently, LF `DataFilters` that exclude columns) are the standard mechanism to hide `ssn` and `email`. (b) A LF row-level data filter with `region = 'EU'` is applied automatically by every LF-integrated engine — analysts querying via Athena or Spectrum see only EU rows without any client-side predicate. (d) Enforcement in EMR Spark requires using the EMR Lake Formation integration (runtime roles on EMR on EC2, or EMR Serverless with LF) — without this, Spark bypasses LF and reads S3 directly with the cluster's IAM role. c wrong: S3 bucket policies operate at the object level, not the column or row level. You cannot express "deny this column" or "deny rows where region<>'EU'" with an S3 policy — Parquet files contain both PII and non-PII columns in the same object. e wrong: Athena workgroups have per-workgroup settings (result location, encryption, engine version, cost controls) but do not provide a column-masking "query result filter." Even if you post-process results in a proxy, that doesn't stop Redshift Spectrum or EMR from reading the raw columns.

6. A Kinesis Data Stream in provisioned mode has 4 shards. Producers are throttled with ProvisionedThroughputExceededException. Which per-shard write limit are they hitting FIRST?

Why: a correct: Each shard in provisioned Kinesis Data Streams supports 1 MB/s OR 1,000 records/s on ingress (whichever hits first). Once either limit is reached the producer gets `ProvisionedThroughputExceededException` and must retry or scale out shards. b wrong: 2 MB/s and 5 GetRecords/s are the read-side limits per shard, not writes. c wrong: Those numbers don't match any Kinesis limit. d wrong: Kinesis always has per-shard limits; use on-demand mode or add shards to increase capacity.

7. Traffic on a Kinesis Data Stream is bursty and unpredictable. Which capacity mode minimizes operational overhead?

Why: b correct: On-demand mode scales capacity automatically up to 200 MiB/s (writes) without manual shard management - ideal for unknown or spiky traffic. You pay per GB and per request. a wrong: Provisioned requires predicting shard counts and rescaling manually. c wrong: Enhanced fan-out is a consumer feature, not a write-side scaler. d wrong: Firehose is a delivery pipeline, not a durable stream for application consumers.

8. Kinesis Data Firehose is delivering JSON events to S3. You need files partitioned by `customer_id` and `yyyy-MM-dd` from `event_time` inside the payload. Which feature enables this WITHOUT a Lambda transform?

Why: b correct: Firehose Dynamic Partitioning lets you declare keys via inline parsing (JQ for JSON) so records are written to prefixes like `customer_id=X/dt=2026-04-26/`. Combine with record format conversion to Parquet for query-ready Hive-style partitioning. a wrong: S3 bucket keys optimize KMS; unrelated to partitioning. c wrong: Retry handles failures, not partitioning. d wrong: S3 Object Lambda rewrites objects on GET; adds latency and cost for ingestion.

This preview is 8 of 100 questions. Use the quiz UI on this page to attempt the rest.

← Back to Home