IAM at Scale — Identity Federation, Permission Boundaries, and ABAC

IAM identity federation and permission boundaries are the twin disciplines that turn a sprawling multi-account AWS estate into something a DevOps team can govern at scale without drowning in long-lived access keys or hand-maintained policies. On the DOP-C02 exam, IAM identity federation and permission boundaries appear all over Domain 6 Task 6.1 whenever a scenario sets "developers should self-serve roles but cannot escalate privileges," "GitHub Actions must deploy without static credentials," or "central security must enforce a ceiling on what a delegated admin can grant." The right answer always combines federation (so humans and CI systems never hold long-lived credentials), permission boundaries (so delegated admins cannot exceed an organizational ceiling), and SCPs (so the entire account is fenced) into a layered control that a single misconfigured policy cannot bypass.

This Pro-depth guide walks through every IAM identity federation and permission boundaries primitive you will encounter on DOP-C02: SAML 2.0 vs OIDC identity providers, IAM Identity Center as the recommended human entry point, ABAC with session tags, the precise evaluation order between identity policies, resource policies, permissions boundaries, SCPs, and session policies, machine identity patterns for EC2/ECS/Lambda/CodeBuild, GitHub Actions OIDC trust without static keys, role chaining with STS, IAM Access Analyzer for policy generation and external-access detection, and the canonical delegated-admin pattern where a platform team gives application teams self-service IAM creation power constrained by a permission boundary they cannot remove.

What Is IAM Identity Federation and Permission Boundaries?

IAM identity federation and permission boundaries are two complementary primitives. Identity federation lets external identity stores (corporate IdPs, GitHub, Okta, Active Directory) authenticate users and assume IAM roles for temporary credentials, eliminating the need for IAM users with long-lived access keys. Permission boundaries are an advanced IAM feature that sets the maximum permissions an identity-based policy can grant to an IAM user or role, even if a more permissive identity policy is attached. Together, they let a DevOps platform team delegate "create your own IAM roles" to application teams while guaranteeing those teams cannot escalate beyond an organizational ceiling.

Why IAM Identity Federation and Permission Boundaries Matter for DOP-C02

DOP-C02 Task 6.1 explicitly enumerates "identity federation techniques" and "permission management delegation by using IAM permissions boundaries" as required knowledge. Single-account IAM patterns from SAA-C03 are inadequate. Pro-tier scenarios involve 50-account organizations where a central platform team needs to enforce a ceiling on what application-team developers can do, where pipelines must deploy across accounts without static credentials, and where session tags drive ABAC so one role definition serves dozens of project teams.

The Five Layers of IAM Authorization

Understanding IAM identity federation and permission boundaries requires holding all five authorization layers in your head simultaneously: SCPs (Organizations-level allow-list ceiling), permission boundaries (per-entity ceiling on identity policies), identity policies (what the principal can do), resource policies (what the resource permits), and session policies (per-STS-call narrowing). On the DOP-C02 exam, any single-layer answer is usually wrong; the right answer reasons across at least three.

Plain-Language Explanation: IAM Identity Federation and Permission Boundaries

IAM identity federation and permission boundaries sound like impenetrable acronyms, but three everyday analogies expose their structure.

Analogy 1 — The Office Building Security Pass System (Door Access Analogy)

Picture a 50-floor office building (your AWS Organization) with one main reception (IAM Identity Center), one external badge bureau the company contracts with (SAML/OIDC IdP), and per-tenant floor managers (delegated admins). IAM identity federation is the rule that nobody — staff, vendors, contractors — gets a permanent building pass; everyone presents their corporate ID at reception each morning and is issued a temporary day-pass.

