Cross-Account IAM Role Trust Policy for AWS

SAA-C03 By islever Editorial Last updated

Design secure access to AWS resources.

Short answer

C Create an IAM role in the Production account with a trust policy specifying the Development account ID.

Question

A company has two AWS accounts: Production and Development. The company needs to push code changes in the Development account to the Production account. In the alpha phase, only two senior developers on the development team need access to the Production account. In the beta phase, more developers will need access to perform testing. Which solution will meet these requirements?
  1. Create two policy documents by using the AWS Management Console in each account. Assign the policy to developers who need access.
  2. Create an IAM role in the Development account. Grant the IAM role access to the Production account. Allow developers to assume the role.
  3. Create an IAM role in the Production account. Define a trust policy that specifies the Development account. Allow developers to assume the role. Correct Answer
  4. Create an IAM group in the Production account. Add the group as a principal in a trust policy that specifies the Production account. Add developers to the group.

Key Takeaways

The key concept is that IAM roles must be created in the account being accessed (Production), and the trust policy must reference the ARN of the account or role in the trusting account (Development).

This question tests the correct configuration of cross-account access in AWS using IAM roles and trust policies. The solution requires creating a role in the target account with a trust policy that specifies the source account.

Common mistake: Many learners incorrectly choose Option D, failing to realize that IAM Groups cannot be used as principals in an IAM Role's trust policy. They also overlook the security best practice of placing the role in the resource account.

Expert Analysis

Why the Answer Is Correct

Option C is correct because it follows the standard AWS pattern for cross-account access: creating a role in the destination account (Production) and defining a trust relationship with the source account (Development). This allows developers in the Development account to assume the role in Production. As the team scales from alpha to beta, you simply add more users/roles in the Development account; the Production role remains unchanged.

Why the Other Options Are Wrong

Option A is insecure and manual, lacking automated role assumption. Option B violates AWS best practices by creating the role in the source account; roles should reside in the account they grant access to. Option D is invalid because IAM Groups cannot be specified as principals in a Role's trust policy—only AWS accounts, IAM users, roles, or AWS services can be trusted.

Community Comment Notes

The majority correctly identified C, citing official documentation on cross-account roles. Some commenters argued for D, mistakenly believing groups could be used in trust policies or overcomplicating user management. One commenter noted that while D might seem granular, it is technically impossible due to IAM constraints.

Official Reference

https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

Always create IAM Roles in the account where the resources live (the 'resource' account). Remember that Trust Policies only accept Account IDs, User ARNs, Role ARNs, or Service Principals—not IAM Groups.

Frequently Asked Questions

Can I use an IAM Group in a Role's trust policy?

No, IAM Groups cannot be principals in a trust policy. You must use specific Users, Roles, or the entire Account.

Why create the role in Production instead of Development?

Best practice dictates roles reside in the account they grant access to. This simplifies permission management and follows the principle of least privilege.

More SAA-C03 FAQ →

Community Votes

C
75%
D
25%

75% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 9 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 9

  1. f07ed8f 👍 3 Answered C
    https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
  2. LeonSauveterre 👍 2 Answered C
    A - We need secure cross-account access between the Development and Production accounts. Option A did nothing about that. B - This setup violates the AWS best practice for cross-account access, which recommends creating roles in the account being accessed (aka Production env). C - As more developers need access, you can grant permissions in the Development account without modifying the role in Production. Also, access is granted through temporary credentials generated when the role is assumed, reducing the risk of long-term credential exposure. D - Groups cannot establish trust between accounts. It didn't provide any mechanism for Development account users to access the Production account.
  3. FlyingHawk 👍 2 Answered C
    1. Creating an IAM role in the Production account with a trust relationship to the Development account. 2. Grant the sts:AssumeRole permission to the specific developers (or groups) who need access to the Production account. 3. During the beta phase, you can easily add more developers to the IAM group or policy in the Development account that allows them to assume the role in the Production account. 4. In the Alpha phase, grant AssumeRole Permission to the groups of Two Senior Developers only
  4. AMEJack 👍 2 Answered C
    It should be C, groups can't be used in trust policy.
  5. Mikado211 👍 1 Answered D
    If you want ALL the developers to assume the role in the production, then C using a trust policy to assume the role in production is perfect BUT You could allow users in development account to assume the role in production, but in the end you will maintain potentially a big trust policy depending of the total number of users. Here you want only some developers to connect to the production (others will follow without knowing if they all can connect and without knowing the number) so managing a separate group will give you a little more maintenance but will allow you to have different rights between the users. I'd say D
Show 4 more comments
  1. TwinSpark 👍 1 Answered D
    Weird question, but D is actually the only one that allow you to select which developer got access and when, so will go for D
  2. 03beafc 👍 1 Answered A
    you can't assign groups as principals, b and c don't specify only the senior devs, a is the only one that works here
  3. xBUGx 👍 1 Answered D
    i think D is better
  4. Mayank0502 👍 1 Answered D
    answer should be D

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Most Cost-Effective 7-Year Retention for EBS Snapshots?

S-grade

AWS Forecast vs SageMaker for Time-Series Prediction

S-grade

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide