What is the default timeout for a Lambda function?

You've deployed a new Lambda function that calls a third-party payment gateway. It works fine in your local tests, but in production, it occasionally fails with a 'Task timed out' error after exactly 3 seconds. What is likely happening here, and how would you fix it?

Imagine you have a Lambda function that processes image uploads. If a user uploads a large file and the processing takes 10 seconds, what will happen if you deployed the Lambda with its out-of-the-box default settings? Where would you go to change this?

We have a Lambda function triggered by an API Gateway endpoint. Users are occasionally getting 504 Gateway Timeout errors, but when you check the Lambda logs, the function actually finishes successfully after 45 seconds. How do these two timeouts interact, and how would you resolve this mismatch?

You are debugging a system where a Lambda processes messages from an SQS queue. You notice in the logs that some messages are being processed three or four times, even though the Lambda eventually completes successfully. How does the Lambda timeout configuration relate to SQS visibility timeouts, and how would you fix this duplication?

We are designing a data ingestion pipeline where a Lambda function processes large CSV files from S3. As the business grows, some files are taking longer than 15 minutes to process, causing the Lambda to hard-fail. How would you re-architect this ingestion process to handle arbitrarily large files without running into Lambda's execution limits?

Your team wants to set a very generous timeout—say, 10 minutes—on all synchronous Lambda functions 'just in case' downstream databases are slow. What are the architectural, cost, and blast-radius implications of doing this under high-traffic conditions?

Our enterprise is migrating a legacy batch-processing system to AWS. Some of these legacy jobs run for hours. How would you design the decision framework and architectural guardrails to help engineering teams choose between Lambda, Step Functions, and ECS/Fargate based on execution limits and cost-efficiency?

We have a complex, distributed serverless application with hundreds of microservices. During a recent downstream database brownout, we experienced a cascading failure because upstream Lambdas kept retrying and holding connections open. How would you design a standardized timeout, retry, and circuit-breaker strategy at the platform level to prevent this?