A developer is building an application that processes a stream of user-supplied data. The data stream must be consumed by multiple Amazon EC2 based processing applications in parallel and in real time

Question

Options

• APublish the data to Amazon Simple Queue Service (Amazon SQS).
• BPublish the data to Amazon Data Firehose.
• CPublish the data to Amazon EventBridge.
• DPublish the data to Amazon Kinesis Data Streams.

• A
  4% (1)
• B
  8% (2)
• C
  4% (1)
• D
  83% (20)

Explanation

Amazon Kinesis Data Streams is the right choice because it's purpose-built for real-time, parallel data consumption - multiple EC2 consumers (called "shard consumers") can each read the same stream independently using their own shard iterators, and each consumer tracks its own position (sequence number), so it can resume exactly where it left off after an interruption without data loss or duplication.

Why the distractors are wrong:

• A (SQS): SQS messages are deleted once consumed by one consumer - parallel consumers would compete for the same messages rather than each receiving a full copy, making true parallel processing impossible without duplicating data.
• B (Firehose): Firehose is a delivery service that loads data into destinations like S3 or Redshift; it's not designed for real-time consumption by custom EC2 processing applications.
• C (EventBridge): EventBridge is an event bus for routing events between AWS services based on rules; it lacks the durable, replayable stream semantics needed for parallel consumers that must resume after interruption.

Memory tip: Think of Kinesis like a conveyor belt in a factory - multiple workers (consumers) can each watch the belt from their own position and pick up items independently, and if a worker takes a break, they just return to their last position. SQS is more like a shared bin where the first worker to grab an item removes it for everyone else.

No community discussion yet for this question.