An application ingests data from an Amazon Kinesis data stream. The shards in the data stream are set for normal traffic. During tests for peak traffic, the application ingests data slowly. A…

Question

Options

• AInstall the Kinesis Producer Library (KPL) to ingest data into the data stream.
• BSwitch to on-demand capacity mode for the data stream. Specify a partition key when writing data
• CDecrease the amount of time that data is kept in the data stream by using the
• DIncrease the shard count in the data stream by using the UpdateShardCount API operation.

• A
  8% (3)
• B
  3% (1)
• C
  5% (2)
• D
  85% (33)

Explanation

Increasing the shard count via UpdateShardCount directly scales throughput capacity - each shard provides 1 MB/s write and 2 MB/s read, so matching shard count to known peak load is the most targeted and cost-predictable fix.

Why the distractors are wrong:

• A (KPL): The Kinesis Producer Library improves write efficiency through batching and compression, but it cannot overcome a hard shard throughput ceiling - it won't help if the stream itself is undersized.
• B (On-demand mode): On-demand does auto-scale, but it charges per GB ingested/retrieved, making it more expensive than provisioned shards when peak traffic volume is already known from testing.
• C (Decrease retention): Retention period controls how long data stays in the stream, not how fast it can be ingested - this has zero effect on throughput capacity.

Memory tip: Think of shards as lanes on a highway - if traffic is slow, you add lanes (UpdateShardCount), not a fancier car (KPL) or a toll-by-mile system (on-demand). When peak load is predictable, provisioned shards beat on-demand on cost.

No community discussion yet for this question.