A consultant agency needs to perform a security audit for a company's production AWS account. Several consultants need access to the account. The…

This solution correctly implements the AWS best practice for secure, cross-account access. An IAM role is created in the company's production account (the trusting account), which will contain the necessary audit permissions. The role's trust policy correctly identifies the consultant agency's AWS account as the trusted principal, allowing users from that account to assume the role. Crucially, the trust policy can enforce the use of MFA by including a condition key (aws:MultiFactorAuthPresent). This approach provides temporary credentials via the sts:AssumeRole action, satisfying the requirement to forbid long-term credentials.

A. Creating IAM users directly in the production account generates long-term credentials (passwords and access keys), which is explicitly forbidden by the company's policy.

B. Amazon Cognito is a service for managing user identity for web and mobile applications, not for providing cross-account administrative access to the AWS environment.

C. This configuration is backward. The IAM role must be created in the account whose resources need to be accessed (the company's account), not in the consultant's account.

1. AWS Identity and Access Management User Guide, "IAM tutorial: Delegate access across AWS accounts using IAM roles": This document outlines the exact procedure described in the correct answer. It states, "You can use roles to delegate access to resources that are in different AWS accounts that you own... The trusting account owns the resources to be accessed, and the trusted account contains the users who need to access the resources." This confirms the role must be in the company's account.

2. AWS Identity and Access Management User Guide, "IAM JSON policy elements: Principal": This section explains how to specify a trusted principal in a role's trust policy. It shows that to trust an entire AWS account, you specify the account ARN in the Principal element, such as "Principal": { "AWS": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root" }. This validates specifying the consultant agency's account as the principal.

3. AWS Identity and Access Management User Guide, "Configuring MFA-protected API access": This guide provides an example policy that demonstrates how to enforce MFA for role assumption. The policy includes a Condition block: "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}. This must be added to the role's trust policy to meet the MFA requirement.

4. AWS Identity and Access Management User Guide, "Security best practices in IAM": This guide states, "Require temporary credentials... For human users, require federation with an identity provider to access AWS using temporary credentials... We recommend that you require your human users to use temporary credentials to access AWS." This supports the use of roles (which provide temporary credentials) over IAM users (which have long-term credentials).