AWS Lambda interview questions — practice quiz

AWS Lambda bills per request plus the compute time consumed, where compute time is calculated as the configured memory size multiplied by the execution duration in milliseconds. The deployment package size, S3 storage, event payload size, and concurrency settings do not directly factor into the per-invocation cost formula.

AWS Lambda is the serverless compute service that runs code in response to events without requiring you to provision or manage servers, and it bills based on actual execution duration metered in milliseconds. Amazon EC2 provides virtual servers that you must provision and pay for while they run, Amazon EBS is block storage rather than a compute runtime, and AWS CloudFormation is infrastructure-as-code that provisions resources but does not execute your application code.

AWS Lambda enforces a hard maximum of 15 minutes (900 seconds) per invocation, and the function's configured timeout cannot be set above that limit. If an invocation runs longer than its timeout, Lambda terminates it. The answer is an open fact, so a short free-text answer is the right format.

AWS Lambda is a serverless compute service. You upload your code and Lambda automatically handles provisioning, scaling, and operating the underlying servers, which is the defining characteristic of serverless computing. The statement therefore holds, so the answer is true.

This is true. Lambda is one of the supported destinations for Amazon S3 event notifications. When you configure a notification on an S3 bucket for events like object creation, S3 sends the event to Lambda, which invokes your function automatically.

Lambda runs each invocation inside an execution environment, and it reuses that environment for later invocations (warm starts). Because the environment persists, module-level variables keep their values, and the initialization code outside the handler runs only when the environment is created, not on each reused invocation. Lambda does not guarantee a new environment per invocation, since environments are reused whenever available. Concurrent requests are handled by separate execution environments, each processing one event at a time, so global state is not shared across concurrent invocations.

SnapStart takes a snapshot of the function's initialized state after the init phase and restores that snapshot for new execution environments, so the init code does not run again on each cold start. The feature launched for the Java runtime family because JVM startup and class loading made Java cold starts especially slow. A correct answer must name both the snapshot-and-restore mechanism and the Java runtime family.

AWS Lambda allows you to configure a function timeout between 1 second and 15 minutes (900 seconds). If the function does not complete within the configured timeout, Lambda terminates it and returns a timeout error. For workloads that need more than 15 minutes, you must split the work across multiple invocations or use a different compute service such as AWS Fargate or EC2.

AWS Lambda applies a default timeout of 3 seconds to every newly created function. This is deliberately conservative so that runaway invocations are stopped quickly and unexpected cost is minimized. The timeout can be increased up to a hard ceiling of 15 minutes (900 seconds), but 3 seconds is the out-of-the-box default.

AWS Lambda supports two primary invocation modes. RequestResponse (the default) is synchronous: the caller blocks and receives the function's return value. Event is asynchronous: the API immediately returns a 202 Accepted and the event is queued for processing, so the caller does not wait for, nor receive, the function's result. Failed asynchronous invocations are retried under the function's async retry configuration.

Lambda has no separate CPU setting. The only resource you configure is memory, and Lambda allocates CPU power proportionally to it, so raising the memory setting raises the available vCPU share. Because a CPU-bound function can finish faster with more vCPU, the higher memory setting can sometimes reduce total billed cost even though the per-millisecond rate is higher.

Provisioned concurrency pre-initializes a requested number of execution environments so that invocations routed to them skip the initialization code (the cold-start phase) and begin executing the handler immediately. Only invocations that fall within the provisioned level get this benefit — any surge beyond provisioned concurrency is served by on-demand environments that may still cold-start. It is independent of reserved concurrency (a hard cap on total concurrent executions), so the claim that it must be set equal to the function's reserved concurrency value is wrong. Billing is for the provisioned capacity over time, not per invocation, so the claim that you are billed only for invocations that actually use a pre-initialized environment is wrong. And the claim that it eliminates cold starts for every invocation of the function, including those that exceed the provisioned concurrency level, is wrong because the guarantee does not extend to invocations beyond the provisioned level.

Provisioned concurrency pre-initializes (warms) a fixed number of execution environments, so invocations up to the configured level skip cold-start initialization. The statement about billing for idle capacity is wrong because you pay for provisioned capacity whether or not it is invoked. Provisioned concurrency cannot be set on $LATEST; it must target a published version or an alias. Reserved concurrency is a separate feature that only caps concurrent executions without pre-warming, so the two are not the same setting.

The Lambda execution environment lifecycle has two phases: Init and Invoke. On a cold start, AWS creates a new environment and runs Init — loading the runtime and executing your code outside the handler (global/static initialization). On a warm start, the existing environment is reused so Init is skipped and the platform goes directly to the Invoke phase, where the handler is called with the event.

Code at module scope runs during the execution environment's initialization phase, which is the cold start. When Lambda reuses that warm environment for later invocations, it does not re-run module-level code, so the S3 client created at init persists and is reused by the handler. The statement describing a new client on every invocation contradicts this reuse. The statement about a single client shared across the whole account is wrong because execution environments are per function instance, not per account. The statement claiming the line is skipped on warm invocations and the client is recreated on return is wrong because the client is not rebuilt on return; it stays in memory for the environment's lifetime.

Cold start = the one-time cost of spinning up a new execution environment (init phase) when none is warm to reuse. The signal is whether the candidate knows the real levers: Provisioned Concurrency / SnapStart to pre-warm, slimmer packages and right-sized memory to shorten init, and moving reusable setup into the init phase. Naming Provisioned Concurrency as the only answer is shallow — it costs money around the clock, so the better engineers weigh it against optimizing the function itself.

