Question 1

What is AWS Lambda?

Accepted Answer

Lambda runs your code in response to events without you provisioning or managing servers. You upload a function as a zip or container image, choose a runtime and memory, and Lambda handles provisioning, scaling from zero to thousands of concurrent executions, and availability. You are billed per request and per GB-second of execution. The framing to give is event-driven compute with no idle cost. Naming that CPU scales proportionally with configured memory — you cannot set them independently — is the detail that shapes almost every Lambda performance and cost decision.

Question 2

How does Lambda concurrency work?

Accepted Answer

Each concurrent execution handles exactly one request at a time — unlike a container that serves many. Concurrency is the number of executions running simultaneously, bounded by an account-level limit per region, defaulting to 1,000 and raisable. Lambda scales by adding execution environments up to that limit. The one-request-per-environment model is the single most important difference from Cloud Run or a container service, and it drives cost: an I/O-bound function pays for wall-clock time it spends waiting. That is why heavy I/O sometimes belongs in a container instead.

Question 3

What is reserved concurrency versus provisioned concurrency?

Accepted Answer

Reserved concurrency sets aside a portion of the account limit for a function and simultaneously caps it at that number — it both guarantees and limits. Provisioned concurrency pre-initialises a number of execution environments so they are warm and respond without cold-start latency, and it is billed for the time it is provisioned. Reserved concurrency is a protection mechanism in both directions: it stops one function starving others, and stops a function overwhelming a downstream database. Provisioned concurrency solves latency but removes the scale-to-zero cost benefit, which is the trade-off to name.

Question 4

What is a Lambda cold start and how do you reduce it?

Accepted Answer

A cold start is the latency of creating a new execution environment — downloading the code, starting the runtime and running initialisation — before the handler executes. Reduce it with provisioned concurrency, smaller deployment packages, lighter dependencies, doing expensive work in the init phase where it is billed differently, and choosing a faster runtime. The runtime difference is substantial: Node.js, Python and Go start in tens to low hundreds of milliseconds while a cold JVM or .NET function can take seconds, which is why SnapStart exists for Java. Naming SnapStart as the Java-specific answer shows currency.

Question 5

What is Lambda SnapStart?

Accepted Answer

SnapStart takes a snapshot of the initialised execution environment after the init phase and restores from it on invocation, dramatically reducing cold start for Java and now other runtimes. The trade-off is that anything captured in the snapshot — random seeds, cached connections, unique identifiers generated at init — is reused across restores. The uniqueness caveat is the substance: code that generates a random value or a connection at init will have the same one in every restored environment, which is a real correctness and security issue. Runtime hooks exist to reinitialise those values, and knowing that is the practical detail.

Question 6

How does the Lambda execution environment lifecycle work?

Accepted Answer

Three phases: init, where the runtime starts and code outside the handler runs; invoke, where the handler executes; and shutdown. Environments are reused for subsequent invocations, so global-scope state persists between calls on the same environment, and environments are eventually recycled. The practical consequence is that database clients and SDK clients should be created in global scope so they are reused, while request-specific data must never be stored there — a global variable holding user data leaks between invocations, which is a genuine security bug.

Question 7

What is the difference between synchronous and asynchronous Lambda invocation?

Accepted Answer

Synchronous invocation — API Gateway, ALB, direct SDK calls — returns the function's response to the caller, and errors are the caller's to handle with no automatic retry. Asynchronous invocation — S3, SNS, EventBridge — queues the event internally, returns immediately, and Lambda retries twice on failure before sending to a dead-letter destination. The two-retry default for async is the number interviewers check. Naming Lambda destinations, which route both success and failure outcomes to SQS, SNS, EventBridge or another function, is the modern improvement over the older dead-letter queue.

Question 8

What is an event source mapping?

Accepted Answer

For poll-based sources — SQS, Kinesis, DynamoDB Streams, Amazon MQ, Kafka — Lambda itself polls the source and invokes the function with batches. The event source mapping configures batch size, batch window, parallelisation factor, starting position, error handling and filtering. The distinction from push sources matters for error handling: with SQS, a failure returns the whole batch to the queue unless you use partial batch responses, which report only the failed message identifiers. Knowing ReportBatchItemFailures is a strong practical detail.

Question 9

How does Lambda scale with SQS?

