A platform team manages a production VPC stack with "AWS CloudFormation". The stack contains a hand-tuned security group whose rules must never be altered or deleted by a routine template update, while the rest of the stack should still accept ordinary changes through the pipeline. The team wants a guardrail that lives with the stack itself rather than relying on reviewers to spot risky diffs. Which approach BEST protects that one resource while leaving the remainder of the stack updatable?
- AAdd a "DeletionPolicy" of "Retain" to the security group so that the resource is preserved whenever the production stack is updated by the pipeline.
- BAttach a stack policy that denies "Update:Modify" and "Update:Delete" on the security group logical ID while allowing updates to all other resources. Correct
- CEnable termination protection on the stack so that no resource inside it can be changed during a pipeline-driven update.
- DMove the security group into a separate nested stack and mark that nested stack resource with "Update:Replace" denied in the parent.
Why A is wrong: "DeletionPolicy" only controls what happens when a resource is removed from the template or the stack is deleted; it does not block in-place modification, so it fails the no-alteration requirement here.
Why B is correct: A stack policy is evaluated during every stack update and can deny modify and delete on a specific logical ID while permitting changes elsewhere, giving an in-stack guardrail that needs no human review.
Why C is wrong: Termination protection only blocks deletion of the whole stack; it is tempting as a safety switch but does nothing to prevent updates to an individual resource during a normal update.
Why D is wrong: Splitting the resource out adds structure but still permits modification, and a deny on replace alone does not stop modify or delete, so the protected rule could still be altered.