Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in how to efficiently separate searchable metadata from large binary objects for fast, scalable API access. In production, this is about knowing exactly which AWS services to combine to balance API performance and storage practicality. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
TechNova Solutions is modernizing its internal legacy apps by migrating to AWS. The team is tasked to rebuild the internal employee directory application. This application needs to store and retrieve employee contact details and high-resolution profile photos using native AWS APIs with low latency and scalability.
The Requirement: #
Design a solution that allows the application to search for and retrieve individual employee contact data along with their associated high-resolution photos efficiently and with minimal operational overhead.
The Options #
- A) Encode the entire employee contact info and photos in Base64, then store these records with a sort key in an Amazon DynamoDB table.
- B) Store all employee contact information in an Amazon DynamoDB table, referencing photo object keys that are stored separately in Amazon S3.
- C) Use Amazon Cognito user pools to manage the employee directory as a fully managed SaaS solution.
- D) Save employee contact details in an Amazon RDS database and store the photos on an Amazon Elastic File System (EFS) mount.
Google adsense #
leave a comment:
Correct Answer #
B
Quick Insight: The Developer Imperative #
- The best design divides metadata and large objects, using DynamoDB for low-latency queries on contacts and S3 for scalable, cost-effective storage of large photos.
- Embedding photos as Base64 in DynamoDB (Option A) leads to inefficient, costly storage and query performance issues.
- Cognito (Option C) is for authentication and user management, not for storing arbitrary directory data.
- RDS + EFS (Option D) adds operational complexity and lacks the scalability and API integration benefits of DynamoDB plus S3.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option B
The Winning Logic #
This solution leverages a proven pattern: store structured, queryable metadata (employee contact info) in DynamoDB for fast, indexed retrieval. High-resolution photos, which are large binary files, reside efficiently in S3. The DynamoDB records only hold S3 object keys, enabling the application to retrieve contact data and then fetch photos via standard S3 GET operations. This separation optimizes cost, performance, and API integration.
- DynamoDB excels at handling low latency, key-value, and query access for structured data.
- S3 is designed for scalable, durable storage of large media assets accessed via object keys.
- This approach simplifies API calls — first querying DynamoDB, then S3 — using AWS SDKs such as
GetItemandGetObject.
The Trap (Distractor Analysis): #
- Option A: Storing photos as Base64 in DynamoDB bloats item size and causes high read/write costs and latency, as DynamoDB has a 400 KB item size limit and inefficient large blob handling.
- Option C: Cognito User Pools are authentication providers, not meant for storing arbitrary employee directory data or large files.
- Option D: Using RDS plus EFS adds operational overhead (database maintenance, EFS mounts) and lacks the native API efficiency of DynamoDB and S3 combination for serverless or microservices architectures.
The Technical Blueprint #
# Example AWS CLI commands used in this pattern:
# Put employee contact item in DynamoDB, with S3 photo key as attribute
aws dynamodb put-item --table-name EmployeeDirectory \
--item '{"EmployeeId": {"S": "1234"}, "Name": {"S": "John Doe"}, "PhotoKey": {"S": "photos/1234.jpg"}}'
# Retrieve photo from S3 using key stored in DynamoDB
aws s3api get-object --bucket employee-photos-bucket --key photos/1234.jpg /tmp/johndoe.jpg
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low (single service) | Poor, large item sizes | Not suitable for large images |
| B | Moderate (Dynamo + S3) | High, optimized for queries | Best for scalable metadata + large files |
| C | High (Cognito APIs) | Not for custom data storage | User auth, not directory data |
| D | High (RDS + EFS) | Moderate, but operationally heavy | Traditional app lift-and-shift |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick S3 + DynamoDB when you see storage of metadata plus large files needing API-based retrieval.
Real World #
In reality, developers often use Amazon S3 for large media assets and DynamoDB for fast access to associated metadata, improving scalability, cost efficiency, and ease of development with native AWS SDKs.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.