AWS DVA-C02 Drill: CloudFormation DeletionPolicy - Stack Protection vs. Resource Retention

Jeff’s Note

#

Jeff’s Note

“Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.”

“For DVA-C02 candidates, the confusion often lies in mixing up DeletionPolicy (resource-level) with Stack Policy (operation-level). In production, this is about knowing exactly which CloudFormation attribute controls what happens when you update or delete your infrastructure-as-code. Let’s drill down.”

The Certification Drill (Simulated Question)

#

Scenario

#

TechFlow Solutions uses Infrastructure-as-Code to manage their product catalog API. A single CloudFormation template provisions their EC2-based application servers and a PostgreSQL database on Amazon RDS. The DevOps team deploys this stack across sandbox, staging, and production environments using parameter overrides.

Last week, a junior developer ran aws cloudformation update-stack against the development environment to modify an EC2 instance type. Due to a template error, the RDS database resource was inadvertently replaced, causing the development database to be dropped and recreated. Three days of test data and schema migrations were lost, blocking the QA team.

The Requirement

#

Implement CloudFormation-native safeguards to prevent accidental database deletion or replacement during future stack updates, while maintaining the ability to update other resources like EC2 instances.

The Options

#

• A) Add a CloudFormation DeletionPolicy attribute with the Retain value to the database resource
• B) Update the CloudFormation stack policy to prevent updates to the database
• C) Modify the database to use a Multi-AZ deployment
• D) Create a CloudFormation stack set for the web application and database deployments
• E) Add a CloudFormation DeletionPolicy attribute with the Retain value to the stack

Correct Answer

#

Options A and B.

Quick Insight: The Developer’s IaC Safety Net

#

For DVA-C02 Developers: This tests your understanding of CloudFormation’s dual-layer protection model:

1. DeletionPolicy (resource attribute): Controls what happens to the actual AWS resource when removed from template
2. Stack Policy (stack-level JSON document): Controls which template updates are even allowed to execute

Both work at different layers of the IaC lifecycle—and both are required here.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answers

#

Options A and B

The Winning Logic

#

Option A: DeletionPolicy with Retain

• The DeletionPolicy: Retain attribute on the RDS resource prevents the physical database from being deleted when:
  • The resource is removed from the CloudFormation template
  • The entire stack is deleted
• Developer Implementation Detail: This is a resource-level attribute added directly to the RDS::DBInstance definition in your template:

Resources:
  ProductionDatabase:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Retain
    Properties:
      DBInstanceIdentifier: techflow-prod-db
      Engine: postgres
      # ... other properties

• Critical Behavior: Even if you delete the stack, the RDS instance remains in your AWS account (orphaned but accessible). You must manually delete it via Console/CLI if truly needed.

Option B: Stack Policy to Prevent Updates

• A Stack Policy is a JSON document that defines which resources can be updated during update-stack operations
• Developer Implementation Detail: You set this via the AWS CLI or SDK:

aws cloudformation set-stack-policy \
  --stack-name techflow-infrastructure \
  --stack-policy-body file://stack-policy.json

stack-policy.json:

{
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "LogicalResourceId/ProductionDatabase"
    },
    {
      "Effect": "Allow",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "*"
    }
  ]
}

• Why This Matters: This prevents any template changes to the database resource from being applied, even if you modify the template. The update operation will fail with a StackPolicyViolation error.

The Dual-Layer Protection Strategy:

• DeletionPolicy: Safety net for deletion/removal scenarios
• Stack Policy: Proactive barrier against updates that could trigger replacement
• Together they cover both accidental deletion AND update-triggered replacement (the actual cause of the incident)

The Trap (Distractor Analysis)

#

Why not Option C (Multi-AZ Deployment)?

• Multi-AZ provides high availability for database failover, not deletion protection
• The RDS instance would still be deleted/recreated if the CloudFormation resource is replaced
• This is a runtime availability feature, not an IaC safety mechanism
• Dev Exam Tip: Multi-AZ appears in distractors when the question is about operational safety, but the actual issue is IaC lifecycle management

Why not Option D (CloudFormation StackSets)?

• StackSets are for multi-account/multi-region deployment, not resource protection
• This would add complexity without solving the deletion problem
• The incident occurred in a single-account, single-region scenario
• API Reality: StackSets use the same underlying CloudFormation engine—no additional safety guarantees

Why not Option E (DeletionPolicy on Stack)?

