Day 5 - Week 3 Review: Sharpening Your Instincts With Comprehensive Lambda Scenarios

A payment API Lambda function shows high latency during traffic surges. CloudWatch ConcurrentExecutions is in the normal range, and Duration P99 exceeds 3,000ms. What is the most likely cause and solution?

• AVPC ENI creation delay makes every invocation slow → detach Lambda from the VPC — after Hyperplane ENI there's no hot-path ENI creation, and ConcurrentExecutions is normal, so the cause doesn't match
• BDuring surges, new execution environments are created, causing cold starts → set Provisioned Concurrency
• CInsufficient memory causes GC/swap → raise MemorySize to 10GB — if memory were insufficient, you'd first see OOM errors and Max Memory Used saturation, but there's no such sign
• DIt's queued at the Reserved Concurrency ceiling → remove the Reserved setting — but then the Throttles metric should rise, whereas only Duration P99 spikes, which doesn't match the symptom

When an image is uploaded to S3, Lambda generates a thumbnail and saves it to the thumbnails/ directory of the same bucket. In operation, you discover Lambda is stuck in an infinite loop. What is the cause and solution?

• AThumbnail generation doesn't finish within the timeout, so the same object is reprocessed → raise the timeout to 900s — even with a longer timeout, the loop remains as long as the output triggers the input event again
• BWhen a file is saved to the thumbnails/ directory, a new S3 event fires and Lambda is invoked again → add a suffix filter (*.jpg) to the event notification and save the thumbnail with a different extension, or separate input/output buckets
• CInsufficient concurrency causes events to pile up in the retry queue and be invoked repeatedly → raise Reserved Concurrency to 1000 — increasing concurrency doesn't resolve the recursive structure where the output creates a new event
• DThe execution role lacks s3:PutObject, so the save is retried repeatedly → grant S3 full access to the role — if permission were the issue, it would fail immediately with AccessDenied rather than loop forever

In an order processing system, Lambda polls SQS to process orders. The batch size is 100, and one order failed due to an external API timeout. The remaining 99 also got reprocessed. How do you fix it?

• ASet a maxReceiveCount-based DLQ on the SQS queue to isolate failed messages — a DLQ only works after final failure and doesn't prevent the reprocessing of the other 99
• BSet the ESM's asynchronous retry count to 0 to turn off retries — SQS ESM is not asynchronous invocation, and this setting doesn't isolate partial failures
• CEnable ReportBatchItemFailures and implement Lambda to return only the failed message IDs in batchItemFailures
• DReduce the batch size from 100 to 1 to process messages one at a time — partial failure disappears, but invocation count grows 100× and it's inefficient

You're running Java Spring Boot on Lambda. Cold starts reach 3–5 seconds, violating the API response SLA. What is the cost-effective solution?

• AMaximize memory to 10GB to increase vCPU and accelerate INIT — CPU gets faster, but JVM class loading dominates, so the 3–5s cold start doesn't shrink enough and memory cost spikes
• BEnable Lambda SnapStart and deploy via a version/alias
• CSet Provisioned Concurrency to 1,000 to always keep warm instances — it works, but 1,000 PC far exceeds real traffic, so the cost is enormous
• DSwitch the runtime from Java to Node.js to reduce boot time — cold start improves, but it requires a full code rewrite, a large-scale refactor

You stored a DB password in a Lambda function's environment variables. The security team pointed out that this is encrypted only with the default KMS-managed key, so other teams in the account could potentially access it. What is the most effective solution?

• ABase64-encode the password before storing it in the environment variable to prevent plaintext exposure — Base64 is not encryption; anyone can decode it, so there's no security benefit
• BMove it to AWS Secrets Manager, or encrypt the environment variable with a per-team customer-managed KMS key (CMK)
• CDelete the environment variable and hardcode the password as a constant in the code, then restrict repository access — embedding the secret in source exposes it more broadly via git history and deployment packages
• DRemove KMS decrypt permission from the execution role to block other teams' access — this blocks environment variable decryption and makes the function itself non-functional

A team set Reserved Concurrency of 500 on a Lambda function. The account-wide concurrency limit is 1,000. The next day, another team's function got throttled due to a sharp traffic increase. What is the cause?

