バージョン難易度 標準無料
開発チームは、本番環境で稼働中のLambda関数のコードと設定を、後から誰かが誤って$LATESTを更新しても影響を受けない形で「スナップショット」として固定し、いつでもそのスナップショットへロールバックできるようにしたい。この要件を満たす機能として最も適切なものを選べ。（単一選択）
- A関数のコードと設定を更新するたびにバージョンを発行（publish）し、発行済みの各バージョンを不変なスナップショットとしてARNで参照する。ロールバック時は目的のバージョン番号を参照先にする
- B本番トラフィックは常に
$LATESTのARNを直接参照するようにし、変更の都度$LATEST自体を注意深く更新して固定運用する - C関数のデプロイパッケージのZIPファイルをS3の別バケットへ手動でバックアップし、ロールバック時にそのZIPを新規関数として作り直す
- DCloudFormationのスタックを更新するたびに新しいスタックを作成し、常に複数のスタックを並行稼働させることでロールバックに備える
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
Lambdaで関数コードと設定を更新すると、常に$LATESTという可変（mutable）なバージョンが更新される。
$LATESTは常に最新の変更を反映するため、単体では「固定されたスナップショット」にはならない。
- バージョンを発行（publish）すると、その時点の
$LATESTのコード・設定（メモリ・環境変数・レイヤー参照等）を 不変（immutable）なスナップショットとして、一意な番号（1, 2, 3...）付きのARNで固定できる。 - 発行済みバージョンのコード・設定はその後変更されることがないため、そのバージョンのARNを参照している限り、
誰かが
$LATESTを更新しても影響を受けない。 - 過去の任意のバージョンへ切り戻す（ロールバック）際は、そのバージョン番号（またはそれを指すエイリアス）を参照先として設定し直すだけでよい。
- B
$LATESTは常に最新の変更を反映する可変ポインタであり、「後から誰かが誤って更新しても影響を受けない固定スナップショット」という要件を満たせない。 - C手動バックアップと関数の作り直しは運用が煩雑で即時性に欠け、Lambdaが標準機能として提供するバージョン管理の代替として非効率。
- Dインフラ全体を並行稼働させるのは過剰な複雑性とコストを伴い、Lambda関数単体のコード/設定の不変スナップショットという要件には直接対応しない。
ひっかけ： 「
$LATESTそのものを本番用の固定参照として使う（B）」は要件に反する。$LATESTは常に変化し得るため、
固定・不変なスナップショットが必要な場面ではバージョンの発行が必須である。AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）