DVA-C02 Development with AWS Services Practice Question
A developer is building a real-time chat application using WebSocket APIs in API Gateway and Lambda. The application must handle thousands of concurrent connections. Which TWO actions should the developer take to ensure the application scales properly?
⚠ Common exam trap
A common pitfall is assuming CloudFront can help scale WebSocket APIs for concurrent connections. While CloudFront does support WebSocket connections, it does not address the backend Lambda scaling or state management required for thousands of connections. The correct scaling actions are setting reserved concurrency for the Lambda function and storing connection IDs in DynamoDB for state management. Similarly, enabling API Gateway caching or placing Lambda in a VPC do not solve the concurrency scaling issue.
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
✓
Set the Lambda function's reserved concurrency to a high enough value.
Setting reserved concurrency ensures the Lambda function has enough allocated capacity to handle the high volume of concurrent WebSocket connections without being throttled by the account-level concurrency limit. Without reserved concurrency, the function could experience throttling errors (HTTP 429) during traffic spikes, causing dropped connections and poor user experience.
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 CloudFront to distribute the WebSocket endpoints.
Why it's wrong here
CloudFront does support WebSocket connections via the same CloudFront distribution, but it is not necessary for scaling. API Gateway WebSocket API automatically scales to handle thousands of concurrent connections. Using CloudFront adds complexity and cost without improving scaling. Instead, focus on Lambda concurrency and DynamoDB for state management.
- ✗
Place the Lambda function in a VPC to improve security.
Why it's wrong here
While placing a Lambda function in a VPC can enhance security by allowing access to private resources and applying network security groups, it introduces significant scaling limitations for high-concurrency applications like real-time chat. Each concurrent invocation within a VPC requires an Elastic Network Interface (ENI), and AWS imposes service quotas on ENIs per VPC and per subnet. These quotas can quickly become a bottleneck, preventing the Lambda function from scaling rapidly enough to handle sudden spikes in chat activity, thus making it unsuitable for a highly scalable real-time chat application.
- ✗
Enable API Gateway caching to reduce Lambda invocations.
Why it's wrong here
API Gateway caching is designed for REST API endpoints to store and serve responses for idempotent requests, aiming to reduce backend load and improve latency. However, WebSocket connections establish a persistent, full-duplex communication channel where messages are exchanged in real-time and are inherently dynamic and unique to each session. Caching mechanisms are fundamentally incompatible with the stateful, continuous nature of WebSocket message flow, rendering this option irrelevant and ineffective for a real-time chat application.
- ✓
Set the Lambda function's reserved concurrency to a high enough value.
Why this is correct
For a real-time chat application, sudden bursts of user activity can lead to a large volume of concurrent Lambda invocations. Setting a high enough reserved concurrency guarantees that a specified number of execution environments are always available exclusively for this specific Lambda function, preventing it from being throttled by the account's unreserved concurrency pool. This ensures the function can consistently process messages and maintain responsiveness even during peak load, which is critical for delivering a smooth and reliable real-time chat experience.
- ✓
Use a DynamoDB table to store connection IDs and handle connection state.
Why this is correct
A real-time chat application built with API Gateway WebSockets and Lambda is inherently stateless, meaning Lambda functions do not retain information about connected clients between invocations. DynamoDB, a highly scalable, fully managed NoSQL database, is an excellent choice for storing and retrieving connection IDs and associated user metadata, such as user IDs or chat room memberships. Its low-latency performance and ability to handle massive read/write throughput make it ideal for quickly looking up active connections and managing the state required to broadcast messages to specific clients or groups.
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 →
Same concept, more angles
2 more ways this is tested on DVA-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A developer is building a real-time chat application using WebSockets via API Gateway. The backend uses AWS Lambda functions to handle connect, disconnect, and message events. The application needs to broadcast messages to all connected clients. What is the most scalable and cost-effective way to maintain the list of connection IDs and broadcast messages?
hard- A.Use an SQS FIFO queue to store connection IDs and have a Lambda function poll the queue to broadcast.
- ✓ B.Store connection IDs in a DynamoDB table. Use a Lambda function to query all connection IDs and send messages using the API Gateway Management API.
- C.Maintain an in-memory list of connection IDs in a global variable of a single Lambda function.
- D.Use Amazon ElastiCache Redis to store connection IDs and use Redis Pub/Sub for broadcasting.
Why B: DynamoDB provides a scalable and cost-effective solution for storing connection IDs because it is a NoSQL database designed for high availability and low latency. The Lambda function can query the entire table to retrieve all connection IDs and then use the API Gateway Management API (via `postToConnection`) to send messages to each client. This approach scales horizontally because multiple Lambda instances can access the same DynamoDB table. Option A is wrong because SQS FIFO queues are not suitable for broadcasting all messages to all connections; they are designed for point-to-point messaging and would require polling, adding latency and cost. Option C is wrong because an in-memory list in a single Lambda instance does not persist across cold starts and cannot be shared across multiple concurrent Lambda instances, leading to data loss and incorrect broadcasts. Option D is wrong because ElastiCache Redis adds operational complexity and cost, and using its Pub/Sub feature would require additional infrastructure; DynamoDB is simpler and more aligned with serverless best practices.
Variation 2. 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?
hard- ✓ A.Store connection IDs in Amazon DynamoDB and use the API Gateway Management API to send messages to all connections.
- B.Use Amazon ElastiCache to cache connection IDs and have Lambda send messages using the Redis pub/sub feature.
- C.Use Amazon SNS to publish messages to all connected clients via the WebSocket API.
- D.Use Amazon SQS to queue messages and have Lambda poll the queue to send messages to all connections.
Why A: 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.
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.