A company has two AWS accounts: Production and Development. The company needs to push code changes from the Development account to the Production account. In the alpha phase, only two senior developers in Development need access to Production. In the beta phase, more developers will need access for testing. Which solution meets these requirements?

The correct solution involves creating an IAM role in the Production account. This role will have a trust policy that explicitly allows the Development account to assume it. Developers in the Development account can then assume this role to gain temporary, elevated access to the Production account. This approach is secure and scalable because access is granted through role assumption, not by creating users or policies directly in the Production account. Incorrect options: Creating two policy documents in each account and assigning them to developers is less secure and harder to manage, as it requires creating users or policies directly in the Production account for each developer. Creating an IAM role in the Development account and granting it access to the Production account is incorrect because the role needs to reside in the resource account (Production) to grant access to its resources. Creating an IAM group in the Production account and adding it as a principal in a trust policy that specifies the Production account is incorrect. Trust policies specify who can assume the role, not what resources the role can access. Also, adding developers directly to a group in the Production account violates the principle of least privilege and cross-account access best practices.