IAM Policy Simulator

Correct Answer: Modify the bucket policy to include the new account ID

To grant an additional AWS account access to an existing S3 bucket that already trusts other external accounts, the most direct and required change is to update the bucket policy to include the new account as a principal with the desired actions (for example, s3:GetObject) on the appropriate resources. This typically uses the principal ARN arn:aws:iam::ACCOUNT-ID:root or a specific role ARN if restricting to a role. Creating a new IAM role alone does not grant access to the bucket unless the bucket policy also permits that principal. Adding access keys is unrelated to resource-based permissions, and modifying AWS Organizations is not required unless you specifically use organization-wide conditions such as aws:PrincipalOrgID.

Correct Answer: Add a new policy statement granting 's3:PutObject' action in the simulator

The IAM Policy Simulator allows you to load the user's existing permissions and add a temporary, custom policy statement to model proposed changes without affecting any live IAM policies. Adding an Allow statement for s3:PutObject simulates granting write access to the bucket. Modifying the existing policy statement or attaching a new policy would change real policies, which the question prohibits, and changing Effect to Deny would remove access rather than grant it.

Correct Answer: Simulate the ‘s3:DeleteObject’ action without providing MFA context in the simulator request

The IAM Policy Simulator evaluates IAM policy logic and request context keys such as aws:MultiFactorAuthPresent. To determine whether the user’s IAM policies would allow s3:DeleteObject when MFA is not used, simulate the s3:DeleteObject action without supplying MFA context, which sets aws:MultiFactorAuthPresent to false. Note that this only tests IAM policy evaluation; S3’s MFA Delete enforcement (x-amz-mfa requirement) is a service-level check and is not simulated.