AWS IAM Policies and Cross-Account Access: The Exam-Critical Patterns

IAM is the highest-weighted security topic on every AWS architect-track certification. The Solutions Architect Associate (SAA-C03) Security domain alone is 30% of the blueprint, the Security Specialty (SCS-C02) exam dedicates more than half its weight to IAM-adjacent topics, and the Solutions Architect Professional (SAP-C02) tests cross-account IAM patterns in nearly every multi-account scenario. Candidates who master IAM policy structure, permission evaluation logic, role assumption, and cross-account access patterns gain the single biggest score advantage available on these exams.

This guide walks through the IAM concepts that AWS exam writers reach for repeatedly: identity vs resource policies, policy evaluation logic, the assume-role pattern, cross-account roles, permission boundaries, service-control policies, and the specific scenario patterns that appear on architect and security certifications.

---

The IAM Mental Model

IAM controls who can do what to which AWS resources. Four entities matter:

• Users -- long-term identities, typically for humans, with credentials
• Groups -- collections of users for shared permission management
• Roles -- temporary identities assumed by principals (users, services, federated identities)
• Policies -- JSON documents that grant or deny permissions

"Think of IAM as a system of trust. Every action in AWS is evaluated against the question: who is doing this, what are they allowed to do, and from where? The exam is testing whether you can answer those three questions for any scenario." -- Becky Weiss, Senior Principal Engineer at AWS

Principal -- The entity attempting an action: a user, role session, or AWS service. Identity-based policy -- A policy attached to a user, group, or role granting permissions to that identity. Resource-based policy -- A policy attached to a resource (S3 bucket, KMS key, Lambda function) granting permissions to specified principals. Permission boundary -- An advanced feature that caps the maximum permissions an IAM entity can have, regardless of attached policies.

For broader exam context, see AWS Solutions Architect Associate Domains That Matter Most.

---

Policy Structure and Evaluation Logic

An IAM policy is a JSON document with one or more statements. Each statement contains an Effect (Allow or Deny), an Action or list of actions, a Resource or list of ARNs, and optional Condition blocks.

A minimal example:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

The exam tests evaluation logic intensely. The rules:

1. By default, all requests are denied (implicit deny)
2. An explicit Allow overrides the implicit deny
3. An explicit Deny overrides any Allow (deny always wins)
4. Service Control Policies (SCPs) and permission boundaries set a ceiling that even explicit Allows cannot exceed
5. Resource-based policies and identity-based policies are evaluated together; an Allow in either grants access, unless overridden by a Deny

A representative question: "A user has an IAM policy granting s3:* on a bucket. The bucket policy denies s3:DeleteObject from any principal not in a specific VPC. The user attempts to delete an object from outside the VPC. What happens?"

The answer is the delete is denied. The bucket policy's explicit deny overrides the user's identity-based allow. Candidates who memorize "Allow grants access" without understanding deny precedence miss this.

The Six-Step Evaluation Process

AWS evaluates requests in a defined order:

1. Decision starts as implicit deny
2. Evaluate organizational SCPs -- if any deny, the action is denied
3. Evaluate resource-based policies -- explicit allow can grant access cross-account
4. Evaluate identity-based policies -- combined with resource policies
5. Evaluate IAM permission boundaries -- caps maximum permissions
6. Evaluate session policies -- further limits an assumed-role session

Memorizing this order pays off. The exam writes scenarios that require you to walk a request through it.

---

The Cross-Account Access Pattern

Cross-account access is the most-tested IAM pattern on SAA-C03 and SAP-C02. The standard pattern uses an IAM role in the target account, with a trust policy allowing principals from the source account to assume it.

The trust policy in Account B (target):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::ACCOUNT-A:root" },
    "Action": "sts:AssumeRole"
  }]
}

The identity-based policy in Account A (source) grants sts:AssumeRole on the target role's ARN. The user calls sts:AssumeRole, receives temporary credentials (access key, secret key, session token), and uses those credentials to act in Account B.

Variations the exam tests:

• External ID -- Required when the source account is a third-party customer, prevents the confused deputy problem
• MFA condition -- Trust policy requires multi-factor authentication for the assume-role call
• Session duration -- 1 hour to 12 hours, configurable per role
• Source IP condition -- Restricts assume-role calls to specific IP ranges
• Tag-based session policies -- Attribute-based access control via aws:PrincipalTag

"Cross-account roles are the right answer to almost every multi-account access question on the AWS exams. If a question describes an access pattern between accounts, the assume-role pattern is your default answer until proven otherwise." -- Stephane Maarek, AWS instructor and Udemy bestselling author

Capital One, which runs hundreds of AWS accounts under AWS Organizations, has publicly described their internal use of cross-account roles as the foundation of their account isolation model. Netflix, Salesforce, and most other large AWS customers use the same pattern.

The Confused Deputy Problem

