SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company runs a nightly batch job on a single Amazon EC2 instance that reads 2 TB of data from Amazon S3, transforms it, and writes results back to S3. The job currently takes 9 hours and must finish within a 4-hour maintenance window. The instance is a compute-optimized type with 10 Gbps network bandwidth, and CloudWatch shows the CPU is never above 35%. Which change should a solutions architect make to shorten the runtime?

⚠ Common exam trap

The trap here is reading 10 Gbps network bandwidth and assuming the instance is already network-saturated, when a single sequential reader rarely achieves that ceiling without concurrent requests.

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

✓

Redesign the job to process data in parallel across multiple EC2 instances using S3 multipart uploads and range-based GET requests.

Low CPU utilization with high data volume points to a network and concurrency bottleneck rather than insufficient compute. Sharding the dataset and processing shards concurrently across multiple instances multiplies aggregate S3 bandwidth, and range-based GETs with multipart uploads let each worker fully use its network path. Vertical scaling and Transfer Acceleration leave the sequential processing model intact.

Answer analysis

Option-by-option breakdown

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

✗
Move the job to an AWS Lambda function with 10 GB of memory and a 15-minute timeout.
Why it's wrong here
AWS Lambda caps execution at 15 minutes and provides limited local storage, so a 9-hour batch job processing 2 TB cannot run as a single invocation. Refactoring into many short invocations is possible but is a major rewrite, not a tuning change, and the per-invocation overhead for 2 TB of data would be significant. This option does not straightforwardly shorten the runtime within the maintenance window.
✗
Change the instance type to a larger compute-optimized size with 25 Gbps network bandwidth and keep the single-instance design.
Why it's wrong here
A larger instance raises the per-instance network ceiling, which helps, but the job still runs as a single sequential process and the achievable throughput may be limited by request concurrency and connection count rather than raw bandwidth. Scaling vertically also caps out at the largest available size, whereas the workload is embarrassingly parallel. Parallelizing across instances delivers a larger and more predictable reduction in runtime.
✓
Redesign the job to process data in parallel across multiple EC2 instances using S3 multipart uploads and range-based GET requests.
Why this is correct
The instance is CPU-idle and network-bound, so the bottleneck is throughput to and from S3 rather than compute. Partitioning the dataset and processing shards concurrently across several instances multiplies aggregate bandwidth, and range-based GETs plus multipart uploads make full use of each instance's network path. This directly attacks the real constraint and can bring a 9-hour job within the 4-hour window.
✗
Enable S3 Transfer Acceleration on the bucket and rerun the job unchanged on the same instance.
Why it's wrong here
S3 Transfer Acceleration speeds up transfers over long geographic distances by routing through edge locations, and it helps most when clients are far from the bucket Region. Here the instance is already in a Region with high bandwidth to S3, so acceleration offers little benefit. It also does nothing to parallelize the transformation logic, leaving the sequential bottleneck in place and the runtime largely unchanged.

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 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question