These questions cover Lambda performance and messaging — two areas that appear heavily across DVA-C02 question sets and where the wrong mental model costs marks.
Question 1
A Java 21 Lambda function that initialises a Spring Boot context takes 8–12 seconds to start. Users are complaining about intermittent latency spikes. Which feature reduces this cold start time without changing the application code?
- A) Lambda Reserved Concurrency set to the expected peak load
- B) Lambda SnapStart, which snapshots the initialised execution environment
- C) Lambda Layers to pre-package Spring Boot dependencies
- D) Increase the function memory allocation to 10 GB
Answer: B — Lambda SnapStart
Lambda SnapStart (available for Java 11 and Java 21 runtimes) takes a Firecracker microVM snapshot after the Init phase completes. On subsequent invocations, Lambda restores from the snapshot instead of re-running initialisation, reducing startup latency from seconds to milliseconds.
Why the others don't solve it:
- Reserved Concurrency controls how many concurrent executions are allowed, not how fast they start
- Lambda Layers reduce deployment package size and enable code sharing, but don't skip the init phase
- More memory speeds up CPU-bound init slightly (Lambda allocates CPU proportional to memory) but doesn't eliminate framework startup time
SnapStart is the purpose-built solution for framework-heavy Java workloads.
</details>Question 2
A Lambda function processing an SQS queue is generating high NumberOfEmptyReceives CloudWatch metrics, causing unexpected SQS costs. What is the most cost-effective fix?
- A) Switch to an SQS FIFO queue to reduce redundant API calls
- B) Reduce the Lambda function timeout to limit idle polling time
- C) Configure the SQS queue's
ReceiveMessageWaitTimeSecondsto 20 seconds - D) Increase Lambda reserved concurrency to process messages faster
Answer: C — Configure ReceiveMessageWaitTimeSeconds to 20 seconds
NumberOfEmptyReceives spikes indicate short polling: Lambda's event source mapping calls ReceiveMessage and gets an empty response because no messages are in the queue at that instant. Each empty call still costs money.
Setting ReceiveMessageWaitTimeSeconds to up to 20 seconds enables long polling. The ReceiveMessage call holds the connection open until a message arrives or the wait time expires, dramatically reducing empty responses.
| Polling type | Behaviour | Cost |
|---|---|---|
| Short polling (default) | Returns immediately, empty if no messages | Higher — many empty API calls |
| Long polling (wait ≤ 20s) | Waits for a message before returning | Lower — far fewer API calls |
FIFO queues, concurrency, and timeout changes don't affect polling behaviour.
</details>Question 3
A Lambda function generates pre-signed S3 URLs so clients can upload files directly. Users report that upload links expire before they can use them, even though the Lambda generates the URL with a 1-hour expiry. What is the most likely cause?
- A) Pre-signed URLs generated in
us-east-1have a maximum TTL of 15 minutes - B) The Lambda function uses an IAM role; pre-signed URLs expire when the role's temporary credentials expire
- C) S3 pre-signed URLs are always limited to 15 minutes regardless of the requested expiry
- D) The Lambda function must use SDK v4 signer explicitly to honour custom expiry
Answer: B — The IAM role's temporary credentials expire
Pre-signed URLs are signed with the credentials of the principal that creates them. Lambda functions run under an IAM role, which issues temporary credentials with a maximum session duration (typically 1 hour by default, configurable up to 12 hours). If the role's temporary credentials expire before the requested URL TTL, the URL becomes invalid — even if you set a longer expiry.
Fixes:
- Extend the IAM role's maximum session duration to match your required URL lifetime
- Use a long-lived IAM user's credentials to sign URLs (not recommended)
- Generate the pre-signed URL closer to when the client needs it
The 15-minute limit mentioned in options A and C applies to pre-signed URLs signed with temporary credentials from AWS STS using the GetFederationToken API — not standard IAM role credentials.
Key Takeaways
- Lambda SnapStart is the solution for slow Java framework cold starts — it snapshots after init, not before
- Empty SQS receives = short polling; fix with
ReceiveMessageWaitTimeSecondsup to 20 seconds (long polling) - Pre-signed URL expiry is bounded by the signing credentials' lifetime, not just the TTL you request