In AWS IAM Identity Center, what exactly is a permission set, and what is created inside a member account when you assign one to a group?

## Template versus grant The most common confusion in Identity Center is treating a permission set as if it were the permission itself. It is not. There are two distinct objects: - The **permission set** — created once, in the Identity Center instance, describing *what* access looks like. - The **account assignment** — the triple *(principal, permission set, target account)* that says *who* gets that access *where*. One permission set called `ReadOnly` can be assigned to fifteen different groups across forty accounts. Editing it changes all forty. ## What a permission set contains - **AWS managed policies** attached by name, for example `ReadOnlyAccess` or `AWSLambda_ReadOnlyAccess`. - **Customer managed policy references** — a *name*, not a document. The policy with that exact name must already exist in every account the permission set is provisioned into, or provisioning fails there. This is the mechanism for per-account variation of the same permission set. - An **inline policy**, a single JSON document carried with the permission set itself. - An optional **permissions boundary**, capping whatever the above grant. - A **session duration**, expressed as an ISO-8601 duration such as `PT1H` or `PT8H`. As of 2026 the maximum is 12 hours; the default is one hour. - A **relay state**, which is just the console page the user lands on after sign-in. ## What provisioning actually does The moment you assign the permission set to a group in account `111122223333`, Identity Center reaches into that account and creates an IAM role: ``` arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/eu-west-1/AWSReservedSSO_ReadOnly_0a1b2c3d4e5f6789 ``` The policies you listed are attached to it, and its trust policy allows only the Identity Center SAML provider in that account to assume it. That role is a completely ordinary IAM role from the account's point of view — it appears in the IAM console, in CloudTrail, in Access Analyzer findings — but it is **managed**: it carries the `AWSReservedSSO_` name prefix and the `/aws-reserved/sso.amazonaws.com/` path so that both humans and tooling can recognise it as owned by Identity Center. If you attach an extra policy to it by hand, the next provisioning run reconciles it away. ## The hash suffix, and why it matters The trailing suffix is generated per account, so the same permission set has a **different role ARN in every account**. Any place you want to name that principal — a bucket policy, a KMS key policy, a cross-account trust — must therefore match with a wildcard rather than a literal ARN: ```json "Condition": { "ArnLike": { "aws:PrincipalArn": "arn:aws:iam::111122223333:role/aws-reserved/sso.amazonaws.com/*/AWSReservedSSO_ReadOnly_*" } } ``` A candidate who has actually operated Identity Center knows this, because the first cross-account bucket policy they wrote against a hard-coded SSO role ARN broke the day someone re-provisioned it. ## Drift and re-provisioning Changing a permission set marks it as needing re-provisioning in the accounts where it is assigned. In the modern console this happens for you, but the underlying API operation — `ProvisionPermissionSet` — is worth knowing about, because a permission set that references a customer managed policy missing from one account will show that account as failed while the rest succeed. Provisioning is per account and can partially fail. ## Designing the set of permission sets The practical guidance interviewers listen for: - Keep the number of permission sets small and job-shaped — `ReadOnly`, `Developer`, `Billing`, `SecurityAudit`, `AdministratorAccess` — rather than one per team per account, which recreates the sprawl you left IAM users to escape. - Assign to **groups**, never to individual users; the group is the thing your identity provider already manages. - Express per-account differences through customer managed policy references or condition keys, not by cloning the permission set. - Set the session duration to the shortest length people can actually work with, because that duration is also your revocation lag. - Use a permissions boundary on any permission set that is allowed to create IAM roles, so that delegated administrators cannot mint something wider than themselves. ## The shape of a good answer Say "template, plus an assignment that provisions a real IAM role in the target account", name the `AWSReservedSSO_` prefix, and mention that the ARN differs per account. That trio proves hands-on exposure rather than documentation reading.