Why D? And why not the others?

Correct answer: D. Have the engineer call AWS STS to assume an IAM role in Account B whose trust policy permits Account A, receiving temporary credentials that expire automatically

Calling AWS STS to assume a role whose trust policy names Account A as a trusted principal produces temporary security credentials with a defined, bounded session lifetime that expires automatically without any manual revocation step, which is exactly the self-expiring access the security team wants. The option using a permanent IAM user and shared access keys is wrong because that credential does not expire on its own and, once shared, is difficult to fully revoke or rotate, the opposite of a short session. The option granting a resource-based policy on every resource in Account B is wrong because it would have to be created and later removed on each resource individually, it grants standing access rather than a time-bounded session, and it does not scale as resources change. The option adding the engineer's user to an IAM group inside Account B is wrong both because IAM groups cannot contain principals from another account and because group membership, like the other rejected options, does not expire on its own the way an assumed-role session does.

Source: AWS IAM documentation: Using IAM roles — AssumeRole and temporary security credentials