Which combination of actions should the security engineer take to meet these requirements?

Explanations:

Inactivating the IAM role’s access key and issuing a new access key does not directly address the compromised Active Directory identity. The IAM role itself is still vulnerable since it can be accessed by the federated identity unless the root cause is mitigated. Additionally, it may lead to downtime for the production workloads if they rely on the specific access key.

Revoking access for the identity in the on-premises Active Directory effectively mitigates the unauthorized use of the IAM role. This action directly addresses the root cause of the compromise, preventing any further access to the AWS environment using that identity without causing downtime to existing workloads.

Attaching an IAM policy to the IAM role that denies access to any AWS Security Token Service (AWS STS) tokens issued prior to the current time would prevent any previously issued tokens from being used, effectively mitigating access by the compromised identity. This action can be implemented without causing significant downtime, as it only affects the permissions associated with the role rather than the role itself.

Denying access to the federated Active Directory identity’s ARN does not prevent the IAM role from being used by the compromised identity if that identity is still valid in the directory. Additionally, this approach might lead to operational complexities if multiple identities are being managed. It does not effectively mitigate the issue of the compromised identity itself.

Removing the IAM role’s login profile would restrict use of the AWS Management Console for that role but does not prevent the compromised identity from accessing AWS resources programmatically through other means (such as via STS tokens). This action alone would not mitigate the risk posed by the compromised Active Directory identity.