How to Prevent CloudFormation from Resetting SSM Parameter Store Values on Stack Update?
A company's developer has deployed an application in AWS by using AWS CloudFormation. The CloudFormation stack includes parameters in AWS Systems Manager Parameter Store that the application uses as configuration settings. The application can modify the parameter values. When the developer updated the stack to create additional resources with tags, the developer noted that the parameter values were reset and that the values ignored the latest changes made by the application. The developer needs to change the way the company deploys the CloudFormation stack. The developer also needs to avoid resetting the parameter values outside the stack. Which solution will meet these requirements with the LEAST development effort?
Community Votes
62% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
This question tests understanding of how CloudFormation handles resource replacement during updates and how DeletionPolicy: Retain prevents CloudFormation from deleting and recreating resources (and thus resetting their values) when properties change.
When an application modifies SSM Parameter Store values outside of CloudFormation, stack updates can reset those values to their template-defined defaults. Setting the DeletionPolicy to Retain on the AWS::SSM::Parameter resource preserves the current values during stack updates with minimal development effort.
Many candidates choose Option D (stack policy to deny updates) because it sounds like it would protect the parameters. However, a stack policy that denies updates on SSM parameters will cause the entire stack update to fail if CloudFormation attempts to replace the resource, breaking the deployment workflow.
Community Discussion (12 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Understanding the Problem
The scenario describes a common anti-pattern: an application modifies SSM Parameter Store values at runtime, but those parameters are also managed by a CloudFormation stack. When the stack is updated (even for unrelated changes like adding tags to other resources), CloudFormation may detect a drift or attempt to reconcile the parameter values back to what is defined in the template, effectively resetting the application's runtime changes.
Why Option A is Correct
Option A — setting DeletionPolicy: Retain on the AWS::SSM::Parameter resource — is the correct answer with the LEAST development effort.
When CloudFormation updates a stack and determines that a resource needs to be replaced (deleted and recreated), the DeletionPolicy attribute controls what happens to the existing resource. With DeletionPolicy: Retain, CloudFormation will remove the resource from the stack's management but leave the actual SSM parameter intact in AWS, preserving its current value (including any modifications made by the application).
``yaml
Resources:
MyAppParameter:
Type: AWS::SSM::Parameter
Properties:
Name: MyAppConfig
Type: String
Value: InitialValue
DeletionPolicy: Retain
`
As noted by community member KarBiswa, this approach preserves parameter values during stack updates instead of deleting and recreating them. Community member yingying920928 correctly points out that this is the most straightforward approach.
Why Option D is Incorrect (Common Trap)
Option D suggests modifying the stack policy to deny updates on Parameter Store parameters. While this sounds protective, it creates a critical problem:
- A stack policy that denies updates on a resource will cause the entire stack update operation to fail if CloudFormation determines that the resource needs to be replaced.
- As community member Anandesh referenced from AWS documentation, stack policies are designed to protect resources from unintended updates, but they do not gracefully handle the scenario where CloudFormation needs to replace a resource.
- The question states the developer needs to "avoid resetting the parameter values outside the stack" — meaning the application should continue to work. A stack policy denial would break the stack update entirely, which is not a viable solution.
Why Options B and C are Incorrect
Options B and C suggest migrating configuration data to DynamoDB or RDS. While these would technically solve the problem by moving configuration outside of CloudFormation-managed SSM parameters, they require:
- Significant development effort to migrate the application to use DynamoDB/RDS instead of SSM Parameter Store
- Changes to application code to read/write from the new data store
- Additional infrastructure management
Key Takeaway
When resources are modified outside of CloudFormation and you need to preserve those modifications during stack updates, DeletionPolicy: Retain` is the simplest and most effective approach. It allows CloudFormation to remove the resource from stack management while preserving the actual AWS resource and its current state.
Official Reference
Exam Strategy
When a question asks for the 'LEAST development effort' solution, prioritize answers that use existing AWS features and attributes (like DeletionPolicy) over answers that require migrating to new services or rewriting application code. Always evaluate whether a 'protective' solution might actually break the deployment workflow.
Related Analysis
Practice All DVA-C02 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DVA-C02 Practice Test →