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…

Question

Options

• AModify the CloudFormation stack to set the deletion policy to Retain for the Parameter Store
• BCreate an Amazon DynamoDB table as a resource in the CloudFormation stack to hold
• CCreate an Amazon RDS DB instance as a resource in the CloudFormation stack. Create a table
• DModify the CloudFormation stack policy to deny updates on Parameter Store parameters.

• A
  72% (26)
• B
  17% (6)
• C
  3% (1)
• D
  8% (3)

Explanation

Option A is correct because setting DeletionPolicy: Retain on the AWS::SSM::Parameter resource tells CloudFormation to preserve the parameter and its current value instead of deleting and recreating it during stack updates - this ensures that any runtime value changes made by the application survive future deployments with zero application code changes.

Option B is wrong because migrating configuration storage to DynamoDB requires rewriting the application to read from a new data source, which is significant development effort and defeats the "least effort" requirement.

Option C is wrong for the same reason as B, but worse - using RDS as a config store is massively over-engineered and even more development work than DynamoDB.

Option D is wrong because a stack policy that denies updates on SSM parameters would block CloudFormation from making any changes to those parameters (including intentional ones), but it does not prevent CloudFormation from resetting values - it would actually cause the stack update to fail entirely.

Memory tip: Think of DeletionPolicy: Retain as telling CloudFormation "hands off - don't touch this resource during updates or teardown." Whenever you see a scenario where a resource's state changes at runtime and needs to survive CloudFormation updates, Retain is your lowest-effort protection.

No community discussion yet for this question.