DVA-C02 Development with AWS Services Practice Question
A development team is building a real-time chat application using Amazon API Gateway WebSocket APIs and AWS Lambda. The application needs to maintain a connection to each user and broadcast messages to all connected clients. Which approach should the developer use to scale the application efficiently?
⚠ Common exam trap
Many exam-takers confuse the pub/sub or queuing services (SNS, SQS, ElastiCache) as direct communication channels to WebSocket clients, overlooking that API Gateway requires the Management API for server-to-client messaging and that DynamoDB is the simplest way to store and retrieve connection IDs at scale.
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
✓
Store connection IDs in Amazon DynamoDB and use the API Gateway Management API to send messages to all connections.
DynamoDB provides a scalable, serverless key-value store to persist WebSocket connection IDs, and the API Gateway Management API allows Lambda to send messages directly to any connected client via its connection ID. This combination efficiently handles the broadcast requirement without managing infrastructure, as Lambda can iterate over stored connection IDs and call the Management API for each message.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Store connection IDs in Amazon DynamoDB and use the API Gateway Management API to send messages to all connections.
Why this is correct
This is the correct and standard architectural pattern for serverless WebSocket applications on AWS. When a client connects, API Gateway invokes an onConnect Lambda function which stores the unique connectionId in a DynamoDB table. To send a message to all connected clients, a backend service (e.g., another Lambda function) retrieves all active connectionId's from DynamoDB and then iteratively calls the API Gateway Management API's postToConnection action for each ID, pushing the message directly to the client.
- ✗
Use Amazon ElastiCache to cache connection IDs and have Lambda send messages using the Redis pub/sub feature.
Why it's wrong here
While ElastiCache Redis could store connection IDs, its pub/sub feature is designed for internal, in-memory messaging within the Redis cluster, allowing subscribers to receive messages published to specific channels. It does not provide a mechanism to directly send messages to external WebSocket clients connected via API Gateway. To achieve that, a Lambda function would still need to retrieve messages from Redis and then explicitly use the API Gateway Management API to push them to each client, making the Redis pub/sub part redundant for external delivery.
- ✗
Use Amazon SNS to publish messages to all connected clients via the WebSocket API.
Why it's wrong here
Amazon SNS is a highly scalable messaging service for fan-out scenarios, supporting various endpoints like SQS, Lambda, HTTP/S, email, and SMS. However, SNS does not natively support WebSocket endpoints as a direct subscription protocol. Therefore, it cannot directly publish messages to clients connected via an API Gateway WebSocket API. An intermediary Lambda function would be required to subscribe to the SNS topic, receive the message, and then use the API Gateway Management API to forward it to the WebSocket clients.
- ✗
Use Amazon SQS to queue messages and have Lambda poll the queue to send messages to all connections.
Why it's wrong here
Amazon SQS is a robust message queuing service primarily used for decoupling application components and ensuring reliable, asynchronous message delivery, typically for point-to-point processing by a single consumer. It is not designed for broadcasting messages to multiple active WebSocket connections. While a Lambda function could poll an SQS queue for new messages, it would still need to retrieve all active connection IDs from a separate data store (like DynamoDB) and then use the API Gateway Management API to individually send the message to each client, making SQS an inefficient choice for the broadcast mechanism itself.
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 724-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.