DVA-C02 Development with AWS Services Practice Question
A developer is building a real-time chat application using Amazon API Gateway WebSocket APIs and AWS Lambda. The application needs to send messages to connected clients. The developer notices that the 'connectionId' changes every time a client reconnects. How should the developer store the mapping between user identity and connectionId?
⚠ Common exam trap
Candidates often think of Amazon ElastiCache (Redis/Memcached) first for low-latency key-value storage. However, for serverless WebSocket applications, DynamoDB is the preferred choice because it is fully serverless, does not require VPC placement for the Lambda function (which ElastiCache typically does, increasing complexity and cold start times), and easily handles the rapid read/write patterns of connection mappings at a lower cost.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use Amazon DynamoDB to store the mapping, with user identity as the partition key and connectionId as an attribute.
Amazon DynamoDB is the recommended, fully managed, serverless key-value store for persisting WebSocket connection IDs in AWS. It offers single-digit millisecond latency, scales automatically, and integrates seamlessly with AWS Lambda without requiring VPC configuration (unlike Amazon ElastiCache, which typically requires a VPC, adding setup complexity and potential latency for Lambda functions).
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use Amazon ElastiCache to store the mapping in memory.
Why it's wrong here
Using Amazon ElastiCache for this mapping is problematic because it is an in-memory caching service, meaning data is not persistently stored. If an ElastiCache node fails, restarts, or is evicted, the critical user-to-connection ID mapping would be lost. This ephemeral nature would lead to service disruptions, requiring users to re-establish their connections and potentially losing messages, which is unacceptable for a real-time chat application requiring continuous availability and state persistence.
- ✓
Use Amazon DynamoDB to store the mapping, with user identity as the partition key and connectionId as an attribute.
Why this is correct
Amazon DynamoDB is an excellent choice for storing real-time chat application mappings due to its consistent single-digit millisecond latency at any scale. By using the user identity as the partition key, the application can efficiently retrieve the associated connectionId for message routing with high throughput. Its fully managed, highly available, and durable nature ensures the mapping data is always accessible and resilient to failures, making it ideal for critical, frequently accessed application state.
- ✗
Use Amazon RDS to store the mapping in a relational database.
Why it's wrong here
Amazon RDS, a relational database service, is generally not the optimal choice for high-volume, low-latency key-value lookups like a connection mapping. While persistent, it introduces higher operational overhead and typically exhibits greater latency compared to purpose-built NoSQL databases like DynamoDB for simple data retrieval. The overhead of managing connections, schema, and transactional integrity for this specific use case makes it less efficient and more costly than a NoSQL solution designed for rapid access to simple data structures.
- ✗
Use Amazon S3 to store the mapping as a JSON file.
Why it's wrong here
Amazon S3 is fundamentally an object storage service, optimized for storing large, immutable files and not designed for frequent, low-latency, transactional updates to small data records. Storing a dynamic user-to-connection mapping as a JSON file in S3 would necessitate reading the entire file, modifying it, and then rewriting it for every connection establishment or termination. This process would result in extremely high latency and poor performance, rendering it completely unsuitable for the real-time demands of a chat application.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This DVA-C02 question is part of Courseiva's 1,135-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.