The exam tests confused deputy scenarios specifically. A confused deputy is when a service or role is tricked into using its permissions on behalf of an attacker. The fix is the External ID condition in the trust policy, which the legitimate caller must provide and an attacker cannot guess.

A typical scenario: a SaaS vendor needs to access a customer's S3 bucket. The customer creates a role with the vendor's account ID as principal. Without an External ID, any other customer of the same vendor could potentially assume that role. With a unique External ID per customer, the vendor must pass the right value, which only they know.

For deeper service-specific patterns, see AWS S3 Storage Classes Explained for Solutions Architect Associate Candidates.

---

Identity-Based vs Resource-Based Policies

Many candidates conflate these. They serve different purposes:

Policy Type	Attached To	Use Case	Cross-Account
Identity-based	User, group, role	Grant permissions to an identity	Indirect via assume-role
Resource-based	S3 bucket, KMS key, Lambda, SNS, SQS, etc.	Grant principals access to a resource	Direct, no assume-role needed
Permission boundary	User or role	Cap maximum permissions of identity	N/A
Session policy	Assumed-role session	Further restrict the session	N/A
Service Control Policy	OU or account in Organizations	Set guardrails across accounts	N/A

A scenario that distinguishes: a Lambda function in Account A needs to read from an S3 bucket in Account B. Two valid approaches:

1. Attach a resource-based policy to the bucket allowing Account A's Lambda role
2. Have the Lambda role assume a role in Account B that has bucket access

The first approach (resource policy) is simpler and is preferred when only one resource is involved. The second is preferred when many resources need access, since the assumed role can have broader permissions than a single resource policy expresses.

When Resource Policies Beat Identity Policies

Resource policies handle some patterns identity policies cannot:

• Granting public access to an S3 object (set on the bucket policy, not on identities)
• Allowing anonymous SNS publishing from specific HTTPS sources
• Allowing AWS services like CloudTrail to write to an S3 bucket

Conversely, only identity policies can grant a single identity access to many resources without listing each on its resource policy.

---

Permission Boundaries: The Advanced IAM Pattern

Permission boundaries cap the maximum permissions an IAM user or role can have. They do not grant permissions; they limit what attached identity-based policies can grant. The intersection of attached policies and the boundary defines effective permissions.

The exam tests permission boundaries in delegation scenarios. A common pattern: a central IAM team allows developers to create new roles within their team's project, but only for permissions within a defined boundary. Without boundaries, a developer with iam:CreateRole and iam:AttachRolePolicy could grant themselves AdministratorAccess. With boundaries, the developer can create roles, but those roles cannot exceed the boundary even if AdministratorAccess is attached.

"Permission boundaries are how mature AWS organizations delegate IAM management without losing control. They are tested on the SCS-C02 and SAP-C02 exams specifically because they distinguish architects who understand defense in depth." -- Adrian Cantrill, AWS instructor and former AWS Specialist Solutions Architect

For broader security exam coverage, see AWS Specialty Certifications Ranked.

---

AWS Organizations and Service Control Policies

AWS Organizations groups accounts under a single payer account, organized into Organizational Units (OUs). Service Control Policies (SCPs) attach to OUs or accounts and limit what any principal in those accounts can do, including the root user.

Key exam facts:

• SCPs are guardrails, not grants -- they cap what is possible but do not grant any access
• SCPs apply to all principals including the root user of member accounts
• The management (payer) account is not affected by SCPs
• SCPs use the same policy syntax as IAM but with specific allowed actions

A typical scenario: an enterprise wants to ensure no developer in any sandbox account can create resources outside us-east-1 and us-west-2. The fix is an SCP attached to the Sandbox OU that denies all actions where aws:RequestedRegion is not in the allowed list.

Control	Applies To	Grants Permissions	Caps Permissions
Identity policy	User, group, role	Yes	No
Resource policy	Resource	Yes	No
Permission boundary	User, role	No	Yes
Session policy	Role session	No	Yes
Service Control Policy	OU, account	No	Yes

The exam asks "which AWS feature would prevent X from being possible regardless of attached policies?" The answer is almost always SCPs or permission boundaries, depending on whether the scope is across accounts or within a single account.

---

Federated Access and IAM Identity Center

Modern AWS deployments rarely use IAM users. Instead, they federate from external identity providers (Okta, Azure AD, Google Workspace) via SAML 2.0 or OIDC, often through AWS IAM Identity Center (formerly AWS SSO).

The exam tests:

1. SAML federation flow: IdP issues assertion, user calls sts:AssumeRoleWithSAML, gets temporary credentials
2. OIDC federation flow: similar but with sts:AssumeRoleWithWebIdentity, common for mobile apps and IoT
3. IAM Identity Center: AWS-managed federation across multiple accounts via permission sets
4. Cognito User Pools (authentication) vs Identity Pools (AWS credential exchange)

