SAA-C03 Design High-Performing 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.

• ✗

  A larger deployment package

  Why it's wrong here

  A larger deployment package is incorrect because packaging more code or dependencies into the Lambda function increases the time required to download and unpack the deployment artifact during a cold start. This directly worsens latency rather than mitigating it, and it does nothing to pre-initialize execution environments or handle traffic spikes. Even if the function logic itself is large, the fundamental problem remains that new instances must be created from scratch when demand surges.

• ✗

  Reserved concurrency only

  Why it's wrong here

  Reserved concurrency alone is incorrect because it only sets a limit on the number of concurrent executions and reserves capacity for your function, preventing throttling due to regional limits. It does not, however, pre-initialize any execution environments, so every new instance invoked during a spike still experiences a cold start with the attendant latency penalty. Reserved concurrency is a governance and capacity-planning tool, not a performance optimization for reducing initialization delay.

• ✓

  Provisioned concurrency during campaign windows

  Why this is correct

  Provisioned concurrency is correct because it keeps a specified number of Lambda execution environments fully initialized and ready to handle requests immediately, thereby eliminating cold-start latency for traffic within the provisioned capacity. By configuring it only during campaign windows, you align the pre-warmed capacity with predictable traffic surges, which both improves response times and controls cost since you are not paying for idle provisioned concurrency outside those windows. This directly addresses the unpredictable spikes by turning them into a scheduled, managed pattern.

• ✗

  CloudTrail data events

  Why it's wrong here

  CloudTrail data events are incorrect because they are used solely for auditing and recording API activity, such as object-level operations in S3 or Lambda invocations, and have no operational effect on Lambda's runtime performance. Enabling data events does not alter the execution environment lifecycle, nor does it reduce cold-start latency or increase concurrency. It simply adds logs for governance and security analysis, making it irrelevant to the performance problem described.

Go deeper

Related to this question