In challenge 2 I would actually add Answer “C”.

Interesting thought! There’s a few things potentially to unpack in that one, beyond Scott’s remarks in the videos

The answer is specifically saying that we would do this to ensure no backdoors are left behind.

We’d want to consider what might be in our AWS Account that migrating to a new account might prevent. Many of our production services would be migrated, which would probably include EC2 instances, Lambda functions, and IAM objects like users, roles, and policies. The problem is whatever we migrate may still contain these potential backdoors. While it’s easy to keep mental track of each object in our AWS Account as part of learning and testing, it’s a lot harder in a complex production environment

Many compromises will take place not by adding something new, but to some degree by co-opting something that already exists. For example, we might add a clandestine extra set of IAM Access Keys to an administrative user, install some malicious software on an EC2 instance, or add some sneaky rules send database backups to an unsecured external account. Straight migrations would bring these along to our new account too.

Another hint in the answer is the "different region". Materially, we know the region wouldn’t make much of a difference. In production environments, we may also be restricted to which region we could deploy our solutions in for regulatory reasons.

One other thing we notice is the timeline of two months. On the side of what we might recommend to our client, any migration would also take quite a considerable amount of effort and time, even between AWS Accounts. Even if we have CloudFormation templates for everything (which really, sometimes we don’t), even moving the data and conducting the necessary testing and reconfiguration would take some time to make sure we do it right. Anytime we see "migration", the term "speed" often doesn’t go along with it.

Happy to hear any extra thoughts from Scott or other students too