In this system, the corporate badge from your home company is your SAML or OIDC identity at Okta/Azure AD/Auth0. Reception's issuing desk that converts corporate badges into building day-passes is sts:AssumeRoleWithSAML or sts:AssumeRoleWithWebIdentity. The day-pass itself with a 1-hour to 12-hour expiry is the temporary STS credential. The building-wide rules posted in every elevator that say "no smoking, no firearms, no recording" — applying to every visitor regardless of their day-pass colour — are SCPs. The per-floor ceiling on who can enter which rooms that the floor manager set when issuing a tenant's day-pass is the permissions boundary on the role. The specific room key the floor manager hands you for today's meeting is your identity policy. The room's own door rules that says "this room only opens for registered visitors" is the resource policy. And the temporary downgrade the floor manager applies on a day a sensitive event is happening ("today only, no access to floors 40-45 even if your pass normally allows it") is a session policy applied at AssumeRole time. Five layers. Day-passes only. No permanent badges anywhere.

Analogy 2 — The Hospital Prescription Authority System (Medical / Pharmacy Analogy)

Imagine a hospital where doctors (developers), residents (junior engineers), and external locums (CI systems like GitHub Actions) all prescribe medications. IAM identity federation and permission boundaries is the layered authority system that prevents any single doctor from prescribing controlled substances they should not.

The medical license issued by the state board (your corporate IdP) is the SAML/OIDC assertion. The hospital policy book that applies to everyone in the building, set by the hospital board (Organizations management) — "no opioid prescriptions over 30-day supply, no narcotics without consultant sign-off" — is SCPs. The department-level ceiling the chief of medicine sets when granting a new attending physician their privilege list — "even if you sign your own privilege amendment, you cannot exceed this ceiling" — is the permissions boundary. The physician's actual privilege list ("can prescribe insulin, antibiotics, and anti-hypertensives") is the identity policy. The pharmacy's own dispensing rules ("controlled substance shelf only opens for principals on the controlled-list registry") is the resource policy. The on-call session restriction ("during this 8-hour shift, no prescriptions for patient X who is in conflict-of-interest with this physician") is the session policy. A locum doctor (machine identity) does not get a permanent license — they get a one-shift temporary credential issued via federation each shift. The hospital trusts external license boards but still enforces every layer of its own.

Analogy 3 — The Embassy Visa and Customs Layered Inspection System (Border Control Analogy)

Picture an international airport's border-control system. IAM identity federation and permission boundaries is the layered series of checkpoints between a traveller's passport and them entering the country to pursue specific activities.

The passport from your home country verified by your government is the IdP-issued SAML/OIDC token. The embassy that converted your passport into an entry visa is the IAM Identity Center or AssumeRoleWithSAML endpoint. The visa stamp itself with type "tourist 90 days" or "work permit 2 years" or "transit 24 hours" is the temporary STS credential. The customs declaration form posted in every airport that lists categories never allowed regardless of visa type ("no firearms, no agricultural products") is the SCP. The per-visa-class ceiling that says "tourist visa holders may not work for compensation, even if a local employer offers them a contract" is the permissions boundary on the role. The specific employer's letter giving you permission to take a particular job is the identity policy. The specific worksite's safety rules is the resource policy. And the per-shift restrictions the worksite manager applies ("today you are only allowed in zone A") is the session policy. Federation is what made this possible — the country trusts the issuing government, the visa expires automatically, and everything else stays consistent across millions of travellers.

SAML 2.0 Federation — The Enterprise-Standard IdP Path

SAML 2.0 is the long-standing enterprise federation protocol that DOP-C02 expects you to know in IAM detail.

Trust Establishment

In SAML federation, you create an IAM SAML identity provider in each AWS account by uploading the IdP's metadata XML — a document containing the IdP's signing certificate, SSO endpoint URL, and entity ID. The metadata is distributed by Okta, Azure AD, ADFS, Ping, OneLogin, Auth0, and Google Workspace as a downloadable file or a published URL. Once registered, the IdP is the trust anchor; AWS will accept any SAML assertion signed by the IdP's certificate.

AssumeRoleWithSAML Flow

