SAA-C03 Design Cost-Optimized Architectures Practice Question

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 provisioned concurrency to 100 so that cold starts never occur, regardless of traffic patterns.

  Why it's wrong here

  Setting provisioned concurrency to a fixed 100 means you are billed for 100 initialized environments around the clock, even when no requests arrive during low-traffic periods. This creates significant idle cost without solving the actual problem, because any spike beyond 100 concurrent invocations will still trigger cold starts for the extra executions. Moreover, a static value ignores the predictable timing of campaign windows, so you pay for capacity even when it is not needed instead of aligning cost with demand.

• ✓

  Use Application Auto Scaling scheduled actions to increase provisioned concurrency on the Lambda alias before campaign windows and reduce it to a minimal baseline afterward.

  Why this is correct

  Application Auto Scaling scheduled actions let you define time-based policies on a Lambda alias, so provisioned concurrency is raised to a high value just before the campaign starts and lowered to a minimal baseline once it ends. During the campaign, requests are served by pre-initialized execution environments, eliminating the cold-start latency that would otherwise be noticeable. Because provisioned concurrency is billed while allocated even when idle, the schedule ensures you only pay for warm capacity during the actual spike window, not during all other hours.

• ✗

  Turn provisioned concurrency off permanently and rely on retries at the client side to mask cold starts.

  Why it's wrong here

  Disabling provisioned concurrency reintroduces cold starts for every new execution environment, and client-side retries do not remove the initialization delay—they only send the request again after a timeout, which degrades user experience and may cause duplicate processing. During a spike, the Lambda service has to initialize many new environments at once, and you can hit regional burst concurrency limits, leading to throttling errors that retries will only amplify by adding more load. This approach trades latency guarantees for cost savings, which is the opposite of what a latency-sensitive API requires.

• ✗

  Replace Lambda with a single always-on EC2 instance sized for peak demand to eliminate cold starts.

  Why it's wrong here

  Replacing Lambda with a single always-on EC2 instance sized for peak demand means you pay for compute capacity continuously, even when traffic is near zero, which is usually more expensive than paying only for Lambda invocations. That instance is also a single point of failure: if it fails or needs patching, the API goes down completely, and it cannot handle traffic beyond its fixed size without you manually intervening. In contrast, scheduling provisioned concurrency on Lambda gives you the same low-latency behavior during spikes while preserving the serverless benefits of automatic scalability and no idle cost.

Go deeper

Related to this question