SAA-C03 Design Resilient Architectures 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.

• ✗

  Enable server-side encryption on the stream and increase the retention period to 365 days.

  Why it's wrong here

  Encryption protects data at rest and retention controls how long records remain accessible, but neither affects ingest throughput limits. The exceptions occur because the four shards cannot absorb the peak write rate, and these settings leave the shard count unchanged, so the bottleneck remains exactly where it was.

• ✗

  Switch the consumers to enhanced fan-out and raise the number of registered consumers.

  Why it's wrong here

  Enhanced fan-out gives each consumer a dedicated 2 MiB per second read throughput pipe, which helps lagging consumers but does nothing for the producer-side ProvisionedThroughputExceededException. Write capacity is governed by shard count, so the ingestion errors would persist even with dedicated consumer throughput.

• ✗

  Replace the Kinesis Data Stream with an Amazon SQS FIFO queue and have consumers poll it.

  Why it's wrong here

  This forces producer and consumer code changes, violating the stated constraint, and SQS FIFO throughput is bounded by message group and batch limits that may not match the ingest profile. It also abandons Kinesis semantics such as multiple consumers reading the same record and configurable retention, so it is not the appropriate remedy.

• ✓

  Increase the number of open shards using UpdateShardCount to a higher count.

  Why this is correct

  UpdateShardCount increases the shard count by splitting existing shards, which raises the stream's write and read capacity. Records with the same partition key continue to map to a single shard, preserving order for that key. Producers need no code change because they keep writing with the same partition key to the same stream name.

Go deeper

Related to this question