The user authenticates at the IdP (browser redirect to Okta login, MFA, etc.). The IdP issues a signed SAML response containing the user's identity and a list of role ARNs the user is permitted to assume (encoded in the https://aws.amazon.com/SAML/Attributes/Role attribute). The user's browser POSTs the assertion to AWS sign-in, which calls sts:AssumeRoleWithSAML and returns temporary credentials for the chosen role. Session duration: 1 hour to 12 hours, set on the role's MaxSessionDuration.

SAML Attribute Mapping for ABAC

SAML assertions can carry attributes (department, costCenter, project) that AWS converts to session tags via the https://aws.amazon.com/SAML/Attributes/PrincipalTag namespace. Session tags drive ABAC — identity policies use aws:PrincipalTag/department to grant access only to resources tagged with the same department. One role definition serves dozens of departments because the assertion-supplied tag narrows the effective access at session time.

When to Choose SAML

Choose SAML when the corporate IdP is established and centralized (Active Directory Federation Services, Azure AD, Okta), when the workforce uses browser-based console access predominantly, and when MFA, conditional access, and lifecycle management already live in the IdP. SAML is the answer in DOP-C02 scenarios where "5,000 developers, central Active Directory, must access AWS console without IAM users" is the requirement.

OIDC Federation — The Modern Choice for CI/CD and Web Identity

OIDC (OpenID Connect) is the modern OAuth 2.0–based federation protocol that DOP-C02 emphasises for machine identities and CI systems.

Why OIDC for GitHub Actions and CI/CD

The flagship use case is GitHub Actions deploying to AWS without storing long-lived access keys as repository secrets. GitHub publishes an OIDC token on every workflow run; AWS validates the token's signature against GitHub's published JWKS and issues temporary credentials via sts:AssumeRoleWithWebIdentity. The role's trust policy pins the GitHub org, repo, and branch using the token.actions.githubusercontent.com:sub condition — only specified workflows can assume the role.

Trust Policy Pattern for GitHub OIDC

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    },
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
    }
  }
}

Pin the sub claim to the exact branch or environment to prevent forks or feature branches from assuming production roles.

Cognito Identity Pools for Mobile and Web Apps

Cognito identity pools provide a different OIDC flavour — issuing AWS temporary credentials to mobile/web app end users authenticated via Google, Apple, Facebook, or a custom OIDC IdP. The app receives credentials scoped to an authenticated or unauthenticated role, with fine-grained control via identity-pool role mappings.

OIDC Provider Thumbprint

When creating an IAM OIDC provider, AWS records the SHA-1 thumbprint of the IdP's TLS certificate. If the IdP rotates its certificate, you must update the thumbprint or AssumeRoleWithWebIdentity calls will fail. AWS now auto-fetches thumbprints for well-known providers (GitHub, Bitbucket) but third-party OIDC providers may need manual thumbprint refresh.

AWS IAM Identity Center — The Recommended Human Entry Point

AWS IAM Identity Center (formerly AWS SSO) is the managed multi-account federation service that DOP-C02 treats as the default human-access pattern.

How Identity Center Works

Identity Center maintains an identity store (built-in, or synced from Azure AD/Okta/Google Workspace via SCIM) and a permission set catalog. Users sign in to a single AWS access portal URL, see all assigned accounts and permission sets, and click through to obtain temporary credentials in any account they have access to. Behind the scenes, Identity Center provisions IAM roles in each member account named AWSReservedSSO_<PermissionSetName>_<HASH> whose trust policy allows the Identity Center service to assume them.

Permission Sets

A permission set is a template combining AWS managed policies, customer managed policies, inline policies, and (critically) a permissions boundary into a reusable bundle. Assign a permission set + an account + a user/group, and Identity Center provisions the corresponding role in that account. One permission set serves all accounts where the same access pattern applies — central definition, distributed enforcement.

Identity Center vs Direct SAML/OIDC

