AWS Lambda — Interview & Certification Prep

Serverless execution model

Lambda runs your function in response to events (an API request via API Gateway, a message on SQS, an S3 upload, an EventBridge rule) and scales automatically by running many concurrent invocations. You supply a handler function and a runtime; AWS manages the servers, patching and scaling. You pay per request and per GB-second of execution time, with no charge when idle. Lambda shines for glue logic, event processing and spiky workloads; long-running or stateful control belongs on containers/EC2.

• Event-triggered; scales by running many concurrent invocations
• Pay per request + GB-second; nothing when idle
• Great for glue/event processing; not for long-running stateful work

Exam tip: Lambda scales horizontally via concurrency and has a per-invocation timeout; long or stateful jobs belong on ECS/EC2. Billing is per request + GB-second.

Source: AWS docs — Lambda Developer Guide

Invocation types & event sources

Lambda is invoked in three ways. Synchronous: the caller waits for the response (API Gateway, direct Invoke) — the caller handles errors/retries. Asynchronous: the caller hands off the event and Lambda queues it, retrying on failure and sending failures to a dead-letter queue or destination (S3 events, SNS, EventBridge). Event source mapping: Lambda polls a stream/queue (SQS, Kinesis, DynamoDB Streams) and invokes with batches. The invocation type determines how errors and retries behave.

• Synchronous: caller waits and handles errors (API Gateway, Invoke)
• Asynchronous: Lambda queues + retries, DLQ/destination on failure (S3, SNS, EventBridge)
• Event source mapping: Lambda polls SQS/Kinesis/DynamoDB Streams in batches

Exam tip: Async invocations retry automatically and support a DLQ/destination; synchronous ones don't — the caller owns retries.

Source: AWS docs — Lambda Developer Guide

Memory, timeout, env vars & layers

You configure a function's memory (which also proportionally allocates CPU — more memory can make CPU-bound code run faster and sometimes cheaper), a timeout (max run time before it's killed), and environment variables (config, optionally encrypted with KMS — not a place for plaintext secrets; use Secrets Manager/Parameter Store). Layers package shared libraries/runtimes separately so multiple functions reuse them and deployment packages stay small.

• Memory setting also scales CPU — tune it for CPU-bound work
• Timeout caps run time; env vars for config (encrypt secrets via KMS/Secrets Manager)
• Layers share libraries across functions and shrink packages

Exam tip: More memory = more CPU. For secrets, use Secrets Manager/Parameter Store, not plaintext env vars.

Source: AWS docs — Lambda Developer Guide

Execution role & VPC access

Every function runs with an EXECUTION ROLE — an IAM role granting exactly what it needs (e.g. write CloudWatch Logs, read a DynamoDB table). By default a function runs in an AWS-managed network with internet access. Attach it to your VPC only when it must reach private resources (an RDS instance, an internal service); then it uses ENIs in your subnets and, to reach the internet or public AWS APIs, needs a NAT gateway or VPC endpoints. VPC attachment can add cold-start and networking considerations.

• Execution role = least-privilege IAM for what the function calls
• Attach to a VPC only to reach private resources (RDS, internal services)
• VPC-attached functions need NAT/endpoints for internet + public AWS APIs

Exam tip: A Lambda reaching a private RDS must be in the VPC; if it also needs S3/DynamoDB, add VPC endpoints (or it goes via NAT).

Source: AWS docs — Lambda Developer Guide

Comparison: Lambda vs EC2/containers

Lambda vs EC2/containers: Lambda is event-driven, scales to zero, requires no server management, and bills per request + duration — ideal for spiky, short, event-driven work. EC2/containers run continuously (you manage capacity), suit long-running, stateful, or steady high-throughput workloads, and can be cheaper at sustained high volume. Choose Lambda for glue, APIs with variable load and event processing; choose containers/EC2 for long-running services, predictable heavy load, or when you need full control of the runtime/network.

• Lambda: event-driven, scales to zero, no servers, per-request billing
• EC2/containers: always-on, stateful/long-running/steady, more control
• Spiky/short/event-driven ⇒ Lambda; long-running/steady/heavy ⇒ containers/EC2

Source: AWS docs — Lambda Developer Guide

Concurrency, cold starts & scaling

Each concurrent request runs in its own execution environment; Lambda scales by adding environments up to an account concurrency limit. A COLD START is the extra latency when a new environment initializes your code (worse for large packages or VPC-attached functions). RESERVED concurrency caps (and guarantees) how many concurrent executions a function can use — protecting downstream systems and other functions. PROVISIONED concurrency keeps environments pre-warmed to remove cold-start latency for latency-sensitive APIs.

• Scales by concurrent execution environments up to an account limit
• Cold start = init latency of a new environment
• Reserved concurrency caps/guarantees; provisioned concurrency pre-warms to avoid cold starts

Exam tip: Latency-sensitive API with cold-start pain → PROVISIONED concurrency. Protect a downstream DB from a Lambda flood → RESERVED concurrency.

Source: AWS docs — Lambda Developer Guide

Retries, DLQ/destinations & idempotency

Failure handling depends on the source. Async invocations retry automatically and send exhausted events to a dead-letter queue or on-failure destination. SQS event source mappings return failed messages to the queue, which retry and eventually go to the queue's DLQ. Because events can be delivered more than once (at-least-once), your function should be IDEMPOTENT — processing the same event twice must not double-charge or duplicate work (e.g. dedupe on an idempotency key).

• Async: auto-retry then DLQ/destination; SQS: reprocessing then queue DLQ
• Delivery is at-least-once — design idempotent handlers
• Use an idempotency key/dedupe to make retries safe

Exam tip: At-least-once delivery means idempotency is your responsibility; a DLQ captures messages that keep failing.

Source: AWS docs — Lambda Developer Guide