AWS DVA-C02 Drill: CloudFormation Updates - DynamoDB Table Replacement Behavior

Jeff’s Note

#

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

For AWS DVA-C02 candidates, the confusion often lies in how CloudFormation treats resource renames and the default deletion behavior. In production, this is about knowing exactly whether CloudFormation preserves existing data or replaces infrastructure when logical names or physical names change. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

An engineering team at FinNova Software manages their cloud infrastructure using AWS CloudFormation. They have a stack that includes an Amazon DynamoDB table named CustomerRecords. During a recent update, a developer mistakenly changed the DynamoDB table’s Logical ID in the CloudFormation template to ClientRecords, but did not specify any DeletionPolicy attributes for the resources, so the default applies.

The Requirement:

#

Understand the impact of this accidental name change on the existing DynamoDB table and any new tables after deploying the stack update.

The Options

#

• A) CloudFormation will create a new DynamoDB table named ClientRecords and delete the existing table named CustomerRecords.
• B) CloudFormation will create a new DynamoDB table named ClientRecords and keep the existing CustomerRecords table intact.
• C) CloudFormation will overwrite the existing DynamoDB table and rename it from CustomerRecords to ClientRecords.
• D) CloudFormation will keep the existing DynamoDB table and will not create a new table named ClientRecords.

Google adsense

#

leave a comment:

Correct Answer

#

A

Quick Insight: The DVA-C02 Imperative

#

• CloudFormation treats a change in the Logical ID of a resource as deleting the old resource and creating a new one.
• By default, the DeletionPolicy is Delete which means the old DynamoDB table will be deleted (including all contained data) unless the policy is explicitly overridden.
• This behavior highlights the importance of applying protective DeletionPolicies if you want to retain data during stack updates.

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 Answer

#

Option A

The Winning Logic

#

In AWS CloudFormation, each resource is identified by a Logical ID in the template. Changing this Logical ID makes CloudFormation interpret it as a brand-new resource creation and a deletion of the old resource.

• Since DynamoDB is stateful, losing the original resource means the table and its data will be deleted by default because the DeletionPolicy attribute is set to the default Delete.
• CloudFormation will therefore create a new table with the new Logical ID (ClientRecords) and remove the old table (CustomerRecords).
• There is no rename or overwrite mechanism. DynamoDB tables are created and destroyed independently.
• To preserve the table, one would have to set a DeletionPolicy: Retain or export/import data manually before the update.

The Trap (Distractor Analysis):

#

• Why not B?
  CloudFormation does not keep the old resource if Logical ID changes unless a DeletionPolicy Retain is set. By default, the old table will be deleted.

• Why not C?
  CloudFormation does not rename or overwrite existing physical resources just by changing Logical IDs; it deletes old resources and creates new ones.

• Why not D?
  Changing the Logical ID signals a new resource. A new table will be created, and the old one deleted due to default policies.

The Technical Blueprint

#

# CloudFormation deploy CLI example for updating a stack
aws cloudformation deploy \
  --template-file updated_template.yaml \
  --stack-name FinNovaStack \
  --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM

Notes:

• Unless the template includes a DeletionPolicy: Retain on the DynamoDB resource, the previous table will be deleted.
• Logical ID changes force deletion + recreation.

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick Option A when you see a Logical ID change without an explicit DeletionPolicy.

Real World

#

In production, to avoid data loss when renaming DynamoDB tables in CloudFormation, you should:

• Use DeletionPolicy: Retain on the table resource.
• Export and import data manually if replacement is needed.
• Avoid changing Logical IDs for critical stateful resources without a migration plan.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the DVA-C02 exam.