A user accidentally modified a database property in a CloudFormation template and executed a stack update, causing application downtime. The DevOps team must still be able to deploy stacks, but accidental changes to particular critical resources must be blocked. Which change to the deployment process will satisfy this requirement?

The correct answer is to deploy CloudFormation stacks with a stack policy. Stack policies are designed precisely for this scenario: they prevent unintentional updates to specified stack resources. By explicitly allowing all resources and explicitly denying Update: on critical resources, you ensure that these resources cannot be modified during a stack update unless the policy is overridden. AWS Config rules and EventBridge rules with Lambda functions (options A and B) could detect changes but are reactive and complex to implement for preventing the update itself. They would likely trigger after the update attempt, potentially leading to a failed update or requiring complex rollback logic. Attaching an IAM policy to the DevOps role (option D) is incorrect because IAM policies control who can perform actions, not what actions can be performed on specific resources within an already authorized stack update. An IAM policy preventing updates to specific ARNs would prevent the entire stack update if those ARNs were part of the stack, which is not the desired granular control.