Accepted Answer

Lambda polls the queue with an initial set of concurrent pollers and increases them as the backlog grows, up to the function's concurrency limit and the account limit. For standard queues it scales quickly; for FIFO queues concurrency is limited by the number of message group IDs, since ordering must be preserved per group. The FIFO limitation is the detail that surprises people: a FIFO queue with one message group processes strictly serially regardless of concurrency settings. Designing message group IDs for parallelism — per customer or per entity rather than one global group — is the fix.

Question 10

What happens when a Lambda function is throttled?

Accepted Answer

Synchronous invocations return a 429 TooManyRequestsException to the caller, which must retry. Asynchronous invocations are retried by Lambda with backoff for up to six hours. Poll-based sources keep the messages in the queue or stream and retry, so nothing is lost as long as retention allows. The differing behaviour by invocation type is the substance of the answer. The design consequence is that a synchronous API behind a throttled function returns errors to users immediately, which is why reserved concurrency and a queue-based buffer are the standard protections.

Question 11

How do you connect Lambda to resources in a VPC?

Accepted Answer

Configure the function with subnets and security groups; Lambda creates Hyperplane ENIs shared across execution environments, so VPC-attached functions no longer suffer the long cold starts they once did. The function then reaches private resources such as RDS and ElastiCache, but needs a NAT gateway or VPC endpoints to reach the internet or AWS services. The internet-access point is what catches people: attaching a function to a VPC removes its default internet access, so an outbound call to a third-party API suddenly fails. Using VPC endpoints for AWS services rather than routing everything through NAT is the cost-efficient answer.

Question 12

What are the main Lambda limits you should design around?

Accepted Answer

Maximum execution duration of 15 minutes; memory from 128 MB to 10,240 MB with CPU scaling proportionally; deployment package of 50 MB zipped direct upload, 250 MB unzipped, or 10 GB as a container image; 512 MB to 10 GB of ephemeral /tmp storage; 6 MB synchronous payload and 256 KB asynchronous; and a default concurrency limit of 1,000 per region. The 15-minute timeout is the one that shapes architecture: anything longer belongs in Fargate, Step Functions, Batch or a container. The 6 MB payload limit is why large data is passed by S3 reference rather than inline, which is the claim-check pattern.

Question 13

How does Lambda memory configuration affect performance and cost?

Accepted Answer

CPU, network bandwidth and disk throughput all scale proportionally with configured memory, so a CPU-bound function often runs faster and cheaper at higher memory — the shorter duration more than offsets the higher per-millisecond rate. AWS Lambda Power Tuning finds the optimal setting empirically. This counter-intuitive result is a favourite question: increasing memory can reduce total cost. Naming Power Tuning as the tool that measures it rather than guessing is what turns the insight into a practice.

Question 14

What is a Lambda layer and when would you use one?

Accepted Answer

A layer is a zip archive of libraries, a custom runtime or shared code that can be attached to multiple functions, extracted to /opt at runtime. Up to five layers per function count towards the unzipped size limit. Use them for shared dependencies across many functions. The honest caveat is that layers complicate versioning and local testing, and with container image packaging now available many teams skip them. Recommending them for genuinely shared, slow-changing dependencies rather than as a default is the balanced answer.

Question 15

What is the difference between packaging Lambda as a zip and as a container image?

Accepted Answer

Zip packaging is limited to 250 MB unzipped and uses AWS-provided runtimes. Container images support up to 10 GB, let you use any base image and tooling, and use the same build and registry workflow as your other containers. Both run on the same Lambda execution model. The container option is right for large dependencies such as machine-learning libraries, and for teams that want one build pipeline across Lambda and ECS. The trade-off is somewhat slower cold starts for very large images and the need to manage base image patching yourself.

Question 16

How do you make a Lambda function idempotent?

Accepted Answer

Use a stable business identifier from the event, record processed identifiers in DynamoDB with a conditional write so a duplicate fails, and check before performing side effects. Prefer naturally idempotent operations such as conditional puts over increments. AWS Lambda Powertools provides an idempotency utility that implements this. Idempotency is mandatory because every asynchronous and poll-based source delivers at least once, and retries are automatic. Naming Powertools shows familiarity with the current tooling rather than reimplementing the pattern by hand.

Question 17

What are Lambda destinations?

