Deletion Policies

DeletionPolicy and UpdateReplacePolicy on Individual Resources

DeletionPolicy decides what happens to a resource when its stack is deleted or it leaves the template; UpdateReplacePolicy decides the fate of the old copy when an update replaces it. Both take Delete (the default), Retain, or Snapshot for types that support snapshots (RDS 24 , EBS volumes, ElastiCache 24 , Redshift 24 , Neptune, DocumentDB 24 ); DeletionPolicy also takes RetainExceptOnCreate, which retains the resource except when the operation that created it rolls back. RDS clusters and stand-alone RDS instances default to Snapshot. This is the advice of cfn-lint 2,641 's I3011 in cfn-lint Setup, applied to the catalog table:

infra/catalog.yaml: the table, retained on delete and on replacementYAML
AWSTemplateFormatVersion: "2010-09-09"
Resources:
  BooksTable:
    Type: AWS::DynamoDB::Table
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      TableName: booknest-books
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions: [{AttributeName: id, AttributeType: N}]
      KeySchema: [{AttributeName: id, KeyType: HASH}]
Deploying the retained table, deleting the stack, and looking for the tableYAML
cfn-lint --include-checks I -- catalog.yaml && echo "cfn-lint: no findings"
aws cloudformation deploy --stack-name booknest-catalog --template-file catalog.yaml
aws cloudformation delete-stack --stack-name booknest-catalog
aws cloudformation wait stack-delete-complete --stack-name booknest-catalog
aws dynamodb list-tables --query TableNames --output json
Output
cfn-lint: no findings
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - booknest-catalog
[]

On AWS 24 the stack reaches DELETE_COMPLETE, BooksTable logs DELETE_SKIPPED, and the table stays, still billed, outside any stack, ready for a resource import (Drift and Import; not run here). LocalStack 4.13.1 63,725 ignores both attributes and deleted the table; release 4.14 added them. Retain every resource whose loss would lose data, and remember that a retained resource with a fixed name blocks the next deploy of the same template until you delete or import it.