SAP-C02 Design for New Solutions Practice Question

A company is deploying a serverless application using AWS Lambda. The application processes high-resolution images and stores them in Amazon S3. The processing time for each image is variable, but some images require more than 15 minutes to process. Lambda has a maximum execution time of 15 minutes. How can the company process these long-running image transformations?

⚠ Common exam trap

Watch out — candidates often assume Step Functions can extend Lambda's execution time by chaining functions, but each Lambda invocation still has a hard 15-minute limit, and Step Functions does not override that service quota.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use AWS Batch to run the image processing as a job on EC2 or Fargate.

AWS Lambda has a hard limit of 15 minutes per invocation, so images requiring more than 15 minutes cannot be processed within a single Lambda function. AWS Batch is designed for long-running, batch-oriented compute jobs and can run on EC2 or Fargate without any time limit, making it the correct choice for processing high-resolution images that exceed Lambda's timeout.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use AWS Step Functions to chain multiple Lambda functions, each processing a part of the image.
Why it's wrong here
Step Functions coordinates Lambda invocations but cannot extend any single function beyond its 15-minute limit; chaining partial transforms also breaks atomicity for whole-image operations. It is tempting because Step Functions is the standard orchestrator for multi-step serverless workflows, and would be correct where the task decomposes cleanly into sub-15-minute stages.
✓
Use AWS Batch to run the image processing as a job on EC2 or Fargate.
Why this is correct
AWS Batch has no 15-minute invocation limit, so it can run image transformations as jobs on EC2 or Fargate for as long as needed. This directly satisfies the stem's constraint that some images exceed Lambda's maximum execution time.
✗
Use Amazon SQS to queue the images and have Lambda poll the queue; the Lambda function can process one image per invocation.
Why it's wrong here
SQS decouples producers from consumers but each Lambda invocation still terminates at 15 minutes, so an image needing longer is killed mid-processing and retried indefinitely. Queuing suits smoothing bursts of short jobs, not extending runtime; the correct approach moves long transformations to a compute service without that invocation ceiling.
✗
Increase the Lambda timeout to 20 minutes.
Why it's wrong here
Lambda's maximum timeout is fixed at 15 minutes, so a 20-minute setting is rejected by the service and cannot extend execution. Raising the timeout is tempting because it appears the obvious configuration fix, and it would be correct for functions finishing just under the existing limit, not for transformations exceeding 15 minutes.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SAP-C02 Design for New Solutions Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question