あるチームが本番Lambda関数のコールドスタートを削減するためにプロビジョニング済み同時実行を設定した。Application Auto Scalingと組み合わせてビジネス時間帯（9時〜18時）に同時実行数を20に増やし、夜間は5に減らすスケジュールを設定した。しかし夜間の深夜2時に突然大量のリクエストが来たとき、プロビジョニング済み同時実行の20インスタンスでは処理しきれなかった。余剰リクエストはどのように処理されるか。

正解: C

プロビジョニング済み同時実行はコールドスタートなしで処理できるインスタンス数を保証するが、プロビジョニング数を超えたリクエストはエラーになるわけではなく、通常のLambdaのオンデマンド起動（コールドスタートが発生）で処理される（選択肢C）。これがプロビジョニング済み同時実行の重要な動作仕様。コールドスタートは発生するが、処理自体は成功する。プロビジョニング済み同時実行はコールドスタートの削減が目的であり、キャパシティの上限ではない。アカウント全体の同時実行上限を超えた場合はスロットリングになるが、その場合はReserved ConcurrencyやProvisionedの合計がアカウント上限を超えたときの話。選択肢Bのエラーはプロビジョニング済み数を超えた場合ではなくアカウント全体の同時実行上限を超えた場合。選択肢AのSQSへの自動バッファリングはLambda単体では起こらず、SQSトリガーを使った非同期呼び出しの場合の話。選択肢DのAPI GatewayキューイングはAPI Gatewayにそのような機能はない。