DEA-C01 Data Ingestion and Transformation Practice Question

A data engineer is building a streaming ingestion pipeline using Amazon Kinesis Data Streams. The producer application writes records with an explicit partition key derived from the device ID, and there are approximately 2,000 active devices. The engineer needs to ensure that records for the same device are processed in order by a downstream consumer. Which configuration should the engineer verify to guarantee per-device ordering?

⚠ Common exam trap

The trap here is assuming that any stream-level feature such as enhanced fan-out or extended retention can enforce ordering, when ordering in Kinesis Data Streams is strictly a per-shard property driven by the partition key.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Confirm that the partition key is stable per device so records map to the same shard.

Kinesis Data Streams guarantees ordering only within an individual shard. Because the partition key is hashed to select a shard, any record sharing the same partition key is consistently routed to the same shard. Keeping the device identifier as the partition key ensures all records for a device are serialized in one shard, delivering the required per-device ordering without sacrificing horizontal scale across the fleet.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Confirm that the partition key is stable per device so records map to the same shard.
Why this is correct
Kinesis Data Streams preserves order within a shard, and records with the same partition key are consistently routed to the same shard via the MD5 hash of the key. By keeping the partition key stable per device, all records from a given device land in the same shard and are delivered in order, satisfying the requirement while retaining parallelism across shards.
✗
Increase the stream's retention period to 365 days to preserve ordering.
Why it's wrong here
Retention controls how long records remain readable, ranging from 24 hours up to 365 days. It has no bearing on the order in which records are written or routed to shards. Extending retention adds replay capability but does nothing to enforce per-device ordering, so it does not satisfy the requirement.
✗
Ensure all records use the same partition key so they land in a single shard.
Why it's wrong here
Using a single partition key forces every record into one shard, which serializes all 2,000 devices through a single throughput unit and destroys parallelism. Ordering is preserved per shard, but the design collapses scalability and will throttle once the shard's 1 MB/s or 1,000 records/s limit is exceeded, making it unsuitable for the scenario.
✗
Enable enhanced fan-out on the stream so each consumer gets a dedicated read throughput.
Why it's wrong here
Enhanced fan-out provides dedicated 2 MB/s read throughput per consumer per shard and reduces latency, but it does not affect how records are distributed across shards. Ordering is a function of shard routing via the partition key, so enhanced fan-out alone cannot guarantee that records for the same device arrive in sequence.

Go deeper

DEA-C01 Data Ingestion and Transformation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question