Courseiva

SAA-C03 Design Cost-Optimized Architectures Practice Question

A solutions architect is optimizing the cost of a serverless data-processing pipeline. The pipeline uses AWS Lambda functions that process messages from an Amazon SQS queue and write results to Amazon DynamoDB. The team observes that Lambda invocations spike unpredictably, DynamoDB is provisioned with high capacity that is often idle, and the SQS queue occasionally accumulates a large backlog. Which two changes will most directly reduce cost while preserving the pipeline's ability to handle bursts? (Choose two.)

⚠ Common exam trap

The trap here is treating Lambda tuning such as memory or reserved concurrency as a cost fix, when the predictable savings come from aligning DynamoDB billing to usage and cutting the number of billed invocations.

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

✓

Switch the DynamoDB table from provisioned capacity to on-demand capacity mode.

The two most direct cost levers are matching DynamoDB billing to actual traffic by using on-demand capacity, and reducing Lambda invocation count by batching SQS messages with long polling. Together they eliminate idle provisioned capacity and cut per-invocation charges, while both changes preserve the ability to absorb unpredictable bursts without throttling the pipeline.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Increase the Lambda function's memory allocation to shorten execution time.

    Why it's wrong here

    Raising memory can reduce duration and sometimes lower total cost, but it is not a reliable, direct cost reduction and may increase the per-millisecond rate. Without profiling, a larger memory setting can raise cost if the function does not finish proportionally faster, so it is not one of the two changes that most directly and predictably reduces spend here.

  • ✗

    Configure the Lambda function's reserved concurrency to a low fixed value to cap scaling.

    Why it's wrong here

    Reserved concurrency limits how many concurrent invocations a function can serve, which throttles processing rather than reducing unit cost. Capping concurrency during a backlog would slow the pipeline and could increase SQS message age, and it does nothing to lower the per-invocation or per-gigabyte-second charges that Lambda bills, so it does not reduce cost while preserving burst handling.

  • ✗

    Move the SQS queue to a FIFO queue to improve ordering and throughput.

    Why it's wrong here

    A FIFO queue enforces strict ordering and exactly-once processing but has lower default throughput than a standard queue and does not reduce Lambda or DynamoDB charges. Changing queue type addresses ordering guarantees, not cost, and could even constrain throughput during bursts, so it does not help meet the cost-reduction goal.

  • ✓

    Switch the DynamoDB table from provisioned capacity to on-demand capacity mode.

    Why this is correct

    On-demand capacity mode charges only for the read and write requests the table actually serves, so idle provisioned capacity no longer incurs cost. Because the pipeline's traffic is unpredictable and bursty, on-demand absorbs spikes without pre-provisioning, directly aligning spend with usage and eliminating charges for capacity that sits unused during quiet periods.

  • ✓

    Enable SQS long polling and batch multiple messages per Lambda invocation.

    Why this is correct

    Long polling reduces the number of empty ReceiveMessage calls, and processing messages in batches means fewer Lambda invocations for the same volume of work. Since Lambda bills per invocation plus execution duration, batching directly lowers the invocation count, which cuts cost while still draining a burst backlog efficiently during high-traffic periods.

Quick reference

Cloud Service Model Comparison

ModelYou ManageProvider ManagesExamples
IaaSOS, runtime, apps, dataHardware, hypervisor, networkingEC2, Azure VMs, GCP Compute Engine
PaaSApps and dataOS, runtime, middleware, hardwareElastic Beanstalk, Azure App Service
SaaSData and settings onlyEverything elseMicrosoft 365, Salesforce, Workday
FaaS / ServerlessFunction code onlyInfra, scaling, runtimeLambda, Azure Functions, Cloud Run
CaaSContainers and appsKubernetes, OS, hardwareEKS, AKS, GKE

About these practice questions

One of 935 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint

This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.