• AA code defect in the other team's function leaked concurrent executions, causing throttling — it's not a code problem but the structural cause that the shared pool was deducted
• BThe Reserved Concurrency setting of 500 shrank the account shared pool to 500, so the other functions could use only 500 in total
• CLambda concurrency limits are allocated independently per function/team, so one function's reservation doesn't affect another — in reality they share a single account/region pool
• DThe other team's function had no Provisioned Concurrency, so it couldn't withstand the burst — the absence of PC is only a cold-start issue, not a cause of throttling

A Lambda function polls Kinesis Data Streams, and in CloudWatch the IteratorAge metric is continuously increasing. What does it mean and how do you respond?

• AInsufficient function memory delays processing, raising the metric → increase MemorySize — memory can be one factor, but the root of rising IteratorAge is the throughput gap where consumption can't keep up with production
• BLambda is processing Kinesis stream records slower than they're produced → increase ParallelizationFactor, increase shard count, optimize the processing logic
• CThe Kinesis stream record retention period expired, growing the lag → extend retention to 7 days — retention is only the data-expiry point and is unrelated to IteratorAge (unprocessed lag)
• DThe ESM execution role lacks Kinesis read permission → grant KinesisFullAccess — if permission were lacking, polling would fail entirely rather than lag gradually increasing

Several Lambda functions use the same pandas and numpy libraries. Each function's ZIP size reaches 200MB, making deployment slow. How do you improve it?

• AMerge all functions into one large Lambda to package the dependencies just once — breaks single responsibility, increases complexity and blast radius, and deployment gets heavier
• BSeparate pandas and numpy into a Lambda Layer, and have each function contain only business logic
• CConvert all functions to container images (up to 10GB) and bake the libraries into the base image — it works but is overkill vs a layer, and container images can't also use a Layer
• DLower the function memory setting to reduce the deployment package size — MemorySize is a runtime resource and is entirely unrelated to ZIP size

How does it behave when Lambda Destinations and a DLQ are configured at the same time?

• ADLQ has higher priority than Destinations, so failure events are sent only to the DLQ — the actual priority is the opposite; Destinations supersede the DLQ
• BIf Destinations OnFailure is configured, the DLQ is ignored
• CBoth settings apply, so the same failure event is duplicated to both the DLQ and Destinations — only Destinations applies, so there is no duplicate delivery
• DThe configuration conflict makes Lambda throw a ConfigurationError, requiring you to keep only one — both can be configured, and Destinations takes precedence with no conflict error

A Lambda function's code creates the DB connection inside the handler function. The operations team reports that a surge in DB connection count causes RDS Connection Limit errors. What is the most effective solution?

• AReduce Lambda memory to suppress the number of concurrently active execution environments — memory is unrelated to connection count and only lowers throughput
• BMove the DB connection code outside the handler (global scope), or use Amazon RDS Proxy
• CSet Reserved Concurrency to 1 to force a single concurrent connection — it prevents the connection surge but effectively serializes processing, collapsing throughput
• DIncrease the RDS instance size to raise the max_connections limit — it only raises the limit while the inefficient connection-creation pattern remains, so it's not a root fix

What is the maximum event age of a Lambda asynchronous invocation?

• A1 hour
• B6 hours
• C24 hours
• D7 days

A Lambda function needs to access an internal on-premises database. This DB is only reachable over a VPN connection. How do you configure it?

• AIssue a Lambda Function URL and communicate with the on-premises DB through that endpoint — a Function URL is just an inbound HTTPS endpoint exposing the function to the internet, not an outbound path to the internal network
• BAssign an Elastic IP directly to the Lambda function to pass through the VPN tunnel with a fixed IP — you can't attach an EIP to Lambda, and an outbound fixed IP is only possible via VPC+NAT
• CAttach Lambda to a VPC, and connect the on-premises network to the VPC via Direct Connect or Site-to-Site VPN
• DGrant appropriate IAM permissions to the Lambda execution role, and AWS will auto-configure the VPN to on-premises — IAM is only permission control and cannot create a network path