Identity Center wraps SAML federation but adds multi-account orchestration, session-lifetime governance, and access-portal UX. The answer for "5,000 developers across 100 accounts need browser console access" is always Identity Center, never per-account SAML providers maintained by hand.

Session Duration and ABAC

Permission sets define session duration (1–12 hours). Identity Center supports ABAC by mapping IdP attributes to session tags — a costCenter SCIM attribute becomes aws:PrincipalTag/costCenter automatically. ABAC permission sets reference aws:PrincipalTag in their policies, granting access scoped to the user's costCenter without per-cost-center role explosions.

Permission Boundaries — The Ceiling on Identity Policies

Permission boundaries are the IAM feature DOP-C02 tests most rigorously in delegation scenarios.

What a Permission Boundary Does

A permission boundary is an IAM managed policy attached to an IAM user or role that defines the maximum permissions the entity can have, regardless of what identity policies are attached. It does not grant permissions. It only restricts. The effective permission is the intersection of the identity policies and the permission boundary.

Permission Boundary Use Case — Developer Self-Service

The canonical use case: a platform team wants developers to create IAM roles for their applications without raising tickets. Without permission boundaries, granting iam:CreateRole and iam:AttachRolePolicy lets developers create roles with AdministratorAccess, defeating least privilege. With permission boundaries, the platform team:

1. Defines a managed policy DevPermissionBoundary with the maximum permissions any developer-created role may have (e.g., S3 read/write, DynamoDB read/write on tagged tables, CloudWatch Logs write — but no IAM, no Organizations, no KMS key creation).
2. Grants developers iam:CreateRole and iam:PutRolePolicy only on roles where iam:PermissionsBoundary equals arn:aws:iam::123:policy/DevPermissionBoundary.
3. Now developers can create any role they need; the role's effective permissions can never exceed the boundary, even if the developer attaches AdministratorAccess as the identity policy.

Permission Boundaries vs SCPs

Permission Boundary Evaluation Pitfall

A common trap: developers think attaching a permission boundary grants permissions. It does not. Without an identity policy granting s3:GetObject, the role cannot read S3 even if the boundary allows S3. The boundary is a ceiling, not a floor. Both layers must allow.

Setting iam:PermissionsBoundary Condition

The platform team's policy granting iam:CreateRole to developers must enforce the boundary attachment via condition:

{
  "Effect": "Allow",
  "Action": ["iam:CreateRole", "iam:PutRolePolicy", "iam:AttachRolePolicy"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::123:policy/DevPermissionBoundary"
    }
  }
}

Also require iam:PassRole only for roles bearing this boundary, and explicitly deny iam:DeleteRolePermissionsBoundary and iam:PutRolePermissionsBoundary so developers cannot remove or change the boundary.

SCPs vs Permission Boundaries vs Session Policies — Five-Layer Evaluation

DOP-C02 frequently tests precise evaluation order. Memorise this hierarchy.

Evaluation Order (AWS Authoritative)

For an API call to succeed, all applicable layers must allow it:

1. SCP — applies to every principal in the account/OU (including root). Default deny if SCP is FullAWSAccess-removed; otherwise allow-listed actions only.
2. Resource-based policy — explicit allow can grant cross-account access without identity policy. Explicit deny vetoes everything.
3. Identity-based policy — the principal's user/role policy must allow.
4. Permission boundary — must allow (for IAM users and roles where attached).
5. Session policy — passed at AssumeRole or GetFederationToken time, narrows further.

Any explicit deny at any layer overrides every allow. Default behaviour is deny — at least one explicit allow is required across identity-policy-or-resource-policy.

Cross-Account Special Cases

Cross-account access requires both the trusting account's resource/role policy AND the trusted account's identity policy to allow the action. Permission boundaries on the calling principal apply. SCPs on both accounts apply.

Session Policy Use Case

Session policies are inline policies passed at sts:AssumeRole time. Use case: a CI pipeline assumes a deploy role but for a particular deployment narrows access further (e.g., only allow writes to a specific stack name) by passing a session policy. The role's identity policy still applies; the session policy intersects with it.

