A developer is creating an application that uses an AWS Lambda function to transform and load data from an Amazon S3 bucket. When the developer tests the application, the developer finds that some inv

Question

Options

• ACreate a schedule group in Amazon EventBridge Scheduler to invoke the Lambda function.
• BConfigure provisioned concurrency for the Lambda function to have the necessary number of
• CUse the $LATEST version of the Lambda function.
• DConfigure reserved concurrency for the Lambda function to have the necessary number of
• EDeploy changes, and publish a new version of the Lambda function.

• A
  4% (1)
• B
  83% (20)
• C
  4% (1)
• D
  8% (2)

Explanation

Provisioned concurrency (B) pre-warms Lambda execution environments so initialization code (library loading, client instantiation) runs during allocation time - not during invocations - eliminating cold starts and ensuring consistent, low-latency execution. Publishing a new version (E) is required because provisioned concurrency can only be configured on a published version or an alias, not on $LATEST.

Why the distractors are wrong:

• A (EventBridge Scheduler): A scheduling mechanism controls when Lambda is invoked, not how fast it initializes - it does nothing to eliminate cold starts.
• C ($LATEST version): Provisioned concurrency cannot be applied to $LATEST; you must publish a versioned snapshot first, making this the opposite of what's needed.
• D (Reserved concurrency): Reserved concurrency limits the maximum concurrent executions to reserve capacity for a function, but it does not pre-warm environments - cold starts still occur.

Memory tip: Think of it as two steps - "bake the cake, then keep it warm." Publishing a version (E) freezes the code into a deployable artifact, and provisioned concurrency (B) keeps environments hot so every invocation skips the oven entirely. Reserved concurrency is just a traffic cap, not a warmer.

No community discussion yet for this question.