If you do not understand event-driven computing, you will waste money running servers that sit idle 95% of the time, and you will fail the DVA-C02 exam questions about building scalable, cost-effective applications. AWS Lambda solves this by letting you run code without provisioning or managing servers — you upload your code, and AWS runs it only when a specific event occurs, then spins it down. For the DVA-C02, mastering Lambda is non-negotiable: it is the core compute service for serverless architectures, and exam questions test your ability to configure triggers, handle execution context, and design functions that work with services like API Gateway, S3, and DynamoDB.
Jump to a section
3 people are running a 24-hour pizza shop. They do not hire a chef to stand in the kitchen waiting for orders. Instead, they have a phone that, when it rings, triggers a perfectly prepped pizza-making machine. The machine only runs when the phone rings. It turns on, assembles the pizza exactly as instructed, bakes it, boxes it, and then powers off completely. The shop does not pay for the machine to sit idle. It only pays for the 8 minutes the machine actually runs per order. Each different call — a delivery order, a collection order, or a catering order — triggers a different set of instructions. One phone number is for standard orders, another is for VIP customers, and a third is for the shop’s own stock-reordering system. The machine has no memory between orders. Every call is a fresh, self-contained event. The phone numbers are the triggers. The pizza-making instructions are the functions. The event-driven architecture means the entire system — the lights, the heating, the payment terminal — only activates when a phone call comes in. The shop saves money, scales effortlessly on Friday nights, and never has a chef standing around doing nothing.
This maps directly to AWS Lambda. The phone calls are events. The triggers are AWS services like S3 or API Gateway. The pizza machine is the Lambda function — code that executes precisely when triggered and then stops. The shop’s “no idle cost” is Lambda’s pay-per-request model. The system only runs when work exists.
AWS Lambda is a compute service that lets you run code without thinking about servers. Before Lambda, if you wanted to run an application, you had to rent a virtual machine (like Amazon EC2) that stayed on 24/7, even when no one was using it. You paid for that idle time. Lambda flips this model: you upload your code (called a function), and AWS runs it only when a specific event happens — like a file being uploaded to an S3 bucket or an HTTP request arriving at an API endpoint. After the code finishes, Lambda stops the execution and you pay only for the compute time consumed, measured in milliseconds.
A Lambda function is the core unit. It is a piece of code (written in Python, Node.js, Java, Go, or other supported languages) that performs a single, focused task. When you create a function, you specify:
The runtime (e.g., Python 3.12)
The handler (the specific function in your code that AWS calls when the function is invoked — for example, 'index.handler' means AWS looks for a function named 'handler' in a file called 'index.py')
The memory allocation (from 128 MB to 10,240 MB, which also proportionally allocates CPU power)
A timeout (maximum execution time, from 1 second to 15 minutes)
A trigger is something that causes the Lambda function to run. AWS services that can act as triggers include:
Amazon S3: when a new object is created or deleted
Amazon DynamoDB: when a new record is added or updated (via DynamoDB Streams)
Amazon API Gateway: when an HTTP request arrives at a REST or WebSocket API
Amazon SQS: when a message arrives in a queue
Amazon SNS: when a notification is published to a topic
Amazon EventBridge: when a scheduled event occurs (like a cron job) or when another AWS service emits a state change
An event is the data that the trigger sends to the Lambda function. For example, when S3 triggers Lambda, the event contains details about the bucket name, the object key, and the size of the uploaded file. The function reads this event and uses it to decide what to do — perhaps resizing an image, processing a log file, or updating a database.
Event-driven architecture is the design pattern where components communicate by emitting and reacting to events, rather than by making direct synchronous calls. Imagine a factory: instead of a central foreman shouting orders to every machine, each machine emits a signal when it finishes a task, and the next machine in line reacts to that signal. This decouples the components — if one machine breaks, the others keep running. In AWS, a typical event-driven flow might be: a customer uploads a photo to S3, which triggers a Lambda function to create a thumbnail, which then stores the thumbnail in a different S3 bucket and updates a DynamoDB table with the metadata. No server is ever manually started or stopped.
Why does this matter? It replaces the traditional model of running a server (like an EC2 instance) that sits and waits for work. That old model is called 'provisioned capacity' — you guess how much traffic you will get and pay for that capacity whether you use it or not. Lambda uses 'on-demand capacity' — you pay only for what you use, and AWS automatically scales the function up to handle thousands of concurrent invocations or down to zero when there is no traffic. For the DVA-C02, you must understand how to write a function, configure triggers, and handle the event payload that arrives in your code.
Create the Lambda function in the AWS Management Console
You navigate to the Lambda service, click 'Create function', choose 'Author from scratch', enter a name (e.g., 'ProcessOrder'), select a runtime (like Python 3.12), and create a new execution role with basic permissions. This sets up the skeleton. The function will not do anything yet because it has no trigger and no code.
Write and upload your function code
In the inline code editor, you write the handler function that will process events. For example, a function that resizes images: `def lambda_handler(event, context):` followed by code to download an image from S3, resize it, and upload it back. You can upload a .zip file or use a container image if you have larger dependencies. The handler name (e.g., 'index.handler') tells Lambda which file and function to call.
Configure the function's execution role (IAM role)
The function needs permissions to interact with other AWS services. If your function reads from S3, you attach a policy that grants `s3:GetObject`. If it writes to DynamoDB, you add `dynamodb:PutItem`. AWS provides managed policies like `AWSLambdaBasicExecutionRole` (for CloudWatch logging) and `AWSLambdaDynamoDBExecutionRole`. You edit the role in IAM after the function is created.
Add a trigger from an event source (e.g., S3 bucket)
In the Lambda console, click 'Add trigger'. Select S3, then choose the S3 bucket and the event type (like 'All object create events'). Optionally specify a prefix or suffix to filter which objects trigger the function (e.g., only objects ending in '.jpg'). Once saved, every new object uploaded to that bucket will automatically invoke the function.
Test the function with a sample event
You create a test event in the console that mimics the structure of an S3 event (e.g., with bucket name and object key). When you click 'Test', Lambda invokes the function with that event. You can view the execution result, logs in CloudWatch, and any errors. This validates that the code works correctly before you rely on real events.
Monitor and debug using CloudWatch Logs
Every Lambda invocation automatically logs to CloudWatch. You view these logs in the 'Monitor' tab of the Lambda console. If the function throws an error, the log shows the stack trace. You set up CloudWatch alarms to notify you of high error rates or throttled invocations. This step ensures the function behaves correctly in production.
An IT professional working for an e-commerce company is tasked with processing customer order confirmations. Every time a customer places an order, the order details are saved to an Amazon DynamoDB table. The company needs to automatically:
Send a confirmation email
Update a shipping service with the order details
Log the order in a separate analytics database
Before serverless, the developer would need to run a server (EC2 instance) with a program that constantly polls the database for new orders. This wastes money and resources. With Lambda, the developer sets up a trigger on the DynamoDB table using DynamoDB Streams. When a new order is inserted, the stream emits an event containing the order ID, customer email, and product details. This event triggers the Lambda function, which contains the logic to call Amazon Simple Email Service (SES) to send the email, Amazon Simple Queue Service (SQS) to queue the shipping update, and another Lambda function to store the analytics log.
Step by step, the developer does this:
Creates a Lambda function using the AWS Management Console or AWS CLI
Writes the Python code that parses the event from DynamoDB Streams
Configures the function's IAM role (a set of permissions) to allow it to read from DynamoDB Streams and write to SES and SQS
Enables DynamoDB Streams on the orders table
Adds a trigger in the Lambda console pointing to that DynamoDB stream
Sets the function's timeout to 30 seconds (more than enough for the email and queue operations)
Tests the function by inserting a test order into the table
In production, the developer must also consider:
Idempotency: if the same event is delivered twice (possible with DynamoDB Streams), the function should not send two emails. The developer writes code to check if the order ID has already been processed.
Error handling: if the email service fails, the function should retry. Lambda can be configured to retry failed invocations up to two times.
Dead-letter queue (DLQ): after exhausting retries, the failed event is sent to an SQS queue for manual investigation.
Memory settings: if the function needs to process large images, the developer increases the memory allocation (and gets more CPU as a side effect).
The real-world result: the company handles 1,000 orders per minute during Black Friday without provisioning a single server. The Lambda functions scale horizontally (more concurrent executions) automatically. The developer spends time writing business logic, not managing servers.
The DVA-C02 exam tests Lambda extensively. You will see approximately 10-15 questions that directly involve Lambda, and many more that involve it indirectly through topics like API Gateway, DynamoDB, and Step Functions. Here is what the exam specifically tests:
Function configuration: You must know the maximum execution timeout (15 minutes), memory range (128 MB to 10,240 MB), and deployment package size limits (50 MB for zipped direct upload, 250 MB for container images). The exam will ask: 'What is the maximum timeout for a Lambda function?' The answer is 900 seconds (15 minutes). They will try to trap you with 300 seconds (5 minutes, the old limit).
Triggers and event sources: You need to know which services can invoke Lambda synchronously (e.g., API Gateway, ALB) and which invoke asynchronously (e.g., S3, SNS, CloudWatch Events). Synchronous invocations wait for the function to finish and return a response. Asynchronous invocations fire and forget — the function runs but the caller does not wait. The exam loves tricky wording: 'Which invocation type does S3 use?' Answer: asynchronous.
Event payloads: The exam will present a sample JSON event from S3 or DynamoDB Streams and ask you to extract specific fields (like bucket name or record keys). You must memorise the structure of common events. For S3, the event contains 'Records[0].s3.bucket.name'. For DynamoDB Streams, it is 'Records[0].dynamodb.Keys'.
IAM permissions: Lambda functions need an execution role (IAM role) that grants permissions to the services the function interacts with. The exam frequently tests which policy is required: e.g., 'To allow a Lambda function to write to CloudWatch Logs, attach the AWSLambdaBasicExecutionRole managed policy.'
Concurrency and throttling: Understand reserved concurrency (guarantees a set number of concurrent executions for a function) and provisioned concurrency (pre-warms a number of environments to avoid cold starts). The exam asks: 'How do you ensure a function can always handle 100 concurrent requests?' Answer: set reserved concurrency to 100.
Cold starts: When a function has not been used for a while, AWS initialises a new environment (cold start), which adds latency. The exam tests ways to mitigate it: using provisioned concurrency, keeping functions small (fewer dependencies), and using Lambda SnapStart for Java.
Best practices: Write functions that are stateless (do not rely on local storage), handle idempotency, use environment variables for configuration, and use the built-in CloudWatch logging.
Common traps:
Trap 1: Assuming VPC-enabled Lambda functions have internet access by default. They do not — you must add a NAT Gateway or configure a VPC endpoint.
Trap 2: Thinking that Lambda can directly respond to an S3 event in synchronous mode. It cannot — S3 uses async invocation.
Trap 3: Forgetting that Lambda has a maximum execution duration of 15 minutes. For longer-running tasks, you must use AWS Step Functions or AWS Fargate.
Trap 4: Confusing 'event source mapping' (used for polling-based services like SQS and DynamoDB Streams) with 'triggers' (push-based services like S3 and API Gateway). Event source mappings are configured differently — they use the CreateEventSourceMapping API.
Key definitions to memorise:
Function: the code and its configuration.
Event: the JSON payload passed to the function.
Context object: provides runtime information like the function name, AWS request ID, and remaining time.
Execution role: the IAM role that gives the function permissions.
Lambda service: the managed compute service.
The maximum execution timeout for an AWS Lambda function is 900 seconds (15 minutes).
Lambda functions are stateless; any data that must persist between invocations must be stored externally, such as in DynamoDB or S3.
S3 invokes Lambda asynchronously, meaning the function runs in the background and S3 does not wait for a response.
The Lambda execution role is an IAM role that grants the function permissions to access other AWS services.
Provisioned concurrency pre-warms a set number of execution environments to eliminate cold starts for latency-sensitive applications.
If your Lambda function needs internet access while inside a VPC, you must configure a NAT Gateway or use a VPC endpoint.
The maximum deployment package size for direct upload is 50 MB (zipped, including layers); for container images, it is 250 MB.
Event source mappings are used for polling-based triggers like SQS and DynamoDB Streams, and are configured separately from push-based triggers.
These come up on the exam all the time. Here's how to tell them apart.
Synchronous Invocation
The caller waits for the Lambda function to finish
Used by API Gateway, AWS ALB (Application Load Balancer)
The function must return a response to the caller within the timeout
Asynchronous Invocation
The caller does not wait; it fires the event and continues
Used by S3, SNS, EventBridge
Lambda queues the event and may retry on failure; no response is returned to the caller
Lambda Function
Serverless: no infrastructure to manage
Pay per invocation (request + duration)
Maximum execution time of 15 minutes
Amazon EC2 Instance
You manage the underlying server (OS, patches)
Pay per hour (even when idle)
Can run indefinitely (no time limit)
Push-Based Trigger (S3, SNS)
Event source automatically invokes Lambda when an event occurs
No need to configure event source mapping
Lambda is called directly with the event payload
Polling-Based Trigger (SQS, DynamoDB Streams)
Lambda must poll the source for new data
Requires an event source mapping to be configured
Lambda uses the mapping to periodically check for new records and then invokes the function
Reserved Concurrency
Limits the maximum number of concurrent executions for a function
Prevents a function from consuming all available concurrency in an account
Does not pre-warm environments
Provisioned Concurrency
Pre-warms a specified number of execution environments
Eliminates cold starts for those environments
You pay for the pre-warmed environments even when there are no invocations
Lambda Function Handler
A specific function in your code that AWS calls when the function is invoked
Defined in the function configuration (e.g., 'index.handler')
Receives the event and context objects as arguments
Lambda Runtime
The environment (e.g., Python 3.12, Node.js 18) that executes your code
Provides APIs for logging, error handling, and lifecycle
Managed and updated by AWS; you only specify the runtime version
Event Source Mapping
A configuration that Lambda uses to poll a data source (SQS, DynamoDB, Kinesis)
Created via CreateEventSourceMapping API or the Lambda console
Lambda reads from the source and then invokes the function with batches of records
Trigger
A configuration that causes another AWS service to invoke Lambda directly
Set up in the source service’s console (e.g., S3 bucket notification) or Lambda console
The source service calls Lambda synchronously or asynchronously
Mistake
Lambda functions run on dedicated servers that I can log into via SSH
Correct
Lambda functions run on ephemeral, managed infrastructure. You cannot SSH into them. AWS automatically manages the underlying compute resources, and the function's environment is destroyed after execution (though it may be reused for subsequent invocations).
People who come from a traditional server background naturally assume there is a server they can access. AWS abstracts this entirely, which causes confusion for beginners.
Mistake
If my Lambda function times out at 15 minutes, I can just increase the timeout to 30 minutes
Correct
The maximum timeout is 900 seconds (15 minutes). You cannot exceed this limit. For tasks that require longer execution, you must use another service like AWS Step Functions or AWS Batch.
Users encounter the 15-minute limit when processing large files and assume they can configure their way out of it. AWS designed this limit to prevent runaway functions from consuming excessive resources.
Mistake
Lambda functions can directly connect to an RDS database without any special configuration
Correct
If the Lambda function is inside a VPC, it cannot access the public internet or other services outside the VPC unless you add a NAT Gateway or VPC endpoints. Additionally, RDS databases in a VPC are not automatically reachable from Lambda, and you may need to configure the Lambda function to be in the same VPC subnet and security group.
Beginners assume that because Lambda lives 'in the cloud', it can reach any AWS service. Actually, VPC-enabled Lambda functions lose internet access, which is a common trap in exam questions.
Mistake
Lambda functions retain state between invocations because they are always running
Correct
Lambda functions are stateless by design. Each invocation starts with a fresh environment (unless the execution context is reused by a subsequent invocation, which is not guaranteed). You cannot rely on local variables persisting between invocations. Use external storage like DynamoDB or S3 for shared state.
New developers often write code that stores data in global variables expecting them to persist. They then encounter surprising behaviour when the next invocation sees different data or no data at all.
Mistake
All Lambda triggers work the same way — they just call the function directly
Correct
Triggers can be synchronous (API Gateway, ALB) or asynchronous (S3, SNS, EventBridge). Synchronous triggers wait for the function to finish and return a response. Asynchronous triggers fire and forget — Lambda queues the event and may retry on failure. The way you handle errors and responses differs significantly between these two modes.
The AWS documentation uses the word 'trigger' for both types, leading beginners to assume a one-size-fits-all approach. The exam specifically tests the distinction.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You can pass data by having the first function write to a shared resource like S3, DynamoDB, or SQS, and then the second function is triggered by that resource (e.g., an S3 event). Alternatively, you can use AWS Step Functions to orchestrate a sequence of Lambda functions and pass output from one to the next as input.
A cold start happens when a Lambda function has not been invoked for a while, and AWS needs to initialise a new execution environment (download the code, start the runtime, run initialisation code). This adds latency (often 1-5 seconds). Provisioned concurrency can pre-warm environments to avoid this.
Yes, you can invoke one Lambda function from another using the AWS SDK (e.g., boto3 for Python). However, this creates coupling. A better pattern is to use SQS or EventBridge to decouple them, so the first function sends a message and the second function processes it independently.
Synchronous invocation (used by API Gateway, ALB) waits for the function to finish and returns the result to the caller. Asynchronous invocation (used by S3, SNS) does not wait — AWS queues the event and the function runs in the background. The caller does not receive the function's response.
If your function is not inside a VPC, it has internet access by default. If you attach it to a VPC (for accessing RDS, for example), it loses internet access. To give it internet access, you must configure a NAT Gateway in the VPC's public subnet and route the Lambda function’s subnet traffic through it.
AWS forcefully terminates the function and returns a 'Task timed out' error. The function is charged for the time it ran up to the timeout limit. You must then increase the timeout (up to 900 seconds) or redesign the function to complete faster, possibly by breaking the work into smaller chunks.
You've just covered AWS Lambda: Functions, Triggers, and Event-Driven Architectures — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?