DVA-C02 Development with AWS Services Practice Question
A developer is using AWS Lambda to process records from an Amazon Kinesis Data Stream. The Lambda function is invoked with a batch of records. The function processes each record and then returns a response. The developer notices that some records are being processed multiple times. The function's execution time is within the Lambda timeout. The Kinesis stream has 10 shards. The developer wants to ensure that each record is processed exactly once. What should the developer do?
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
✓
Modify the Lambda function to use the sequence number of each record to deduplicate processing.
The correct option is B: modify the Lambda function to use the sequence number of each record to deduplicate processing. AWS Lambda's Kinesis event source mapping provides at-least-once delivery, so a batch or individual records can be retried after a failure or timeout, causing duplicates; Kinesis sequence numbers uniquely identify each record within a shard, so the function can track processed sequence numbers (for example in DynamoDB) and skip records already handled. Option A is wrong because reducing shards does not change Lambda's at-least-once semantics and would only lower throughput. Option C is wrong because retry configuration cannot prevent duplicates from Lambda's own retries or checkpointing behavior. Option D is wrong because a larger batch size does not provide exactly-once processing and can actually increase the number of records reprocessed after a failure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Reduce the number of shards to minimize the chance of duplicates.
Why it's wrong here
Reducing the number of shards does not prevent duplicate processing; it primarily affects the throughput and parallelism of the Kinesis stream. Kinesis Data Streams inherently provides an at-least-once delivery guarantee, meaning records can be delivered multiple times due to various factors like consumer retries, concurrent Lambda invocations, or checkpointing failures. Decreasing shard count would only reduce the number of parallel Lambda invocations, potentially slowing down processing without addressing the fundamental cause of duplicates.
- ✓
Modify the Lambda function to use the sequence number of each record to deduplicate processing.
Why this is correct
Modifying the Lambda function to use the sequence number of each record is the correct approach for deduplication. Each record in a Kinesis stream has a unique sequence number within its shard, which, when combined with the shard ID, forms a globally unique identifier. By storing the last successfully processed sequence number (and shard ID) in a durable external data store, such as Amazon DynamoDB, the Lambda function can check if a record has already been processed before executing its business logic, effectively achieving idempotency.
- ✗
Configure the Lambda function's error handling to retry only failed records.
Why it's wrong here
Configuring the Lambda function's error handling to retry only failed records does not prevent duplicate processing in the context of Kinesis. If a Lambda invocation processes a batch of records and successfully processes some but then fails before the entire batch is acknowledged to Kinesis, the Kinesis service will re-deliver the *entire* batch from the last successfully checkpointed sequence number. This re-delivery will cause records that were already processed to be re-processed as duplicates, irrespective of the function's internal error handling for individual records.
- ✗
Increase the batch size to process more records per invocation.
Why it's wrong here
Increasing the batch size to process more records per invocation does not prevent duplicate processing and can even exacerbate the issue. When a Lambda function processes a larger batch, if a failure occurs mid-batch or the invocation times out, Kinesis will re-deliver the *entire* unacknowledged portion of the batch. A larger batch size means more records are susceptible to being re-processed as duplicates in such failure scenarios, increasing the volume of redundant work rather than preventing it.
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
Courseiva writes every DVA-C02 question from scratch — 1,135 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.