Accepted Answer

For asynchronous invocations, destinations route the outcome to SQS, SNS, EventBridge or another Lambda function — separately for success and failure — including the request payload, the response or error, and context. They replace dead-letter queues, which only captured the failed event without the error detail. The richer payload is the improvement: a dead-letter queue tells you a message failed, while a destination tells you why, which is the difference between an actionable alert and a mystery. Configuring an onFailure destination with an alarm is the production baseline.

Question 18

How do you handle secrets in Lambda?

Accepted Answer

Fetch from Secrets Manager or Parameter Store at init using the function's execution role, and cache the value in the execution environment so it is not re-fetched on every invocation. The Parameters and Secrets Lambda Extension provides that caching for you. Never put secrets in environment variables in plain text. The caching point matters for both cost and latency, since a Secrets Manager call on every invocation is charged and adds tens of milliseconds. Environment variables can be encrypted with KMS, but they are still visible in the function configuration to anyone with read access.

Question 19

What is a Lambda extension?

Accepted Answer

An extension runs as a separate process in the execution environment alongside your function, participating in the lifecycle, used for observability agents, secret caching, configuration and security tooling. Internal extensions run in the runtime process; external ones run independently and can continue after the handler returns. The practical examples are the Parameters and Secrets extension, and APM agents from observability vendors. The consideration to name is that an extension consumes memory and can delay shutdown, so it affects both cost and duration.

Question 20

How do you version and deploy Lambda safely?

Accepted Answer

Publish immutable versions and point an alias — such as "live" — at a version. Aliases support weighted routing, so you can shift a percentage of traffic to a new version and roll back by moving the alias. CodeDeploy automates canary and linear deployments with CloudWatch alarm rollback. The alias indirection is what makes rollback instant, since clients reference the alias rather than a version. Naming CodeDeploy's pre-traffic and post-traffic hooks, which run validation functions, is the detail that shows a real deployment pipeline.

Question 21

How is Lambda priced?

Accepted Answer

Per request and per GB-second of duration, measured in one-millisecond increments, with a generous perpetual free tier. Provisioned concurrency is charged for the time it is configured plus a lower duration rate. Additional charges apply for ephemeral storage above the default and for data transfer. The cost model rewards short, efficient functions and punishes long waits, which is why a function that blocks on a slow API call is expensive — you pay for waiting. That is a genuine argument for moving I/O-heavy workloads to a container model.

Question 22

When is Lambda the wrong choice?

Accepted Answer

For workloads longer than 15 minutes; for sustained high-throughput steady traffic where a container or instance costs less; for applications needing persistent connections or in-process state; for very latency-sensitive paths where cold starts matter and provisioned concurrency is uneconomic; and for heavy I/O-bound work where you pay for idle wait time. Being able to say when not to use it is what distinguishes an engineer from an enthusiast. The steady-high-traffic case is the most common real crossover — at sustained load, Fargate or EC2 with a Savings Plan is usually cheaper.

Question 23

How do you observe a Lambda function in production?

Accepted Answer

CloudWatch metrics for invocations, duration, errors, throttles, concurrent executions and, for poll sources, iterator age. CloudWatch Logs for structured output. X-Ray for distributed tracing across services. Lambda Insights for enhanced runtime metrics. Alert on error rate, throttles, duration approaching timeout and iterator age. Iterator age is the metric to name for stream sources because it measures how far behind you are — a growing age means you are permanently falling behind, which invocation count alone will not reveal. Duration approaching timeout is the leading indicator before failures start.

Question 24

What is the difference between Lambda and Fargate?

Accepted Answer

Lambda is event-driven with per-request billing, automatic scaling from zero, a 15-minute maximum and no persistent connections. Fargate runs containers continuously with per-second billing for allocated CPU and memory, supports long-running processes, any protocol, sidecars and persistent connections, but does not scale to zero by default. The decision axis is workload shape rather than preference: bursty and short favours Lambda, steady and long-running favours Fargate. Naming the crossover — where sustained traffic makes Fargate cheaper — is the quantitative half of the answer.

Question 25

How do you handle a Lambda function that must call a slow third-party API?

Accepted Answer

