Handling Large Data with DynamoDB and S3 | SAA-C03

SAA-C03 By islever Editorial Last updated

Determine appropriate data security controls.

Short answer

B Store large data objects in Amazon S3 and save the S3 URL as an attribute in the DynamoDB table.

Question

A company’s application is receiving data from multiple data sources. The size of the data varies and is expected to increase over time. The current maximum size is 700 KB. The data volume and data size continue to grow as more data sources are added. The company decides to use Amazon DynamoDB as the primary database for the application. A solutions architect needs to identify a solution that handles the large data sizes. Which solution will meet these requirements in the MOST operationally efficient way?
  1. Create an AWS Lambda function to filter the data that exceeds DynamoDB item size limits. Store the larger data in an Amazon DocumentDB (with MongoDB compatibility) database.
  2. Store the large data as objects in an Amazon S3 bucket. In a DynamoDB table, create an item that has an attribute that points to the S3 URL of the data. Correct Answer
  3. Split all incoming large data into a collection of items that have the same partition key. Write the data to a DynamoDB table in a single operation by using the BatchWriteItem API operation.
  4. Create an AWS Lambda function that uses gzip compression to compress the large objects as they are written to a DynamoDB table.

Key Takeaways

The question tests knowledge of DynamoDB's 400 KB item size limit and the operational efficiency of offloading large payloads to Amazon S3.

This page explains the AWS best practice for storing large binary objects while using Amazon DynamoDB as the primary metadata store, identifying Option B as the correct solution.

Common mistake: Candidates often choose compression (Option D) or sharding (Option C), failing to realize that neither guarantees compliance with the hard 400 KB limit or offers the same operational simplicity as S3.

Expert Analysis

Why the Answer Is Correct

Amazon DynamoDB enforces a strict maximum item size of 400 KB. Since the application data exceeds this limit, storing it directly in DynamoDB is impossible regardless of compression or splitting strategies. Storing the large data objects in Amazon S3 and keeping only the S3 object key (URL) in a DynamoDB attribute is the standard AWS-recommended pattern for handling large items. This approach decouples storage from compute, is highly scalable, and requires minimal management overhead, satisfying the 'most operationally efficient' requirement.

Why the Other Options Are Wrong

Option A introduces DocumentDB, adding unnecessary complexity and cost when S3 is sufficient for unstructured data. Option C attempts to split data into multiple items; however, DynamoDB reads are limited by the 1 MB response size constraint per request, making retrieval complex and inefficient. Option D suggests compression via Lambda, but gzip does not guarantee the payload will shrink below 400 KB, leading to potential write failures.

Community Comment Notes

Community consensus strongly supports Option B. Users note that introducing another database like DocumentDB is over-engineering (as noted by LeonSauveterre). Others highlight that compression doesn't solve the hard limit issue (Scheldon). The general agreement is that S3 + DynamoDB pointer is the canonical architecture for this scenario.

Official Reference

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-use-s3-too.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

Always check the service limits first. For DynamoDB, remember the 400 KB item limit. If data exceeds this, immediately consider S3 for the blob and DynamoDB for the metadata/index.

Frequently Asked Questions

Why can't we just compress the data with Lambda?

Compression is variable; it may not reduce the data enough to fit under the 400 KB hard limit, causing write failures.

Is DocumentDB better than S3 for this?

No, S3 is more cost-effective and operationally simpler for large binary objects. DocumentDB adds unnecessary management overhead.

More SAA-C03 FAQ →

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 5 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 5

  1. Neung983 👍 9 Answered B
    option B is the most operationally efficient solution for handling large data sizes in Amazon DynamoDB.
  2. Sergiuss95 👍 2 Answered B
    https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-use-s3-too.html
  3. Scheldon 👍 1 Answered B
    AnswerB Compresion of data in DynamoDB is a good idea especially for text data link from forum, but to do that we do not need AWS Lambda if I'm not wrong. In other head Storing big object on S3 and seving URL to it in DynamoDB is one of best practices mentioned by Amazon. Hence we do not know what kind of data we are storing in DB and how big objects will be in the future option B looks like the best solution. https://aws.amazon.com/blogs/database/large-object-storage-strategies-for-amazon-dynamodb/ <<<< Read Option 2 https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-use-s3-too.html
  4. LeonSauveterre 👍 1 Answered B
    A - Introducing another database. No need. B - Decoupling the large data storage (S3) from the metadata or smaller structured data (DynamoDB) is an AWS-recommended pattern. C - OK but this is too complicated. D - Compression does not guarantee that the data will always fit within DynamoDB's 400 KB limit.
  5. seetpt 👍 5 Answered B
    B is correct

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Most Cost-Effective 7-Year Retention for EBS Snapshots?

S-grade

AWS Forecast vs SageMaker for Time-Series Prediction

S-grade

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide