DVA-C02 Development with AWS Services Practice Question
A company has a Lambda function that processes records from an SQS queue. The function is failing intermittently with timeout errors. The processing time per record varies, but the SQS queue has a visibility timeout of 30 seconds. The Lambda function has a timeout of 1 minute. What is the MOST likely cause of the timeout errors?
⚠ Common exam trap
Many exam-takers confuse timeout errors with throttling or concurrency issues, but the specific interplay between SQS visibility timeout and Lambda function timeout is a classic DVA-C02 pitfall that tests understanding of asynchronous message processing lifecycle.
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
✓
The SQS visibility timeout is shorter than the Lambda function timeout.
When the SQS visibility timeout (30 seconds) is shorter than the Lambda function timeout (1 minute), the message becomes visible again in the queue before the function finishes processing it. This causes the same message to be picked up by another consumer (or the same Lambda invocation) while the original invocation is still running, leading to duplicate processing and eventual timeout errors as the function repeatedly attempts to process the same record.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The Lambda function's reserved concurrency is set too low.
Why it's wrong here
Setting a low reserved concurrency for a Lambda function limits the maximum number of concurrent executions. If this limit is reached, subsequent invocation attempts will be throttled and fail immediately with a TooManyRequestsException, rather than being allowed to start and then time out during execution. Therefore, low reserved concurrency would lead to invocation failures, not individual function timeouts once execution has begun.
- ✗
The SQS queue has too many messages causing Lambda to throttle.
Why it's wrong here
An SQS queue with a large number of messages typically triggers Lambda's event source mapping to scale up the number of concurrent function invocations to process the backlog efficiently. While there are limits to Lambda's scaling, reaching these limits would result in new invocations being throttled or delayed, not causing individual function executions that have already started to time out. The function itself would still attempt to process its assigned message within its configured timeout.
- ✓
The SQS visibility timeout is shorter than the Lambda function timeout.
Why this is correct
If the SQS visibility timeout is configured to be shorter than the Lambda function's execution timeout, a message being processed by Lambda can become visible again in the queue before the function successfully completes its work. This scenario can lead to other Lambda instances, or even the same one, picking up and attempting to process the identical message again. Such duplicate processing can cause resource contention, unexpected behavior, and ultimately result in the original or subsequent Lambda invocations timing out as they struggle to complete the task or handle redundant operations.
- ✗
The SQS queue's default visibility timeout of 30 seconds is too long.
Why it's wrong here
A longer SQS visibility timeout provides the Lambda function with an extended period to process a message without it becoming visible to other consumers. If the default 30-second visibility timeout were considered "too long," it would actually reduce the likelihood of duplicate processing and subsequent timeouts, as the message would remain invisible for a sufficient duration. Therefore, a long visibility timeout is generally beneficial for preventing message re-delivery and associated processing issues, not a cause of timeouts.
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
One of 724 original DVA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.