Practice serverless vocabulary: on-demand functions, cold starts, invocation-based pricing, timeouts, event-driven architecture, and serverless vs. containers trade-offs.
0 / 26 completed
1 / 26
Your team says 'The function runs on-demand.' What does on-demand execution mean in serverless?
Serverless functions are event-triggered and on-demand — infrastructure is provisioned when a trigger fires and de-provisioned (scales to zero) when not needed. You pay only when the function runs, not for idle capacity.
2 / 26
A performance report notes 'cold start latency is 800ms on first invocation.' What is a cold start?
A cold start occurs when a serverless function is invoked after being idle (the container was de-provisioned). The platform must provision a new execution environment, which adds latency. Subsequent 'warm' invocations reuse the running container and are much faster.
3 / 26
Your architecture notes say 'The function has a 15-minute timeout limit (AWS Lambda).' What happens if the function exceeds this limit?
AWS Lambda enforces a maximum execution timeout of 15 minutes. If a function runs longer, Lambda terminates it. This makes Lambda unsuitable for long-running tasks — those should use containers, Step Functions, or other compute options.
4 / 26
A system diagram shows 'event-driven invocation' for a serverless function. What triggers this function?
Serverless functions are typically triggered by events: an S3 object upload, an SQS/Kafka message, an HTTP request via API Gateway, a database stream, or a scheduled timer. The event-driven model is fundamental to serverless architecture.
5 / 26
A trade-off analysis compares 'serverless vs. containers.' Which statement best captures a key trade-off?
The core serverless vs. containers trade-off: serverless minimizes operational burden and scales automatically to zero (cost-efficient for sporadic workloads) but has cold starts, execution limits, and vendor lock-in. Containers give more control, predictable performance, and no execution limits but require orchestration and management.
6 / 26
Sarah: "Hey team, I'm seeing a lot of 'stateless' mentioned with our new serverless functions. What does that really mean?"
Stateless in serverless architecture refers to functions that don't retain information about past requests. Each invocation is treated as completely independent, which allows them to be easily scaled and triggered by external events without needing persistent storage or session management. This contrasts with traditional applications where state is often managed within the server itself, leading to complexity and limitations.
7 / 26
PR Description:
Subject: Implement User Authentication API
Body:
"The Lambda function will be invoked by the frontend via a POST request to /api/v1/auth. We'll use a serverless event to trigger this, ensuring minimal operational overhead and scalability. The function should handle JWT validation and user creation."
This question tests understanding of how serverless functions are triggered and configured in a real-world scenario. The correct answer recognizes that the description accurately outlines the function's purpose – handling JWT validation and user creation via a POST request. The other options highlight common misconceptions: JWT validation is a key stateless operation, failing to mention it suggests a lack of understanding, and 'serverless event' itself is simply a trigger mechanism needing further elaboration (like specifying API Gateway).
8 / 26
During a code review, David asks: "The API Gateway is configured to use Lambda functions for all our new integrations. What does 'event routing' mean in this context?"
The correct answer highlights event routing's dynamic nature – it's not just about data flow. Serverless event routing leverages attributes of incoming requests (like URL path or HTTP method) to determine *which* Lambda function should be executed. Misconceptions often arise from thinking of it as a simple mapping, or that it involves manual configuration; it's a core principle of serverless architecture driven by the request itself.
9 / 26
Your team is discussing the architecture for a new serverless application. Mark says, 'We're leveraging asynchronous processing with EventBridge.' During a code review discussion, you're asked: 'What does 'EventBridge' mean in the context of our serverless design?'
EventBridge is a managed service (primarily AWS EventBridge) that acts as an event bus. It allows different services within your application – including Lambda functions – to communicate with each other without direct dependencies. This decoupling and routing of events is core to the design principles of serverless architectures, enabling loose coupling and scalability. The incorrect options misinterpret its role as a database, CLI tool, or deployment process.
10 / 26
Sarah: "Hey team, I'm seeing a lot of 'stateless' mentioned with our new serverless functions. What does that really mean?"
Stateless in serverless architecture refers to functions that don't retain information about past requests. Each invocation is treated as completely independent, which allows them to be easily scaled and triggered by external events without needing persistent storage or session management. This contrasts with traditional applications where state is often managed within the server itself, leading to complexity and limitations.
11 / 26
PR Description:
Subject: Implement User Authentication API
Body:
"The Lambda function will be invoked by the frontend via a POST request to /api/v1/auth. We'll use a serverless event to trigger this, ensuring minimal operational overhead and scalability. The function should handle JWT validation and user creation."
This question tests understanding of how serverless functions are triggered and configured in a real-world scenario. The correct answer recognizes that the description accurately outlines the function's purpose – handling JWT validation and user creation via a POST request. The other options highlight common misconceptions: JWT validation is a key stateless operation, failing to mention it suggests a lack of understanding, and 'serverless event' itself is simply a trigger mechanism needing further elaboration (like specifying API Gateway).
12 / 26
During a code review, David asks: "The API Gateway is configured to use Lambda functions for all our new integrations. What does 'event routing' mean in this context?"
The correct answer highlights event routing's dynamic nature – it's not just about data flow. Serverless event routing leverages attributes of incoming requests (like URL path or HTTP method) to determine *which* Lambda function should be executed. Misconceptions often arise from thinking of it as a simple mapping, or that it involves manual configuration; it's a core principle of serverless architecture driven by the request itself.
13 / 26
Your team is discussing the architecture for a new serverless application. Mark says, 'We're leveraging asynchronous processing with EventBridge.' During a code review discussion, you're asked: 'What does 'EventBridge' mean in the context of our serverless design?'
EventBridge is a managed service (primarily AWS EventBridge) that acts as an event bus. It allows different services within your application – including Lambda functions – to communicate with each other without direct dependencies. This decoupling and routing of events is core to the design principles of serverless architectures, enabling loose coupling and scalability. The incorrect options misinterpret its role as a database, CLI tool, or deployment process.
14 / 26
Sarah: "Hey team, I'm seeing a lot of 'stateless' mentioned with our new serverless functions. What does that really mean?"
Stateless in serverless architecture refers to functions that don't retain information about past requests. Each invocation is treated as completely independent, which allows them to be easily scaled and triggered by external events without needing persistent storage or session management. This contrasts with traditional applications where state is often managed within the server itself, leading to complexity and limitations.
15 / 26
PR Description:
Subject: Implement User Authentication API
Body:
"The Lambda function will be invoked by the frontend via a POST request to /api/v1/auth. We'll use a serverless event to trigger this, ensuring minimal operational overhead and scalability. The function should handle JWT validation and user creation."
This question tests understanding of how serverless functions are triggered and configured in a real-world scenario. The correct answer recognizes that the description accurately outlines the function's purpose – handling JWT validation and user creation via a POST request. The other options highlight common misconceptions: JWT validation is a key stateless operation, failing to mention it suggests a lack of understanding, and 'serverless event' itself is simply a trigger mechanism needing further elaboration (like specifying API Gateway).
16 / 26
During a code review, David asks: "The API Gateway is configured to use Lambda functions for all our new integrations. What does 'event routing' mean in this context?"
The correct answer highlights event routing's dynamic nature – it's not just about data flow. Serverless event routing leverages attributes of incoming requests (like URL path or HTTP method) to determine *which* Lambda function should be executed. Misconceptions often arise from thinking of it as a simple mapping, or that it involves manual configuration; it's a core principle of serverless architecture driven by the request itself.
17 / 26
Your team is discussing the architecture for a new serverless application. Mark says, 'We're leveraging asynchronous processing with EventBridge.' During a code review discussion, you're asked: 'What does 'EventBridge' mean in the context of our serverless design?'
EventBridge is a managed service (primarily AWS EventBridge) that acts as an event bus. It allows different services within your application – including Lambda functions – to communicate with each other without direct dependencies. This decoupling and routing of events is core to the design principles of serverless architectures, enabling loose coupling and scalability. The incorrect options misinterpret its role as a database, CLI tool, or deployment process.
18 / 26
Sarah: "Hey team, I'm seeing a lot of 'stateless' mentioned with our new serverless functions. What does that really mean?"
Stateless in serverless architecture refers to functions that don't retain information about past requests. Each invocation is treated as completely independent, which allows them to be easily scaled and triggered by external events without needing persistent storage or session management. This contrasts with traditional applications where state is often managed within the server itself, leading to complexity and limitations.
19 / 26
PR Description:
Subject: Implement User Authentication API
Body:
"The Lambda function will be invoked by the frontend via a POST request to /api/v1/auth. We'll use a serverless event to trigger this, ensuring minimal operational overhead and scalability. The function should handle JWT validation and user creation."
This question tests understanding of how serverless functions are triggered and configured in a real-world scenario. The correct answer recognizes that the description accurately outlines the function's purpose – handling JWT validation and user creation via a POST request. The other options highlight common misconceptions: JWT validation is a key stateless operation, failing to mention it suggests a lack of understanding, and 'serverless event' itself is simply a trigger mechanism needing further elaboration (like specifying API Gateway).
20 / 26
During a code review, David asks: "The API Gateway is configured to use Lambda functions for all our new integrations. What does 'event routing' mean in this context?"
The correct answer highlights event routing's dynamic nature – it's not just about data flow. Serverless event routing leverages attributes of incoming requests (like URL path or HTTP method) to determine *which* Lambda function should be executed. Misconceptions often arise from thinking of it as a simple mapping, or that it involves manual configuration; it's a core principle of serverless architecture driven by the request itself.
21 / 26
Your team is discussing the architecture for a new serverless application. Mark says, 'We're leveraging asynchronous processing with EventBridge.' During a code review discussion, you're asked: 'What does 'EventBridge' mean in the context of our serverless design?'
EventBridge is a managed service (primarily AWS EventBridge) that acts as an event bus. It allows different services within your application – including Lambda functions – to communicate with each other without direct dependencies. This decoupling and routing of events is core to the design principles of serverless architectures, enabling loose coupling and scalability. The incorrect options misinterpret its role as a database, CLI tool, or deployment process.
22 / 26
During a code review, Elena comments on a Lambda function's configuration: 'This function uses a `dead-letter queue` (DLQ). What is the primary purpose of a DLQ in a serverless environment?',
A dead-letter queue (DLQ) is designed to handle messages that repeatedly fail to be processed by a serverless function. This prevents message loss and allows developers to investigate the root cause of processing failures – often, it's a transient issue that can be addressed without losing data. It's distinct from retry mechanisms which simply attempt to process the message again; the DLQ captures messages that have exhausted their retries.
23 / 26
Liam sends a Slack message: 'I'm seeing high latency with our image resizing Lambda function. I suspect it's hitting the limits of S3's concurrent requests. What does 'concurrency limit' refer to in this scenario?',
A concurrency limit on a Lambda function interacting with S3 defines the maximum number of concurrent operations (like GET or PUT) that the Lambda can perform against S3. Exceeding this limit results in throttling, leading to latency issues. It's crucial for managing resource contention and ensuring efficient use of both services.
24 / 26
The following is a simplified API response from our serverless backend: `{"status": "200", "data": {"user": {"id": 123, "name": "John Doe"}}}`. When discussing this response with a junior developer, you explain: 'This response demonstrates a key principle of serverless – what does the term 'event-driven architecture' mean in relation to this API call?',
Event-driven architecture is central to serverless. The response indicates that the API call was initiated by an event (e.g., a user action) and the backend scaled itself accordingly to handle the load. This contrasts with traditional architectures where scaling is often manual and reactive.
25 / 26
A pull request description reads: 'This change adds a new Lambda function triggered by an EventBridge rule that processes user profile updates. We're using `batch invocation` to improve efficiency.' You are explaining this to a team member. What does 'batch invocation' mean in the context of this PR?',
Batch invocation is a serverless pattern where a single Lambda execution processes multiple items (in this case, user profile updates) that are grouped together in a batch. This significantly improves efficiency compared to invoking the Lambda function for each individual update, reducing overhead and costs.
26 / 26
During a daily stand-up, Maria says: 'We're using API Gateway with Lambda functions to handle our mobile app traffic. We've implemented caching at the API Gateway level.' You are asked: 'What is the primary benefit of implementing caching in this serverless architecture?',
Caching at the API Gateway level dramatically reduces response times for frequently requested data. By serving cached responses instead of invoking Lambda functions (which have cold starts and execution costs), we improve user experience and reduce operational costs. Caching optimizes for performance rather than cost reduction in this scenario.
This is a Cloud-Native exercise set. It walks through 26 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 26 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.