Do not block on it in a synchronous path. Queue the work in SQS with a Lambda consumer using reserved concurrency to rate-limit calls, set aggressive client timeouts, retry with exponential backoff and jitter, and add a circuit breaker so repeated failures fail fast. Return 202 to the original caller with a status mechanism. Reserved concurrency as a rate limiter is the AWS-specific mechanism — it caps how many calls hit the third party at once, which neither SQS nor the function alone provides. Naming that use of reserved concurrency for downstream protection rather than only for isolation is the insight.

Question 26

What is the Lambda function URL?

Accepted Answer

A function URL is a dedicated HTTPS endpoint for a Lambda function with built-in IAM or no authentication, supporting CORS configuration. It provides a simple HTTP entry point without API Gateway, at no additional cost beyond Lambda invocations. The trade-off against API Gateway is the substance: function URLs lack request validation, throttling per key, usage plans, WAF integration, custom domains without CloudFront, and caching. They suit webhooks and simple internal endpoints, not a public API.

Question 27

How do you handle database connections from Lambda?

Accepted Answer

Create the client in global scope so it is reused across invocations on the same environment, and cap total connections with reserved concurrency, since each concurrent execution holds its own connection. For RDS, use RDS Proxy, which pools and multiplexes connections so thousands of executions share a small pool. The arithmetic is the point: 500 concurrent executions each holding a connection will exhaust most RDS instances. RDS Proxy is the purpose-built answer and also handles failover transparently, which is the second benefit worth naming.

Question 28

What is RDS Proxy and why does it matter for serverless?

Accepted Answer

RDS Proxy is a managed connection pool that sits between applications and RDS or Aurora, multiplexing many client connections onto a smaller number of database connections, handling failover faster than DNS propagation, and enforcing IAM authentication. It exists specifically because serverless connection patterns broke traditional databases — many short-lived clients rather than a few long-lived pools. The failover improvement is the underrated second benefit: it reduces failover impact from a minute or more to seconds.

Question 29

How do you test Lambda functions?

Accepted Answer

Unit test the business logic separately from the handler by keeping the handler thin. Use SAM CLI or LocalStack for local invocation with sample events. Run integration tests against a real deployed function in a test account. Contract-test the event shapes, since malformed event assumptions are a common failure. The thin-handler design is the enabling practice: parse the event, call a plain function, format the response. That makes the vast majority of logic testable with no AWS involvement at all, which is what keeps a serverless codebase maintainable.

Question 30

What is AWS SAM and how does it relate to CloudFormation?

Accepted Answer

The Serverless Application Model is a CloudFormation extension with shorthand resource types for functions, APIs, tables and event sources, which transform into full CloudFormation at deploy time. The SAM CLI adds local invocation, guided deployment and log tailing. The comparison to make is with the CDK and the Serverless Framework: SAM is AWS-native and lightweight, the CDK offers general-purpose language abstraction, and the Serverless Framework is multi-cloud with a plugin ecosystem. Having a view on which fits a team is better than naming one as correct.

Question 31

What is the difference between EventBridge and SNS as a Lambda trigger?

Accepted Answer

SNS is pub/sub fan-out with topic-based routing and simple filter policies on message attributes. EventBridge routes on the full event content with rich pattern matching, supports schedules, a schema registry, archive and replay, and over a hundred SaaS and AWS sources. Archive and replay is the capability that most justifies EventBridge for an event-driven architecture: after fixing a consumer bug you can replay the events it mishandled. SNS remains simpler and lower-latency for straightforward fan-out.

Question 32

How do you implement a fan-out pattern with Lambda?

Accepted Answer

Publish to an SNS topic or EventBridge bus and subscribe multiple consumers. The robust variant is SNS to SQS to Lambda — each consumer gets its own queue, so a slow or failing consumer buffers independently, retries without affecting others, and has its own dead-letter queue. The SNS-to-SQS-to-Lambda pattern is the one to name because direct SNS-to-Lambda has limited retry behaviour and no buffering, so a downstream outage loses events. Per-consumer queues are what make fan-out resilient.

Question 33

What is a Lambda dead-letter queue and how does it differ from a destination?

Accepted Answer

A dead-letter queue receives the event payload after asynchronous retries are exhausted, giving you the input but no error context. An on-failure destination receives the payload plus the error, the response and invocation context, and supports more target types. Destinations are the current recommendation. Alerting on messages arriving in either is the operational requirement, because otherwise failures accumulate silently. Naming that a DLQ with no alarm is equivalent to dropping the events is the point that matters.