A common scenario: an enterprise wants single sign-on across 50 AWS accounts. The right answer is IAM Identity Center with permission sets attached to Active Directory groups, not custom SAML federation per account.

Cognito Identity Pools vs User Pools

A frequently confused pair:

• User Pool -- A user directory; handles sign-up, sign-in, MFA, password reset
• Identity Pool -- Exchanges authenticated identity (from User Pool, social login, SAML) for temporary AWS credentials

Mobile and web apps that need direct AWS service access use both: User Pool for authentication, Identity Pool for AWS credential issuance. The exam tests this distinction in mobile and IoT scenarios.

---

STS Operations the Exam Tests

AWS Security Token Service (STS) operations show up across architect and developer exams:

• sts:AssumeRole -- Cross-account or service role assumption
• sts:AssumeRoleWithSAML -- SAML-based federated assumption
• sts:AssumeRoleWithWebIdentity -- OIDC-based federated assumption (Cognito, Google, Facebook)
• sts:GetSessionToken -- Temporary credentials for the calling identity, often with MFA
• sts:GetFederationToken -- For federated proxy applications, less common today

Session duration limits matter: AssumeRole tokens last 1-12 hours, GetSessionToken tokens last 15 minutes to 36 hours. The exam tests these limits in scenarios involving long-running batch jobs or short-lived CI pipelines.

For deeper Lambda IAM patterns specifically, see AWS Lambda and Serverless Questions on the Developer Associate Exam: A Deep Dive.

---

Common Exam Scenarios and the Right Patterns

A short list of recurring IAM scenarios and their canonical answers:

1. EC2 instance needs S3 access -- Instance profile with IAM role, never embedded credentials
2. Lambda needs DynamoDB access -- Execution role with policy, never access keys
3. Cross-account S3 read -- Bucket resource policy or assume-role pattern
4. Third-party SaaS access to your account -- Cross-account role with External ID condition
5. Restrict actions to a specific region -- SCP or identity policy with aws:RequestedRegion condition
6. Restrict actions from a specific IP -- Identity or resource policy with aws:SourceIp condition
7. Mobile app authentication -- Cognito User Pool plus Identity Pool
8. Enterprise SSO across accounts -- IAM Identity Center with permission sets
9. Prevent privilege escalation by developers with iam:* -- Permission boundaries
10. Audit who did what -- CloudTrail with management and data events enabled

See also: AWS VPC Networking Concepts Every AWS Cert Candidate Must Master, AWS Exam Question Patterns: How to Read Scenarios Correctly, AWS SAA-C03 Practice Test Strategy: How to Score 80%+.

---

Study Plan for IAM Mastery

A focused 10-day IAM study plan within an 8-week SAA-C03 schedule:

1. Day 1-2: Read the AWS IAM User Guide chapters on policies, roles, and STS
2. Day 3-4: Build five different policies in your AWS Free Tier account, attach them, test access
3. Day 5: Create a cross-account role between two AWS accounts you control, assume it from CLI
4. Day 6: Configure an External ID requirement and verify failed assumption without it
5. Day 7: Build a permission boundary that caps a developer role's permissions
6. Day 8: Set up AWS Organizations with two member accounts, attach an SCP, verify it
7. Day 9: Take 30 IAM-specific practice questions, review every wrong answer
8. Day 10: Re-attempt the wrong-answer set after reviewing relevant docs

This loop builds the IAM intuition that translates into points. The Linux Foundation, ISC2, and ISACA all teach similar identity-management patterns in their cloud security curricula because the underlying access-control logic generalizes across providers, but the AWS implementation specifics are what the AWS exams test.

A useful supplementary exercise that pays dividends: write each of the canonical policy patterns from memory, without looking. Cross-account read-only S3, EC2 instance role with DynamoDB write, Lambda execution role with KMS decrypt, deny-all-but-region SCP. If you can compose these JSON documents from scratch in five minutes each, you have the IAM fluency SAA-C03 rewards.

---

References

1. Amazon Web Services. AWS IAM User Guide. docs.aws.amazon.com/iam, 2024.
2. Amazon Web Services. AWS Certified Solutions Architect - Associate (SAA-C03) Exam Guide. AWS Training and Certification, 2024.
3. Weiss, Becky. Eliminating Toil with AWS IAM Access Analyzer. AWS re:Inforce Keynote, 2023.
4. Maarek, Stephane. Ultimate AWS Certified Solutions Architect Associate SAA-C03. Udemy / Packt Publishing, 2024.
5. Cantrill, Adrian. AWS Identity and Access Management Deep Dive. learn.cantrill.io, 2024.
6. Ramamoorthi, Ratan, and others. AWS Security Cookbook. Packt Publishing, 2023.
7. Amazon Web Services. AWS Organizations User Guide: Service Control Policies. docs.aws.amazon.com/organizations, 2024.