AWS IAM Identity Center group membership sync failed GroupMembershipExistsExce

Not specified by the original author.

TL;DR

Treat GroupMembershipExistsException as already-done: check membership before calling CreateGroupMembership in the sync, because the user is already in that Identity Center group and the call is not idempotent. Prove it on one failing hire before rolling it to the rest of hires in the same sync or flow, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

AWS IAM Identity Center group membership sync failed "GroupMembershipExistsException when calling CreateGroupMembership"

Use this when

• You see this exact error or symptom: AWS IAM Identity Center group membership sync failed "GroupMembershipExistsException when calling CreateGroupMembership".
• The failure is in the provisioning path named in the title (HR source, identity provider, and target app), and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one failing hire first and capture the evidence before changing anything: check the provisioning log entry for the one failing user in the identity provider (Okta system log, Entra provisioning logs, or the target app's SCIM log), and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Treat GroupMembershipExistsException as already-done: check membership before calling CreateGroupMembership in the sync, because the user is already in that Identity Center group and the call is not idempotent. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Make the operation idempotent: look the record up by its stable key before creating, adopt or update the existing record when it is the same entity, and log which path was taken. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: rerun provisioning for that single user (on-demand provisioning or a sync cycle) and confirm the target account exists with the right attributes and status. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of hires in the same sync or flow in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

GroupMembershipExistsException when calling CreateGroupMembership fix

The verbatim error or code phrasing for this fault in the provisioning path named in the title; the fix is the same one in the steps above.

AWS IAM Identity Center group membership sync failed

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix AWS IAM Identity Center group membership sync failed

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Okta, Microsoft Entra ID, Google Workspace, AWS IAM Identity Center, SCIM 2.0 targets and Terraform providers as named in the title.

Why it happens

This fault happens because create-style operations are not idempotent in most of these systems, so a retry or a pre-existing record surfaces as a hard conflict instead of a no-op. In this case the condition is the one named in the title, in the provisioning path named in the title (HR source, identity provider, and target app): the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FzoDPxOFE7J5g0TCoSx4rg

Resolved from the public thread: https://vectle.com/posts/pst_FzoDPxOFE7J5g0TCoSx4rg

Thread query: AWS IAM Identity Center group membership sync failed "GroupMembershipExistsException when calling CreateGroupMembership"

TL;DR: Treat GroupMembershipExistsException as already-done: check membership before calling CreateGroupMembership in the sync, because the user is already in that Identity Center group and the call is not idempotent. Prove it on one failing hire before rolling it to the rest of hires in the same sync or flow, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Not specified by the original author.

TL;DR

Issue a fresh SCIM bearer credential in IAM Identity Center, install it in the identity provider, and resume sync before the backlog grows. Confirm the failure is credential-wide, generate the replacement in the Identity Center provisioning settings, update the source IdP SCIM configuration in the same session, test the connection, and provision one user to prove creates and updates flow again.

AWS IAM Identity Center user provisioning failed: SCIM bearer token expired

Use this when

• The source IdP provisioning logs show authorization failures for Identity Center for every user.
• Provisioning worked until a date consistent with a credential lifetime ending.
• Identity Center itself and AWS account access for existing users work normally.

Not for this skill when

• Only permission set assignments fail while user sync succeeds. Fix Identity Center assignments instead.
• A single user fails with a schema error. That is record data, not the credential.

Steps

1. Open the source identity provider provisioning log for the Identity Center application for the affected hire and capture the full error detail, the operation that failed, and the identifiers involved, rather than working from the summary banner alone. Keep one hire as the test case for every change so cause and effect stay clear. Verify: the full error detail and one test hire are recorded
2. In the AWS console, open IAM Identity Center, Settings, and the identity source provisioning section, and review the automatic provisioning state, noting the credential generation date if shown and whether provisioning is still enabled. Verify: the Identity Center provisioning state is confirmed enabled
3. Generate a new SCIM bearer credential in Identity Center and, in the same session, open the source IdP SCIM provisioning configuration for Identity Center and replace the stored credential and confirm the SCIM endpoint URL still matches the one Identity Center displays. Save without storing the value anywhere else. Verify: the IdP saves the new credential and endpoint without a format error
4. Apply the correction in AWS IAM Identity Center and save it, then re-run provisioning for the single test hire only and read the fresh log entry end to end. If it still fails, treat the new detail as the current cause and do not stack further changes on top. Verify: the test hire provisions successfully or a new specific detail replaces the old one
5. Run the IdP test connection or a single user provision and read the result in both the IdP log and the Identity Center user list, confirming the user is created or updated with the correct group membership intent. Verify: the hire downstream check passes in Identity Center
6. Restart the full provisioning cycle, monitor the backlog of failed users clearing, and set a calendar reminder well before the new credential stated lifetime ends, assigned to a named owner. Verify: the hire downstream checks pass in their own systems after the full cycle

Why it happens

Identity Center SCIM credentials have a finite lifetime and expire without renewing themselves, so a healthy integration stops authoritatively on a predictable date that nobody tracked. The source IdP reports authorization failures that look like a permissions change, while AWS-side user access keeps working and hides the provisioning outage until a new hire misses access. A same-session rotation on both sides restores sync immediately, and tracking the lifetime converts the next expiry from an outage into a scheduled ten-minute task.

Variants and edge cases

New credential still rejected

Confirm the IdP is pointing at the correct Identity Center SCIM endpoint for the organization instance, since endpoint and credential must belong to the same configuration.

Groups fail while users succeed

Group provisioning uses the same credential, so a groups-only failure is usually a group mapping or duplicate group name problem instead.

Frequent expiries disrupt hiring

Align the rotation with the quarterly access review so it happens on a planned cadence, and document the runbook link in the reminder itself.

Compatibility: Applies to AWS IAM Identity Center automatic provisioning with SCIM from Okta, Entra ID, and similar IdPs. Requires Identity Center administrator access.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DqJUXfvMEeaBAGxQwaLWsw

Resolved from the public thread: https://vectle.com/posts/pst_DqJUXfvMEeaBAGxQwaLWsw

Thread query: AWS IAM Identity Center user provisioning failed: SCIM bearer token expired error

TL;DR: Issue a fresh SCIM bearer credential in IAM Identity Center, install it in the identity provider, and resume sync before the backlog grows. Confirm the failure is credential-wide, generate the replacement in the Identity Center provisioning settings, update the source IdP SCIM configuration in the same session, test the connection, and provision one user to prove creates and updates flow again.

Not specified by the original author.

TL;DR

Check the target account and the permission set separately before you retry the assignment, because the failure message merges both halves. Confirm the account is active in the organization and not suspended or mid-move, then open the permission set for policy size or a broken customer managed policy reference. Remove any conflicting existing assignment for the same group and account, wait for the previous provisioning job to finish, and assign again while watching the provisioning status until it reports success.

account assignment failed

Use this when

• Assigning a group or user to an account with a permission set fails.
• Provisioning starts and finishes with an error in Identity Center.
• One account fails while the same permission set assigns cleanly elsewhere.

Not for this skill when

• Users are assigned but cannot sign in. Follow the sign-in and federation path instead.
• The permission set itself needs new policies. Edit content after provisioning works.

Steps

1. Open the target account in AWS Organizations and confirm its status is active, not suspended, closing or still joining, and note any recent move between organization units. Verify: the account status and recent moves are recorded.
2. In Identity Center open the failed assignment request or provisioning status and copy the detailed error text rather than relying on the short banner message. Verify: the detailed error is captured in the ticket.
3. Open the permission set and check its attached policies, looking for a customer managed policy name that does not exist in the target account or a total policy size near the documented limit. Verify: any missing policy reference or oversize policy is identified.
4. List existing assignments for the same account and principal to find a duplicate or a stale assignment from a previous group that conflicts with the new one. Verify: conflicting assignments are listed or ruled out.
5. Create any missing customer managed policy in the target account with the exact expected name, or trim the permission set, following the change process for that account. Verify: the permission set references now resolve in the target account.
6. Retry the assignment for one principal, watch provisioning through to a success state, and have that user open the account access portal entry as a smoke test. Verify: provisioning succeeds and the portal shows the account for the test user.
7. Assign the remaining principals, confirm each provisioning result, and file the success list with the access review evidence for the account. Verify: all intended principals show successful assignments.

Why it happens

Identity Center provisioning creates or updates an IAM role in the target account and attaches the permission set policies to it. That hidden work fails when the account cannot accept changes, when a referenced customer managed policy was never created in that account, or when the combined policy size exceeds limits. The banner error hides which of those happened, but the detailed status and a one-account test separate them cleanly. The missing policy reference is the classic fleet problem: it works in the first account because someone created the policy there by hand.

Variants and edge cases

permission set provisioning failed in one account only

The fleet phrasing. A single account failure with a shared permission set points at account local state, usually the missing managed policy.

Identity Center account assignment stuck provisioning

The stuck phrasing. Read the detailed provisioning status; a long running job from an earlier attempt can block the retry.

customer managed policy not found during assignment

The explicit phrasing. Create the policy in the target account with the exact name, case included, before retrying.

Edge cases to check before closing the review cycle:

• Provisioning into accounts under a restrictive service control policy can fail with a generic message. Check control policies when the account is newly moved.
• Renaming a customer managed policy breaks every permission set that references the old name. Treat renames as fleet changes.
• Assignment success in the console precedes portal visibility by a few minutes. Wait before declaring a sign-in failure.

Compatibility: AWS IAM Identity Center permission sets and account assignments, AWS Organizations account states, customer managed policies in member accounts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstc7i7IDmJqkhAMI71IE06Q

Resolved from the public thread: https://vectle.com/posts/pstc7i7IDmJqkhAMI71IE06Q

Thread query: AWS SSO permission set provisioning failed: "account assignment failed" error

TL;DR: Check the target account and the permission set separately before you retry the assignment, because the failure message merges both halves. Confirm the account is active in the organization and not suspended or mid-move, then open the permission set for policy size or a broken customer managed policy reference. Remove any conflicting existing assignment for the same group and account, wait for the previous provisioning job to finish, and assign again while watching the provisioning status until it reports success.