ある企業は CloudFormation を使用して本番環境の RDS データベース・ALB・EC2 Auto Scaling グループを 1 つのスタックで管理しています。以前のスタック更新時に担当者が誤ってパラメータを変更し、RDS インスタンスが置換（削除→再作成）されてデータが失われる事故が発生しました。今後は RDS インスタンスへの更新・削除・置換をすべてブロックしつつ、他のリソース（EC2 Auto Scaling グループ・ALB など）は引き続き更新できるようにしたいと考えています。最も適切な対策はどれですか？
CloudFormation スタックポリシーは JSON 形式のポリシーで、スタック更新時に特定リソースへの変更アクション（Update:Modify・Update:Replace・Update:Delete を包含する Update:*）を Allow/Deny で制御できます。デフォルト全許可をベースに RDS の論理リソース ID だけを Deny にすることで、他リソースの更新は維持しながら RDS のみを保護できます。 選択肢A の RDS リソース定義に DeletionPolicy: Retain を設定する方法は、スタック削除またはリソース置換が発生した際に物理リソースを残す設定であり、スタック更新による変更実行そのものは防げません。 選択肢C の RDS リソース定義に UpdateReplacePolicy: Retain を設定する方法は、置換時に旧リソースを保持する設定ですが、置換・変更の実行自体を阻止するものではありません。 選択肢D の AWS Config ルールと自動修復アクションを使用する方法は、変更後の検知・修正であり、スタック更新をリアルタイムにブロックする用途には適しません。