• Critical Misconception: DeletionPolicy is a resource-level attribute, not a stack-level attribute
• There is no such thing as a DeletionPolicy on the stack itself in CloudFormation syntax
• This is a fabricated option designed to test if you understand where DeletionPolicy is applied
• Exam Pattern: AWS loves to test the “scope” of attributes (resource vs. stack vs. account level)

The Technical Blueprint

#

CloudFormation Template Implementation

#

AWSTemplateFormatVersion: '2010-09-09'
Description: 'TechFlow Infrastructure with Database Protection'

Resources:
  # Application Server (Can be updated freely)
  WebServerInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref InstanceTypeParameter
      ImageId: ami-0abcdef1234567890
      # ... other properties

  # Protected Database with DeletionPolicy
  ProductionDatabase:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Retain  # ← Prevents physical deletion
    UpdateReplacePolicy: Retain  # ← Also prevents replacement scenarios
    Properties:
      DBInstanceIdentifier: techflow-catalog-db
      Engine: postgres
      EngineVersion: '15.4'
      DBInstanceClass: db.t3.medium
      AllocatedStorage: 100
      MasterUsername: !Ref DBUsername
      MasterUserPassword: !Ref DBPassword
      BackupRetentionPeriod: 7

Parameters:
  InstanceTypeParameter:
    Type: String
    Default: t3.medium
    Description: EC2 instance type for web servers
  
  DBUsername:
    Type: String
    NoEcho: true
    Description: Database admin username
  
  DBPassword:
    Type: String
    NoEcho: true
    Description: Database admin password

Outputs:
  DatabaseEndpoint:
    Description: RDS database endpoint
    Value: !GetAtt ProductionDatabase.Endpoint.Address
    Export:
      Name: !Sub '${AWS::StackName}-DBEndpoint'

Stack Policy Deployment Command

#

# Create the stack with protection
aws cloudformation create-stack \
  --stack-name techflow-infrastructure \
  --template-body file://infrastructure.yaml \
  --parameters \
    ParameterKey=InstanceTypeParameter,ParameterValue=t3.medium \
    ParameterKey=DBUsername,ParameterValue=admin \
    ParameterKey=DBPassword,ParameterValue=SecurePass123!

# Wait for stack creation
aws cloudformation wait stack-create-complete \
  --stack-name techflow-infrastructure

# Apply stack policy to prevent database updates
aws cloudformation set-stack-policy \
  --stack-name techflow-infrastructure \
  --stack-policy-body '{
    "Statement": [
      {
        "Effect": "Deny",
        "Action": "Update:*",
        "Principal": "*",
        "Resource": "LogicalResourceId/ProductionDatabase"
      },
      {
        "Effect": "Allow",
        "Action": "Update:*",
        "Principal": "*",
        "Resource": "*"
      }
    ]
  }'

# Verify stack policy is applied
aws cloudformation get-stack-policy \
  --stack-name techflow-infrastructure

The Comparative Analysis

#

Developer Performance Note: DeletionPolicy and Stack Policy are metadata-only features with zero runtime performance impact. They only affect CloudFormation API behavior during update/delete operations.

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For the DVA-C02 exam, always combine DeletionPolicy: Retain for deletion scenarios with Stack Policy Deny statements for update scenarios when protecting stateful resources like RDS or S3.”

Real World

#

“In enterprise production environments, we extend this pattern with:

1. Automated Stack Policy Application: Use CDK or Terraform to automatically apply stack policies in CI/CD pipelines:

// AWS CDK Example
const stack = new cdk.Stack(app, 'ProductionStack');
const db = new rds.DatabaseInstance(stack, 'Database', {
  // ... properties
});

// Apply protection via CDK escape hatch
const cfnDb = db.node.defaultChild as rds.CfnDBInstance;
cfnDb.cfnOptions.deletionPolicy = cdk.CfnDeletionPolicy.RETAIN;

2. Change Request Integration: Stack policy updates require approval in ServiceNow/Jira before the set-stack-policy command executes

3. Snapshot-Before-Delete: Combine DeletionPolicy with automated RDS snapshot creation using Lambda on CloudFormation custom resources

4. Detective Controls: CloudWatch Events trigger alerts when:

   • UpdateStack API calls target protected stacks
   • DeleteStack is called on production stacks
   • Stack policy violations occur

The Real Failure Mode: The incident in the scenario happened because there was NO stack policy. A developer changed the RDS DBInstanceClass property, which triggers a replacement (CloudFormation creates new instance, then deletes old one). The DeletionPolicy would have at least saved the old database even after replacement.”

Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam. Always refer to the official AWS documentation for the most current CloudFormation best practices and DeletionPolicy behaviors.