8.1 Advanced IAM — Permission Boundaries, Federation, and Cross-Account

Quick Answer: A permission boundary caps the max permissions a user/role can have; effective access = identity policy INTERSECT boundary. Service Control Policies (SCPs) cap whole accounts/OUs in AWS Organizations but never grant. Cross-account access uses an IAM role (trust policy + sts:AssumeRole) or a resource-based policy (caller keeps its identity). IAM Identity Center delivers SSO across many accounts. IAM Access Analyzer flags external sharing and builds least-privilege policies.

Permission Boundaries

A permission boundary is a managed policy attached to an IAM user or role that defines the ceiling on permissions. It never grants access by itself — it only limits what an identity policy can effectively allow. The exam loves the privilege-escalation scenario: let developers create roles for Lambda or EC2 without letting them mint an admin role.

The intersection rule

Effective permissions = Identity (or session) policy AND Permission Boundary. An action is allowed only if BOTH allow it, with no explicit Deny anywhere (an explicit Deny in any policy always wins).

Boundaries vs SCPs vs identity policies

This distinction is a frequent trap. SCPs are an AWS Organizations feature; they apply to entire accounts or Organizational Units (OUs) and filter the permissions of every IAM principal in those accounts (root user included for member accounts, but SCPs do not restrict the management account). A permission boundary is attached to a single user or role. An identity policy is what actually grants. For a request to succeed it must pass all layers: SCP allows it, the boundary allows it, the identity policy allows it, and no Deny blocks it.

Common Trap: SCPs and permission boundaries NEVER grant permissions. If an SCP is the only thing 'allowing' an action, the principal still has zero access until an identity or resource policy grants it.

IAM Identity Center (formerly AWS SSO)

IAM Identity Center centralizes workforce sign-in across every account in an AWS Organization and into SAML business apps.

On the Exam: 'Employees need SSO to 50 accounts by job function' → IAM Identity Center with permission sets. 'A workload in account A needs temporary access to account B' → cross-account IAM role.

Cross-Account Access

Method 1 — IAM roles (most common, all services)

1. Target account creates a role whose trust policy lists the source account/principal as a trusted entity (the Principal).
2. Source principal calls sts:AssumeRole on that role.
3. AWS Security Token Service (STS) returns temporary credentials (default 1 hour, configurable 15 min – 12 hours via DurationSeconds/MaxSessionDuration).
4. The caller uses those credentials and is logged in the target account's CloudTrail as the role.

Method 2 — Resource-based policies (only some services)

S3 bucket, SQS queue, SNS topic, KMS key, and Lambda function policies can name an external account directly. The caller keeps its own identity (no AssumeRole), so CloudTrail in the target account records the original principal.

Confused-deputy and ExternalId

When you grant a third-party SaaS (e.g., a monitoring vendor) a role, set an ExternalId condition in the trust policy. The vendor must pass that unique value on AssumeRole, preventing another customer of the same vendor from tricking the vendor into accessing your account — the confused-deputy problem.

IAM Access Analyzer

On the Exam: 'Find S3 buckets or roles reachable from outside the account' → IAM Access Analyzer external findings. 'Generate a least-privilege policy from what the role actually did' → Access Analyzer policy generation from CloudTrail.

Temporary Credentials and Federation

The SAA-C03 exam consistently prefers temporary credentials over long-lived access keys. Several mechanisms all flow through STS:

• IAM roles for EC2 (instance profile): the instance retrieves rotating credentials from the metadata service — never hard-code keys on an instance.
• Web identity federation / Amazon Cognito: mobile or web users sign in with an external identity provider (Google, Apple, a SAML/OIDC IdP) and Cognito identity pools exchange that token for temporary AWS credentials scoped to a role.
• SAML 2.0 federation: enterprise users authenticate against the corporate IdP and assume a role via AssumeRoleWithSAML.

Common Trap: 'A mobile app needs to upload directly to S3 for millions of users' → Cognito identity pools issuing temporary credentials, NOT one shared IAM user with embedded keys. Embedding access keys in an app is an automatic wrong answer.