What is AWS IAM advanced — roles, policies, and permission boundaries?

Advanced IAM concepts for secure, scalable AWS access management: Role assumption chain: EC2 → assumes Role A (instance profile) → Role A can assume Role B (cross-account) → Role B can assume Role C. Each step uses STS AssumeRole with temporary credentials. Max session duration configurable (up to 12h for console, 43,200s for API). Cross-account access: Account A (source) creates a role with Account B as trusted entity in trust policy. Account B user assumes the role: aws sts assume-role --role-arn arn:aws:iam::AccountA::role/ReadS3 --role-session-name session1. Returns temporary credentials. Use Organizations for centralized management. Permission Boundaries: IAM entity (user/role) level — set maximum permissions an entity can have, even if their permission policies grant more. Prevents privilege escalation: developer can't grant themselves more permissions than their boundary allows. Example: developer has AdministratorAccess but boundary only allows S3/DynamoDB → developer can only use S3/DynamoDB. SCP (Service Control Policies): Organization-level guardrails — apply to all accounts/OUs. Define what services/actions are EVER allowed in an account. Even account root can't bypass SCPs. Example: Deny EC2 in non-approved regions. Attribute-Based Access Control (ABAC): control access based on tags. Tag resources and IAM principals with same tags → policy uses condition keys. Scales without adding new policies: new resource with matching tag automatically accessible. AWS Organizations: manage multiple AWS accounts centrally. Account hierarchy: Management account → OUs (Organizational Units) → Member accounts. SCPs, centralized billing, AWS SSO/Identity Center.