Security, Compliance, and Governance practice questions

With an external IdP, Identity Center authorises only users and groups that exist in its identity store; SCIM keeps that store in sync.

Authentication at Entra ID succeeds, but Identity Center cannot match the incoming assertion to a user, because new joiners were never provisioned into its identity store. Identity Center has no just-in-time provisioning from SAML. Enabling SCIM automatic provisioning from Entra ID creates the users and their group memberships and removes them when they leave. Manual creation works once but adds effort for every change; re-assigning permission sets or adding SAML attributes does not create identities.

1. Note the symptom: the IdP authenticates the user, Identity Center rejects them.
2. Recall that Identity Center needs a matching user in its identity store and does not create one from SAML.
3. Choose the mechanism that keeps users and groups in sync automatically: SCIM.
4. Discard one-off manual fixes when the constraint is least ongoing effort.

Exam tip: No SCIM, no new users: Identity Center does not provision just in time from a SAML assertion.

Permission sets can reference customer managed policies, which Identity Center resolves by name and path in each target account.

Referencing a customer managed policy lets one permission set carry account-specific permissions, because each account holds its own version of a policy with the same name and path. Identity Center does not create that policy; if it is missing from an account, provisioning to that account fails. The pattern of success in 3 accounts and failure in 17 indicates the policy exists only in 3. Deploying it everywhere, for example with StackSets, fixes provisioning. SCPs, RAM sharing and size limits do not explain a per-account split.

1. Note that provisioning succeeds in some accounts and fails in others.
2. Recall how customer managed policy references resolve: same name and path in each account.
3. Conclude the policy is missing where provisioning fails.
4. Deploy the policy to all assigned accounts before reprovisioning.

Exam tip: A customer managed policy reference in a permission set needs the same-named policy, on the same path, in every assigned account.

IAM Identity Center attributes for access control pass identity-source attributes into each session as aws:PrincipalTag values, enabling ABAC with one permission set.

ABAC scales because the policy does not change as projects are added: it compares the user's attribute with the resource's tag. In Identity Center, the attribute must reach the session as a principal tag, which is what attributes for access control does (from the SAML assertion or the identity store). Tagging the permission set's role cannot work, because one role serves every assigned user, and per-project groups or per-engineer policies break the no-new-artifact constraint.

1. Spot the constraint: no new permission set, group or policy per project.
2. That points to ABAC: one policy comparing a user attribute with a resource tag.
3. Ask how the user's attribute reaches the session: Identity Center attributes for access control.
4. Reject role tags, because the AWSReservedSSO role is shared by all assigned users.

Exam tip: With Identity Center, ABAC uses aws:PrincipalTag from attributes for access control, not tags on the shared permission-set role.

CI/CD platforms that issue OIDC tokens should use IAM OIDC federation instead of stored access keys.

GitHub Actions can request an OIDC token for each workflow run. With an IAM OIDC identity provider for GitHub and a role that trusts it, the workflow calls AssumeRoleWithWebIdentity and gets temporary credentials that expire automatically. Nothing long-lived is stored. Rotating IAM user keys still leaves long-term credentials, Roles Anywhere needs a PKI the scenario does not call for, and an unauthenticated Cognito role is not access control.

1. Identify the problem: long-term IAM user keys stored outside AWS.
2. Check what the platform can present: GitHub Actions issues OIDC tokens.
3. Federate with an IAM OIDC provider and a role per account.
4. Reject options that keep long-term keys or open access to unauthenticated callers.

Exam tip: If the platform issues OIDC tokens, federate with IAM and drop the access keys.

OIDC federation trust policies must scope the token's subject claim, not just its audience.

The aud claim only proves the token was minted for AWS STS; every GitHub workflow can produce such a token. The sub claim carries the repository and ref (or environment) of the run, so an exact match on repo:example-org/payments:ref:refs/heads/main restricts the role to that branch of that repository. A wildcard over the organization is still too broad, and organization IDs or external IDs do not apply to web identity callers.

1. Note that the audience check alone lets any repository's workflow in.
2. Recall which claim identifies the repository and branch: sub.
3. Match it exactly for the one repository and branch allowed.
4. Reject conditions designed for AWS principals (PrincipalOrgID, ExternalId).

Exam tip: For GitHub OIDC, aud says the token is for AWS; sub says who is asking. Always restrict sub.

Amazon Cognito user pools provide customer identity: sign-up, sign-in, social federation and OIDC tokens for APIs.

The app needs a user directory with email sign-up, social sign-in and tokens that the API can validate. That is a Cognito user pool: it federates Google and Apple, issues ID and access tokens, and integrates with API Gateway through a Cognito authorizer. Identity pools only exchange tokens for AWS credentials, Identity Center serves the workforce, and IAM OIDC providers give no directory or application tokens.

1. Classify the users: consumers of the company's own app.
2. List the needs: sign-up, social sign-in, tokens for an API.
3. Match them to a Cognito user pool with an API Gateway Cognito authorizer.

Exam tip: Customer sign-up and sign-in for your app: Cognito user pool. AWS credentials for those users: identity pool.