Provisioned concurrency pre-initializes a fixed number of execution environments for a specific alias or version. Invocations up to that limit are served instantly from warm environments. Any invocation beyond the provisioned amount overflows to standard execution: Lambda spins up new environments on demand, so those invocations incur cold-start latency. They are not queued and not throttled while the unreserved pool has capacity, and they do not raise the provisioned limit; they simply draw from the account's unreserved concurrency pool. Throttling only occurs when total concurrent executions exceed the sum of all reserved concurrency allocations plus the unreserved pool, or when a function-level concurrency limit is hit.

SnapStart takes a snapshot after the Init phase, which includes static initializers, so a SecureRandom created there has its internal state frozen into the snapshot. When Lambda restores the snapshot to create new execution environments, Init is not re-run, so every restored environment shares the same generator state and emits identical values. The recommended fix is to use the Java runtime hooks (the CRaC Resource API) and re-create or reseed the SecureRandom in afterRestore, which runs after each restore. Lazily creating it inside the handler also avoids the stale state, but the runtime hook is the documented mechanism for this class of problem.

This is an open design question, so it is graded against its key points rather than one fixed answer. A strong answer sizes Kinesis shards from the 1,000 records/sec and 1 MB/sec per-shard limits to absorb 50,000 orders/sec. It uses a Kinesis event source mapping with parallelization factor 10, large batches, and a short batching window to drain the stream efficiently. Cold starts are addressed with provisioned concurrency managed by Application Auto Scaling, with reserved concurrency set at or above the provisioned amount. Zero data loss comes from bisect-on-error, bounded retries, and dead-letter queues, combined with idempotent writes because delivery is at least once. DynamoDB on-demand mode and BatchWriteItem handle write throughput, and the answer must note that BatchWriteItem does not support condition expressions. Monitoring uses CloudWatch metrics such as IteratorAge, with X-Ray for latency visibility.

Provisioned concurrency pre-warms execution environments to remove cold-start latency; it does not cap concurrency. The ceiling is reserved concurrency, here 100, and 80 is below that, so no invocation is throttled. The first 50 are served by already-initialized provisioned environments. The remaining 30 exceed the provisioned count, so Lambda creates on-demand environments for them; those invocations pay cold-start latency but run concurrently with the rest. The option claiming a limit of 150 is wrong because provisioned concurrency counts against reserved concurrency rather than adding to it. The option claiming the excess is throttled is wrong because the total stays under the reserved cap. The option claiming excess invocations are queued for warm environments is wrong because synchronous invocations overflow to on-demand environments rather than waiting for provisioned capacity.

Provisioned concurrency pre-warms a fixed number of execution environments (here 20) so those invocations start immediately, which addresses latency. Reserved concurrency is the hard ceiling on concurrent executions (here 100). When concurrent invocations exceed the provisioned count but stay under the reserved limit, Lambda creates on-demand environments for the overflow; those invocations can experience cold starts but are not throttled. Throttling happens only when concurrency would exceed the reserved limit. The statement about invocations beyond the provisioned count being throttled is wrong for that reason, the claim that provisioned concurrency raises the ceiling is wrong because reserved concurrency is the maximum, and reserved concurrency does not pre-warm anything.

Provisioned concurrency pre-initializes exactly the number of execution environments set in its configuration. While concurrent invocations stay at or below that number, each request lands on a warm environment and skips the init phase. Once concurrency exceeds the provisioned value, the overflow requests are served by on-demand environments that go through the standard initialization phase, which is a cold start. So the guarantee is capacity-bound: it covers only the first N concurrent requests, where N is the provisioned value, and does not cover all invocations regardless of concurrency.

When SnapStart restores a snapshot, the JVM heap — including the internal state of any RNG — is restored verbatim. Without intervention, two restored environments would continue from the identical RNG state and produce the same sequence of numbers. For Java, the Lambda runtime automatically patches java.security.SecureRandom (and the provider backing it) so that each restored environment yields cryptographically unique values. However, java.util.Random and other non-SecureRandom generators (e.g., ThreadLocalRandom) are NOT patched — their state is restored from the snapshot and they will produce duplicate sequences across restored environments unless the developer explicitly re-seeds them, for example via a SnapStart Restore hook (registered through the AWS Lambda Runtime Interface) or by re-initializing them on first invocation. The claim that both RNGs are automatically patched is wrong because only SecureRandom is patched. The claim that neither RNG is patched is wrong because SecureRandom is handled automatically; a Restore hook is only needed for the unpatched RNGs. The claim that the snapshot restore injects fresh OS entropy into both RNGs is wrong because the snapshot is a memory-level copy — fresh OS entropy is not mixed into the JVM's existing RNG state during restore; the runtime's SecureRandom patch is what provides uniqueness.

With SnapStart, Lambda captures the memory of the execution environment after the Init phase has finished, so a new environment is created by loading that snapshot rather than re-running static initializers or the handler constructor. The Restore phase then runs any registered runtime hooks, and Invoke starts only after Restore completes. The distractors fail for specific reasons: re-running Init contradicts the snapshot model, OS-level resources such as sockets and file descriptors are not part of a memory snapshot and must be re-established during Restore, and Restore hooks run before the first invocation, not after it.