Question 34

How would you process a 10 GB file with Lambda?

Accepted Answer

Do not load it into memory. Either stream it with range requests and process in chunks within the 15-minute limit, or — better — split the work: a coordinator function lists byte ranges or splits the file, and many parallel functions each process a portion, with results aggregated. For genuinely large processing, use Fargate, Glue or EMR instead. Recognising that this may be the wrong tool is part of the answer. The map-reduce-style split is a legitimate Lambda pattern and Step Functions distributed map is the managed implementation, which is the specific service to name.

Question 35

What is Step Functions distributed map?

Accepted Answer

Distributed map is a Step Functions state that iterates over large datasets — millions of S3 objects or rows in a file — running up to ten thousand parallel child executions, each invoking a Lambda function or other task, with batching, error tolerance thresholds and result aggregation. It is the managed answer to large-scale parallel processing with Lambda, replacing hand-built coordinator functions that were fragile and hard to observe. The error-tolerance threshold — continue if fewer than N percent fail — is a genuinely useful feature for batch work.

Question 36

What is Lambda@Edge and how does it differ from CloudFront Functions?

Accepted Answer

Lambda@Edge runs Node.js or Python at CloudFront regional edge caches on viewer or origin request and response events, with up to 5 or 30 seconds of execution, network access and larger memory. CloudFront Functions run lightweight JavaScript at the edge location itself in under a millisecond, with no network access, for simple header and URL manipulation. The selection rule is latency and capability: CloudFront Functions for header rewrites, redirects and simple authorisation at very high volume and very low cost; Lambda@Edge when you need to call an origin or perform real logic. Naming the sub-millisecond constraint is what shows you know the difference.

Question 37

How do you reduce Lambda cost?

Accepted Answer

Right-size memory with Power Tuning, since higher memory can reduce total cost for CPU-bound work; shorten duration by removing blocking waits and moving them to Step Functions or async patterns; use ARM64 Graviton runtimes for better price-performance; avoid provisioned concurrency where cold starts are acceptable; batch event source records; and move sustained high-throughput workloads to Fargate. The Graviton switch is often a straightforward 20% saving with no code change for interpreted runtimes. The structural point is that paying for wait time is the main serverless anti-pattern, so replacing blocking calls with Step Functions wait states is a real optimisation.

Question 38

What is the difference between Step Functions Standard and Express workflows?

Accepted Answer

Standard workflows run up to a year, are billed per state transition, guarantee exactly-once execution and keep full execution history — suited to long-running business processes. Express workflows run up to five minutes, are billed by duration and memory, offer at-least-once semantics and much higher throughput — suited to high-volume, short-lived orchestration. The exactly-once versus at-least-once difference determines whether downstream steps must be idempotent, which is the design consequence rather than a pricing footnote. Naming the execution-history difference matters too, since Express requires CloudWatch Logs for observability.

Question 39

What is the Lambda function timeout and how should you choose it?

Accepted Answer

The timeout can be set from 1 second to 15 minutes and defaults to 3 seconds. Set it slightly above the realistic worst-case duration rather than at the maximum, so a hung invocation fails fast instead of burning fifteen minutes of billed time on every retry. A timeout set to the maximum "just in case" turns a stuck downstream call into an expensive, slow failure that also holds concurrency. Alarming on duration approaching the timeout is the leading indicator that lets you act before invocations start failing.

Question 40

Design a serverless image processing pipeline on AWS.

Accepted Answer

Clients upload directly to S3 with presigned URLs so bytes never pass through compute. The object-created event goes to EventBridge, which triggers a Lambda function that validates and enqueues work in SQS. A consumer Lambda — or Fargate for heavy processing — generates variants and writes them to a *separate* output bucket to avoid recursion, recording metadata in DynamoDB. CloudFront serves the output bucket with Origin Access Control. Handlers are idempotent on the object version identifier, with a dead-letter destination and alarms. The closing scenario. The senior markers are presigned direct upload, writing to a different bucket to prevent recursive invocation, keying idempotency on the object version rather than the key, and putting a queue between the trigger and the work so bursts are absorbed rather than throttled.

AWS Lambda & Serverless Interview Questions and Answers

How to use this set