The correct options are Resources were changed outside of CloudFormation and the template was not updated and The IAM user or role that ran the update lacked some required permissions. These two causes together explain why the stack update rolled back and then left the stack in UPDATE_ROLLBACK_FAILED.

Resources were changed outside of CloudFormation and the template was not updated is correct because manual or out of band changes create configuration drift and can make the prior resource state unreachable. When CloudFormation tries to restore the previous state it can fail if a resource has been modified outside the stack or if required properties no longer match what CloudFormation expects.

The IAM user or role that ran the update lacked some required permissions is correct because CloudFormation needs permission to modify create and delete all dependent resources during an update or rollback. If the execution principal lacks one or more necessary IAM actions the service cannot complete the rollback and the stack can end up in a failure state.

An interface VPC endpoint for CloudFormation in the VPC was unavailable is not a likely cause because CloudFormation operates via regional service APIs and does not depend on an interface endpoint inside the VPC to manage most resources.

The update was deployed without first creating and executing a change set is incorrect because change sets are optional. Not using a change set does not by itself cause a rollback to fail.

AWS Config was not enabled in the account or Region is unrelated because AWS Config only records resource configuration and is not required for CloudFormation to perform updates or rollbacks.

Full AWS Practitioner Certification Question