5 exercises — master the vocabulary of serverless computing: cold starts, synchronous vs. asynchronous invocation, execution timeouts, stateless constraints, and concurrency management.
0 / 14 completed
1 / 14
A developer observes: "The first request to this Lambda function after 15 minutes of inactivity takes 800ms; subsequent requests in the following minutes take 12ms."
What is the 800ms overhead called, and what causes it?
Cold start is the cost of spinning up a new execution environment from scratch — subsequent invocations reuse the warm environment and skip these steps.
What happens during a cold start:
Phase
What occurs
Typical cost
Environment init
Cloud provider allocates a microVM / container for the execution environment
50–200ms
Runtime start
JVM / Node.js / Python / .NET runtime initializes
10–500ms (JVM worst case)
Deployment package download
ZIP or container image is fetched and extracted
Varies by package size
Init code execution
Code outside the handler runs: imports, DB connection setup, SDK initialization
Varies by application
Handler invocation
Your function handler runs
12ms (warm: only this step)
Cold start mitigation strategies:
• Provisioned Concurrency (AWS) — pre-initialize a fixed number of execution environments; no cold start on invocation
• Keep-alive pings — schedule an EventBridge event every few minutes to keep environments warm (not reliable for production)
• Compiled languages — Go and Rust functions have near-zero cold starts vs. JVM cold starts of 2–6s with large frameworks
• Reduce package size — smaller deployment packages initialize faster; use tree-shaking to exclude unused dependencies
• Move heavy init outside handler — DB connections, loaded ML models, and SDK clients initialized at the module level persist across warm invocations
Key vocabulary:
• Cold start — the latency of initializing a new serverless execution environment when no warm instance is available
• Warm invocation — an invocation that reuses an already-initialized execution environment, skipping the cold start phases
• Provisioned Concurrency — a configuration that keeps a specified number of Lambda execution environments initialized and ready at all times
• Execution environment — the isolated runtime container (microVM in AWS Lambda's case) that hosts a function instance
2 / 14
An architect notes: "This order-confirmation Lambda is triggered by an S3 PutObject event when a receipt file is uploaded — not by an API Gateway HTTP request."
Which invocation model does an S3 event trigger use, and what does this mean for how errors and retries are handled?
S3 event notifications use the asynchronous invocation model — S3 does not wait for your function to complete.
Lambda invocation models:
Model
Caller waits?
Return value
Retry on error
Common triggers
Synchronous
Yes
Returned to caller
Caller's responsibility
API Gateway, ALB, SDK RequestResponse
Asynchronous
No
Discarded
Up to 2 automatic retries; DLQ on exhaustion
S3 events, SNS, EventBridge, SES
Poll-based (stream)
N/A
Checkpoint position
Retry until success or bisection window expires
SQS, Kinesis, DynamoDB Streams, Kafka (MSK)
Asynchronous Lambda error handling:
S3 event fires → Lambda async queue → attempt 1 → fails
→ retry after ~1min → attempt 2 → fails
→ retry after ~2min → attempt 3 → fails
→ send to Dead Letter Queue (SQS or SNS)
→ or Destinations: onFailure → SQS/SNS/EventBridge/Lambda
Practical implications for the S3-triggered function:
• The function may execute 1–3 times if it keeps failing — your logic must be idempotent to avoid duplicate processing
• S3 guarantees at-least-once event delivery — same event can arrive multiple times
• Use a DLQ (Dead Letter Queue) to capture failed events for investigation and reprocessing
Key vocabulary:
• Synchronous invocation — the caller waits for the function to complete and receives the return value
• Asynchronous invocation — the caller hands off the event and does not wait; Lambda manages retries independently
• Dead Letter Queue (DLQ) — an SQS or SNS destination that receives events after all retry attempts have been exhausted
• Idempotent — a function that produces the same outcome whether invoked once or multiple times with the same input
3 / 14
A Lambda function that processes large PDF documents fails with the error: "Task timed out after 900.00 seconds."
What is this limit called in serverless contexts, and what is the recommended architectural approach for operations that regularly approach this boundary?
AWS Lambda's maximum execution timeout is 15 minutes (900 seconds). This is a hard architectural constraint, not a tunable limit.
Execution timeout limits across FaaS platforms:
Platform
Max timeout
Notes
AWS Lambda
15 minutes
Hard limit; cannot be increased
Google Cloud Functions
60 minutes (gen 2)
9 min for gen 1 HTTP functions
Azure Functions
Unlimited (Premium/Dedicated); 10min Consumption
Durable Functions enable long workflows
Cloudflare Workers
30 seconds (CPU time)
Wall time can be longer for I/O operations
Architectural patterns for long-running operations:
• Step Functions (orchestration) — decompose PDF processing into steps: extract text → analyze → generate summary → store. Each step is a separate Lambda invocation. State machine timeout: 1 year
• SQS + long-running worker (ECS/Fargate) — Lambda enqueues the job; a container worker processes it without time constraints
• Async + polling — Lambda starts the job and returns a job ID; the client polls a status endpoint until complete
• Lambda SnapStart (Java) — reduce cold start for JVM functions, but does not extend timeout
Key vocabulary:
• Execution timeout — the maximum wall-clock time a serverless function is permitted to run in a single invocation
• Step Functions — AWS managed workflow service for orchestrating multi-step processes with long timeouts and error handling
• FaaS (Function-as-a-Service) — the serverless computing model where individual functions are the deployment unit (Lambda, Cloud Functions, Azure Functions)
• Orchestration vs. choreography — orchestration uses a central coordinator (Step Functions); choreography uses event reactions between independent services
4 / 14
A developer reports: "I tried storing the user's session token in a global variable so the next request from the same user would be faster — but the next request went to a completely different execution environment and couldn't find it."
Which pattern correctly handles user session state in a serverless architecture?
Serverless functions are stateless by design — execution environments can be created, reused, or terminated at any time. State must live outside the function.
Why in-function state is unreliable:
Request 1 → execution env A (global var set: session = "abc123")
Request 2 → execution env B (new env, global var empty: session = undefined)
Request 3 → execution env A (warm, global var still set: session = "abc123")
Request 4 → execution env B (warm, still empty)
External state store options for serverless:
Store
Use case
Latency
DynamoDB
Session tokens, user preferences, idempotency keys
Large artifacts, intermediate processing results, batch outputs
10–50ms
RDS / Aurora
Relational data; use RDS Proxy to manage connection pooling for Lambda
1–10ms with proxy
The /tmp caveat (option A is wrong): /tmp (512MB–10GB) persists across warm invocations within the same execution environment, but is not shared across execution environments. It is suitable for caching computed data within a single warm run (e.g., a downloaded ML model), not for user session data that could be handled by any environment.
Stateless function + external state = shared-nothing architecture:
Every execution environment is interchangeable — any instance can handle any request. This enables horizontal scaling with no coordination overhead.
Key vocabulary:
• Stateless function — a function that carries no state between invocations; all state is read from and written to external stores
• Shared-nothing architecture — a design where each execution unit is independent and fully interchangeable, with no shared in-process state
• RDS Proxy — an AWS-managed connection pool for Lambda functions accessing RDS, preventing connection exhaustion during Lambda concurrency spikes
5 / 14
A platform engineer configures reserved concurrency of 50 on a Lambda function that processes database writes for a legacy MySQL database with a connection limit of 60.
What does reserved concurrency do, and why is a limit of 50 intentional in this scenario?
Reserved concurrency serves two purposes: it caps a function's concurrency ceiling AND guarantees a floor of available concurrency within the account.
Concurrency mechanics in AWS Lambda:
Concurrency type
What it does
Effect
Account limit
Default 1,000 concurrent executions per region (adjustable)
Hard cap across all functions in the account-region
Reserved concurrency
Sets per-function max AND reserves that capacity from the account pool
Other functions cannot use the reserved portion; this function cannot exceed it
Provisioned concurrency
Pre-initializes N execution environments (eliminates cold start)
Higher cost; useful for latency-sensitive functions
Unreserved concurrency
Shared pool for functions without a reservation; scales freely up to remaining account limit
One noisy function can starve others
The connection storm problem without reserved concurrency:
Traffic spike → Lambda scales to 400 concurrent executions
400 functions × 1 connection each = 400 MySQL connections
MySQL max_connections = 60 → connection refused, errors cascade
With reserved concurrency = 50:
Traffic spike → Lambda attempts to scale → capped at 50 concurrent executions
50 functions × 1 connection = 50 MySQL connections
MySQL max_connections = 60 → 10 connections spare, system stable
Excess requests → throttled with 429 TooManyRequests (better than DB crash)
Key vocabulary:
• Reserved concurrency — a per-function configuration that simultaneously caps maximum concurrency and reserves that capacity from the account pool
• Provisioned concurrency — pre-initializes execution environments to eliminate cold starts (different from reserved concurrency)
• Connection storm — a scenario where a sudden surge in concurrent function executions exhausts the connection limit of a downstream database
• Throttling (429) — Lambda returns TooManyRequests when reserved concurrency is hit; the caller must retry, typically with exponential backoff
6 / 14
Reviewer: 'The PR description says this Lambda function handles user authentication. However, I'm seeing a significant increase in latency when users log in for the first time – around 3 seconds on average. The logs show it's spending a lot of time querying our DynamoDB table. I think we should consider caching the user data to reduce these cold starts.'
What is the primary performance issue being discussed, and what specific technique would be most effective in addressing it?
The question highlights latency due to 'cold starts,' where the Lambda function needs to initialize its environment and dependencies on the first request. Option A is about security and not directly related to the performance problem described. Option B addresses data size but doesn't solve the initial delay. Option Lambda function caching (correct answer) provides a simple and effective way to store frequently accessed data, avoiding this cold start overhead by serving the cached version instead of re-initializing everything on subsequent requests – which is exactly what the reviewer suggests.
7 / 14
Reviewer: 'The PR description says this Lambda function handles user authentication. However, I'm seeing a significant increase in latency when users log in for the first time – around 3 seconds on average. The logs show it's spending a lot of time querying our DynamoDB table. I think we should consider caching the user data to reduce these cold starts.'
What is the primary performance issue being discussed, and what specific technique would be most effective in addressing it?
The question highlights latency due to 'cold starts,' where the Lambda function needs to initialize its environment and dependencies on the first request. Option A is about security and not directly related to the performance problem described. Option B addresses data size but doesn't solve the initial delay. Option Lambda function caching (correct answer) provides a simple and effective way to store frequently accessed data, avoiding this cold start overhead by serving the cached version instead of re-initializing everything on subsequent requests – which is exactly what the reviewer suggests.
8 / 14
Reviewer: 'The PR description says this Lambda function handles user authentication. However, I'm seeing a significant increase in latency when users log in for the first time – around 3 seconds on average. The logs show it's spending a lot of time querying our DynamoDB table. I think we should consider caching the user data to reduce these cold starts.'
What is the primary performance issue being discussed, and what specific technique would be most effective in addressing it?
The question highlights latency due to 'cold starts,' where the Lambda function needs to initialize its environment and dependencies on the first request. Option A is about security and not directly related to the performance problem described. Option B addresses data size but doesn't solve the initial delay. Option Lambda function caching (correct answer) provides a simple and effective way to store frequently accessed data, avoiding this cold start overhead by serving the cached version instead of re-initializing everything on subsequent requests – which is exactly what the reviewer suggests.
9 / 14
Reviewer: 'The PR description says this Lambda function handles user authentication. However, I'm seeing a significant increase in latency when users log in for the first time – around 3 seconds on average. The logs show it's spending a lot of time querying our DynamoDB table. I think we should consider caching the user data to reduce these cold starts.'
What is the primary performance issue being discussed, and what specific technique would be most effective in addressing it?
The question highlights latency due to 'cold starts,' where the Lambda function needs to initialize its environment and dependencies on the first request. Option A is about security and not directly related to the performance problem described. Option B addresses data size but doesn't solve the initial delay. Option Lambda function caching (correct answer) provides a simple and effective way to store frequently accessed data, avoiding this cold start overhead by serving the cached version instead of re-initializing everything on subsequent requests – which is exactly what the reviewer suggests.
10 / 14
Sarah, a backend engineer, sends this Slack message to the team: 'Hey everyone, I've deployed the new Lambda function for processing image uploads. It's triggered by S3 events and uses Node.js with Express. I'm seeing some high latency spikes – around 200ms – when multiple users upload images simultaneously. I suspect it might be hitting the database connection limit. What immediate action should we take to investigate?'
The Slack message highlights a performance issue with concurrent uploads. Increasing Lambda concurrency directly addresses the potential bottleneck of limited connections to the database. The other options are less targeted; monitoring alone doesn't resolve the problem, and circuit breakers are a good long-term strategy but not the immediate fix.
11 / 14
Mark, a senior developer, is writing a PR description for a new Lambda function that validates user input. He writes: 'This Lambda function now handles all incoming API Gateway requests and performs data validation before processing.' A reviewer comments: 'I'm seeing a significant latency increase – approximately 5 seconds – when users submit forms with complex data. The logs show the function is spending a lot of time parsing JSON payloads.' What's the MOST important thing Mark needs to address in his PR description?
The original PR description is too high-level. A realistic description should outline potential issues like complex JSON payloads causing parsing delays. Adding specifics about validation rules and performance considerations will provide valuable context for reviewers and help identify root causes quickly.
12 / 14
David, a DevOps engineer, is explaining reserved concurrency to a junior developer. He says: 'Reserved concurrency means the Lambda function always has 50 instances available, regardless of incoming traffic.' Which statement best describes the purpose of reserved concurrency?
Reserved concurrency isn't about cold starts or throttling. It ensures that the Lambda function *always* has a minimum number of execution environments ready to handle requests, preventing delays during sudden spikes in demand. This is crucial for predictable performance.
13 / 14
Emily, a developer, is debugging a Lambda function that processes customer orders. The function uses a DynamoDB table to store order details. She notices the following error in the logs: 'Task timed out after 900.00 seconds.' What does this timeout limit represent in the serverless context?
The 900-second timeout limit is a fundamental constraint in serverless environments. It's designed to prevent runaway executions and ensure that Lambda functions don't consume excessive resources or impact other services. This limit applies to *every* invocation.
14 / 14
During a standup meeting, Liam reports: 'I'm seeing latency issues with the Lambda function that generates daily reports. It's triggered by an SQS queue and processes data from our CRM system. The logs show it's struggling to keep up with the volume of new records.' What key aspect is Liam highlighting regarding this Lambda function's architecture?
Liam's statement points towards a potential bottleneck in the overall architecture. While CRM performance is a factor, the core issue is likely with the SQS queue or the Lambda function's scaling capabilities. Addressing either of these would be the most effective approach.
What will I practice in "Serverless Language — Cloud-Native Language Exercises"?
This is a Cloud-Native exercise set. It walks through 14 scenario-based multiple-choice questions built around real usage of Cloud-Native terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 14 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the Cloud-Native vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Cloud-Native exercises?
See the Cloud-Native exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — Cloud-Native vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.