(B) If you delay the batch operation using exponential backoff, the individual requests in the batch are much more likely to succeed. (D) The most likely cause of a failed read or a failed write is throttling. For BatchGetItem, one or more of the tables in the batch request does not have enough provisioned read capacity to support the operation https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.RetryAndBackoff

B & C https://docs.aws.amazon.com/general/latest/gr/api-retries.html

BC is the correct answer.

https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BatchGetItem.html https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.RetryAndBackoff

BC is the correct answer.

among B C D, it is hard to say D copes with the problem directly I guess. Increasing RCU will affects the ratio of unprocessed items but that does not mean it handles the unprocessed items.

B,D. La combinación de estrategias es ideal para este comportamiento

B,D is correct

the aws documentation for unprocessedkeys reads: "If DynamoDB returns any unprocessed items, you should retry the batch operation on those items. However, we strongly recommend that you use an exponential backoff algorithm. If you retry the batch operation immediately, the underlying read or write requests can still fail due to throttling on the individual tables. If you delay the batch operation using exponential backoff, the individual requests in the batch are much more likely to succeed." Therefore I am taking the two options that provide this functionality. https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BatchGetItem.html

B & D is correct

According to AWS docs, the answer is B and D

Exponential backoff with randomized delay is a common technique used to handle transient failures and throttle errors in distributed systems like DynamoDB. This approach involves retrying the failed operation after waiting for an increasing amount of time, which helps reduce the load on the service and increases the likelihood of success during periods of high demand or throttling. If the BatchGetItem operation frequently returns values in the UnprocessedKeys element, it indicates that the table's read capacity might be insufficient to handle the requested workload. By increasing the provisioned read capacity for the DynamoDB tables, the application can better handle the read throughput requirements and reduce the likelihood of encountering UnprocessedKeys in batch responses. AWS SDK might provide additional features and simplifications for making requests, it does not directly address the issue of UnprocessedKeys in batch responses. This option might be beneficial for improving code maintainability and leveraging SDK features however.

BC ...No discussion

Why it's suggesting using SDK in the question from below link but not using C in this question? https://www.examtopics.com/discussions/amazon/view/96246-exam-aws-certified-developer-associate-topic-1-question-437/

Correct answer is B & D B- https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html#Programming.Errors.BatchOperations D - https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BatchGetItem.html

Retry with exponential backoff and randomized delay (Option B) helps prevent overwhelming the system with repeated immediate requests and increases the likelihood of successful retries during intermittent issues. Using an AWS SDK (Option C) can provide built-in features for handling transient errors and retries, making the application more resilient to issues like UnprocessedKeys in batch responses.

B & D. B is correct. Because in the question, it is mentioned that low-level API is being used.It means exponential backoff can be implemented manually. D is correct. Because there is a frequently keyword in the question. If UnprocessedKeys error occurs frequently, DynamoDB doesn't have enough capacity to process requests. So read capacity should be increased.