ABAC — Tag-Based Access Control at Scale

ABAC (Attribute-Based Access Control) is DOP-C02's recommended pattern for multi-team scaling.

How ABAC Works

Instead of a role per team, define one role whose identity policy uses tag conditions:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::*/*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalTag/project": "${aws:ResourceTag/project}"
    }
  }
}

A user with session tag project=alpha can access only S3 objects in buckets tagged project=alpha. One role definition serves arbitrarily many projects.

Session Tags from Federation

ABAC works because federation can supply session tags. SAML attributes mapped to session tags, OIDC token claims mapped to session tags, IAM Identity Center SCIM attributes mapped to session tags — all populate aws:PrincipalTag automatically.

ABAC Trade-offs

ABAC scales beautifully but requires disciplined tagging across all resources. A resource without the right tag is invisible to ABAC-scoped principals — a pro of preventing accidental access, a con of breaking workflows when tags are forgotten. Combine ABAC with Config rules requiring project tag on all resources and AWS Resource Groups Tag Editor for retroactive tagging.

ABAC vs RBAC

RBAC (role-based) creates one role per access pattern: AlphaProjectDeveloper, BetaProjectDeveloper, etc. Quickly explodes. ABAC creates one role and varies the tag at session time. DOP-C02 scenarios mentioning "100 project teams need similar access patterns scoped to their own resources" are always ABAC.

Machine Identities — EC2, ECS, Lambda, CodeBuild

Federation also covers machine identities; DOP-C02 expects you to know each compute primitive's identity mechanism.

EC2 Instance Profiles

An IAM role attached via instance profile lets EC2 instances obtain temporary credentials from IMDSv2 (http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>). Always enforce IMDSv2 (token-required) to prevent SSRF-based credential theft. Never embed access keys in user data or AMIs.

ECS Task Roles

ECS tasks (Fargate or EC2) assume task roles via the ECS agent's metadata endpoint. Different from instance profile: each task can have its own role, providing per-microservice least privilege. The task execution role (separate from the task role) is what ECS uses to pull images from ECR and write logs — keep these separate.

Lambda Execution Role

Lambda functions assume their execution role automatically; the temporary credentials are exposed via environment variables. Lambda execution roles should be one-per-function with the minimal CloudWatch Logs and per-function-resource permissions.

CodeBuild Service Role

CodeBuild uses a service role to access CodeCommit/S3 source, push to ECR, write CloudWatch Logs, and perform any deployment actions. CodeBuild can also assume cross-account roles via STS during builds — the canonical pattern for cross-account artifact deployment.

Role Chaining and STS — Cross-Account Access Patterns

Role chaining is the pattern where one role assumes another, and is heavily tested on DOP-C02.

sts:AssumeRole Mechanics

Role A (already authenticated) calls sts:AssumeRole on Role B, providing Role B's ARN and an external ID (recommended for cross-account). Role B's trust policy must allow Role A's principal. The returned credentials are valid for the requested duration (max 1 hour for chained roles vs 12 hours for first-hop).

Chained Role Session Limit

A chained role's MaxSessionDuration is capped at 1 hour regardless of the role's setting. The exam tests this — pipelines running longer than 1 hour with chained roles must refresh credentials.

External ID for Third-Party Access

When granting a third-party SaaS (Datadog, Splunk Observability, third-party SIEM) cross-account access, require sts:ExternalId in the trust policy. The external ID is a shared secret that prevents the confused-deputy problem — even if an attacker learns your account ID and role ARN, they cannot assume the role without the external ID the SaaS uses.

Source IP Conditions on AssumeRole

Trust policies can require aws:SourceIp to be in a known CIDR range, restricting role assumption to corporate networks or specific NAT egress IPs. Combine with VPC endpoints to lock down further.

IAM Access Analyzer — Generation and External Access

IAM Access Analyzer is the under-utilized service DOP-C02 expects you to leverage.

Policy Generation from CloudTrail

Access Analyzer can analyze CloudTrail history for a role and generate a least-privilege policy reflecting what the role actually used. Workflow: the role runs with broad permissions for 30-90 days, Access Analyzer generates a tight policy from the observed actions, the platform team replaces the broad policy with the generated one. This automates least-privilege refinement.

External Access Findings

Access Analyzer continuously evaluates resource policies (S3 buckets, KMS keys, IAM roles, Lambda functions, Secrets Manager secrets, SQS queues) for access from outside the trust zone (the Organization or specified zone of trust). Findings flow to Security Hub for aggregation. The exam tests recognising "we need to detect when a developer makes an S3 bucket cross-account writable" — the answer is Access Analyzer.

Unused Access Findings

Access Analyzer also identifies unused IAM roles and unused permissions within roles, providing actionable least-privilege recommendations. This complements Access Analyzer policy generation.

IAM Policy Simulator and CloudTrail for Permissions Audit

Policy Simulator and CloudTrail are the day-to-day tools for verifying IAM identity federation and permission boundaries setups.

Policy Simulator

The IAM Policy Simulator evaluates whether a principal has permission for a specific action against a specific resource without performing the action. It considers identity policies, resource policies, permission boundaries, and SCPs. Use it to validate boundary changes before production rollout.

CloudTrail for Authorization Audits

Every IAM authorization decision is logged to CloudTrail (AssumeRole, ConsoleLogin, Decode AuthorizationMessage). DOP-C02 scenarios asking "which user assumed this role at this time" are CloudTrail queries. Combine with CloudTrail Lake for SQL-queryable multi-year history.

常考陷阱 (Common Exam Traps)

DOP-C02 has predictable IAM identity federation and permission boundaries gotchas:

1. Storing GitHub secrets as IAM access keys — wrong. Always OIDC federation with AssumeRoleWithWebIdentity.
2. Confusing SCPs with permission boundaries — SCPs are Organizations-level (whole account), permission boundaries are per-IAM-entity. Delegation use cases are permission boundary; account-wide preventive controls are SCP.
3. Assuming permission boundaries grant permissions — they only restrict. Identity policy must still allow. Effective set is intersection.
4. Forgetting chained-role 1-hour session cap — pipelines longer than 1 hour using chained roles must refresh credentials.
5. Missing external ID for third-party trust — without external ID, confused deputy lets any account that learns your ARN assume the role.
6. Using IAM users for machines — always roles. EC2 instance profile, ECS task role, Lambda execution role, EKS IRSA. Never long-lived access keys.
7. Per-team role explosion (RBAC) instead of ABAC — for many similar teams, one ABAC role with session tags scales; one role per team is the wrong answer at scale.
8. Forgetting to deny boundary removal — if developers can call iam:DeleteRolePermissionsBoundary, the entire delegation model collapses. Explicit deny on boundary mutation is mandatory.
9. Trust-policy sub claim too permissive — repo:org/*:* lets any branch deploy. Pin to repo:org/repo:ref:refs/heads/main or :environment:production.
10. IMDSv1 left enabled — SSRF-vulnerable. Always enforce IMDSv2 token-required mode.

FAQ

Q1: When do I use SAML vs OIDC vs IAM Identity Center? SAML for legacy enterprise IdPs (ADFS, Okta classic). OIDC for modern web/mobile apps and CI systems (GitHub Actions, Cognito user-facing). IAM Identity Center for centralized human access across many AWS accounts — it wraps SAML and adds account-aware UX. DOP-C02 default for human access is Identity Center; default for CI is OIDC.

Q2: Permission boundary or SCP for delegating role creation? Permission boundary. SCPs cannot be set on yourself within an account; only the Organizations management account or delegated admin can change SCPs. Permission boundaries are set by IAM administrators within an account on individual users/roles. Delegating "developers can create roles up to this ceiling" is exactly the permission boundary use case.

Q3: Can a permission boundary grant permissions an SCP forbids? No. SCP is evaluated first as an outer ceiling. Permission boundary then narrows further. Identity policy must also allow. The effective set is the intersection of all three. Removing an action from the SCP removes it for everyone in the account regardless of boundary or identity policy.

Q4: How do I let GitHub Actions deploy without storing AWS keys? Configure a GitHub OIDC identity provider in your AWS account. Create a deploy role with a trust policy that allows sts:AssumeRoleWithWebIdentity from token.actions.githubusercontent.com with a sub claim pinned to your specific repo and branch (e.g., repo:org/repo:ref:refs/heads/main). Configure the workflow to call aws-actions/configure-aws-credentials@v4 with the role ARN. Workflow obtains short-lived credentials per run.

Q5: What is ABAC and when does it beat RBAC? ABAC uses tags on principals and resources to grant access based on attribute matching (e.g., aws:PrincipalTag/project = aws:ResourceTag/project). RBAC uses roles per access pattern. ABAC wins when many teams share the same access pattern but on disjoint resource sets — one role for 100 project teams instead of 100 roles. Requires disciplined resource tagging and IdP-supplied session tags.

Q6: How does role chaining differ from direct AssumeRole? Role chaining is when one role assumes another (Role A → Role B). Direct AssumeRole is from a long-lived principal (IAM user) or federated session to a role. Chained roles are capped at 1-hour session duration regardless of the target role's MaxSessionDuration. First-hop sessions can be up to 12 hours.

Q7: What is the external ID for and when must I use it? External ID is a shared secret in the trust policy condition sts:ExternalId. Required when granting a third-party (e.g., Datadog) cross-account access. Without it, confused deputy is possible: an attacker who learns your role ARN could assume the role from a different customer's account at the third party. AWS strongly recommends external ID for any cross-account trust to a service you do not control.

Q8: Can I use permission boundaries on IAM users, or only on roles? Both. Permission boundaries attach to IAM users and IAM roles. They have no effect on AWS service principals or root users. For IAM Identity Center–provisioned roles, the permission set definition includes the boundary; modifying the role's boundary directly is overwritten on the next provisioning sync.

Q9: Why does my Lambda role fail an action that the boundary allows? Because the boundary is a ceiling, not a grant. The Lambda execution role's identity policy must also allow the action. Check both: the identity policy attached to the role AND the permissions boundary. Effective permissions are the intersection.

Q10: How do I detect cross-account access leakage? IAM Access Analyzer External Access Findings. Enable Access Analyzer in every account (or use the Security delegated admin), define your zone of trust as your Organization, and Access Analyzer continuously evaluates resource policies on S3 buckets, KMS keys, IAM roles, Lambda functions, Secrets Manager secrets, SQS queues, and more for cross-zone access. Findings flow to Security Hub.

Summary — IAM Identity Federation and Permission Boundaries Mental Model

IAM identity federation eliminates long-lived credentials by trusting external IdPs; permission boundaries enforce ceilings on what delegated administrators can grant. On DOP-C02 Task 6.1, the right answer always combines: SCPs at the OU level, permission boundaries on developer-created roles, identity policies for actual permissions, ABAC for scaling across teams, OIDC federation for CI, IAM Identity Center for humans, machine roles (instance profile, task role, execution role) for compute, IAM Access Analyzer for continuous validation, and CloudTrail for audit. Every Pro-tier identity-and-access scenario blends three or more of these — single-layer answers are distractors.

The mature DOP-C02 answer pattern is layered: SCP fences the account; permission boundary fences the developer; identity policy grants what the workload needs; ABAC scopes by tag; session policy narrows per-call. Federation is the universal entry point — humans via Identity Center, machines via OIDC or instance roles, third parties via external ID. Long-lived access keys are the wrong answer everywhere.