DEA-C01 Data Operations and Support Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Reduce the number of Kinesis shards to lower the ingestion rate.

  Why it's wrong here

  Fewer shards reduce Lambda invocation concurrency, lowering the write rate but also discarding the parallelism needed to drain the stream, and shard reduction cannot be done without resharding. It is tempting because throttling stems from too many concurrent writes, yet reducing shards risks data loss and backlog.

• ✗

  Increase the DynamoDB table's read capacity.

  Why it's wrong here

  ProvisionedThroughputExceededException arises from writes, so read capacity is irrelevant; the table's write capacity must be raised or on-demand mode enabled. It is tempting because capacity errors often stem from reads, and increasing read capacity is correct when throttling occurs on GetItem or Query operations.

• ✓

  Configure a dead-letter queue (DLQ) on the Lambda function and increase the DynamoDB write capacity.

  Why this is correct

  The DLQ captures failed records so Kinesis retries do not discard them, while raising DynamoDB write capacity removes the throttling that triggers ProvisionedThroughputExceededException. Together they satisfy the no-data-loss constraint, though the DLQ alone would not fix the underlying capacity shortfall.

• ✗

  Disable retries on the Lambda function to avoid throttling.

  Why it's wrong here

  Disabling retries converts throttled writes into dropped records, directly violating the no-data-loss requirement; retries with backoff let Lambda absorb throttling. It is tempting because retries amplify pressure on an already-throttled table, and disabling them is correct only when duplicates or poison-pill records, not capacity, are the problem.

Go deeper

Related to this question