Free Practice Questions for SailPoint Identity-Security-Administrator Exam

The statement is incorrect. Identity Security Cloud prevents access-request self-approval by default. If the requester or access recipient belongs to a Governance Group that has been configured as an approval reviewer, SailPoint does not automatically approve the request merely because that person belongs to the group.

Instead, the requester or recipient is omitted from the Governance Group review. Other valid members of the group can review the request on behalf of the Governance Group. If the requester or recipient is the group's only member, the approval responsibility is reassigned to that person's manager. If no manager exists, Identity Security Cloud can ultimately route the approval to an administrator through its fallback behavior.

SailPoint does provide an optional automatic-approval configuration, but this is materially different. Auto-approval applies only when the configured reviewer is an individual identity and requires API configuration. SailPoint explicitly states that automatic approval does not apply when the configured reviewer is a Governance Group, even when the requester is its only member.

Study Guide Reference: Access Management — Access Request Approvals, Governance Groups, Preventing Self-Approval and Automatic Approval.

===============

Yes. Identity Security Cloud identity profiles support stronger verification for password-reset and account-unlock operations. When two-factor authentication is enabled for these functions, users must successfully complete two configured identity-verification methods before Identity Security Cloud permits the password reset operation. SailPoint explicitly documents this behavior under the identity profile's Password Reset and User Unlock settings.

Available verification methods can include a verification code or call to a configured phone number, a verification message delivered to an email address, security questions, Helpdesk-provided codes, or supported external MFA integrations. Administrators must ensure that the underlying identity attributes—such as phone numbers and email addresses—contain valid data when those methods are selected.

This password-reset authentication control should be distinguished from the Multifactor Authentication Sign-In Method , which uses an authenticator application to protect normal Identity Security Cloud sign-in. Both mechanisms strengthen authentication, but they protect different stages of account access.

Study Guide Reference: Access Management — Identity Profile Security Settings, Two-Factor Authentication, Password Reset and User Unlock Methods.

===============

The statement is incorrect because Attribute Sync does not synchronize entitlement information from a source into Identity Security Cloud. Its purpose is to keep selected source account attributes synchronized with corresponding identity attributes maintained in Identity Security Cloud.

For example, an organization's authoritative identity data might contain a user's department, title, or other business attribute. If a corresponding account attribute on a connected target source is configured for Attribute Sync, Identity Security Cloud can detect that the account value no longer matches the identity value and provision an update to the source account. SailPoint explicitly states that Attribute Sync uses identity information to keep account data on sources consistent with identity data.

Entitlements are handled through separate aggregation mechanisms. Entitlement aggregation imports entitlement objects and their metadata from external sources into Identity Security Cloud.

Therefore, the proposed statement confuses two distinct processes: Attribute Sync pushes identity-derived account-attribute changes toward target accounts, whereas entitlement aggregation loads entitlement information from governed sources.

Study Guide Reference: Provisioning — Attribute Synchronization, Identity-to-Account Attribute Mapping and Entitlement Aggregation.

===============

The statement accurately describes the function of an Identity Provider in a federated authentication architecture. An IdP authenticates users and provides trusted identity or authentication information to a Service Provider. This enables the Service Provider to rely on an established trust relationship instead of independently validating the user's primary credentials.

In a SAML-based implementation, the Identity Provider authenticates the user and generates a signed SAML assertion. The assertion contains information that allows the Service Provider to determine that the user's authentication has been successfully completed. Depending on configuration, additional identity attributes can also be included.

Identity Security Cloud can operate as a SAML Service Provider and rely on an organization's external Identity Provider for user authentication. This allows enterprises to centralize authentication and integrate SailPoint access with existing single sign-on infrastructure.

The critical concepts are trust, centralized authentication, and secure transfer of authentication assertions between the IdP and Service Provider. The proposed statement correctly identifies each of these fundamental IdP responsibilities.

Study Guide Reference: Access Management — Federated Identity, Identity Providers, SAML Authentication, Service Provider Integration.

===============

This approach satisfies the stated provisioning requirements. Identity Security Cloud roles can use identity attributes such as department as assignment criteria. Therefore, a standard role can be configured so that identities whose department equals Finance automatically qualify for the role, regardless of whether their employment type is employee or contractor.

The role can then contain the Office 365 E3 entitlement, either directly or through an appropriate access profile. When an identity satisfies role membership criteria, Identity Security Cloud automatically assigns the role and provisions its associated access to the identity's applicable source account. When the identity ceases to meet the criteria, the role and associated provisioned access can be removed.

This design does not indiscriminately assign a default Office 365 license to contractors throughout the organization. It targets Finance identities and grants the specific E3 access required by the scenario. It also avoids deliberately assigning both the default license and E3 license to the same Finance identity.

Study Guide Reference: Provisioning — Automated Role Assignment, Identity Attribute Criteria, Role-Based Provisioning and Entitlement Assignment.

===============

This approach directly violates the stated requirements. The scenario explicitly requires Finance users to receive an Office 365 E3 license and further states that no Finance employee or contractor should receive more than one type of Office 365 license. The proposed configuration assigns Finance contractors both the default Office 365 license through an access profile and the Office 365 E3 license separately.

Identity Security Cloud access profiles are bundles of entitlements that can be automatically provisioned through role assignment. If an access profile containing the default license is included in the role, that access will be granted when the contractor satisfies the role criteria. Adding E3 separately would therefore produce the duplicate-license condition the design is expressly intended to prevent.

The solution is additionally incomplete because it targets only Finance contractors while the requirement applies to every Finance department user , including employees. A better design is one Finance role whose assignment criteria encompass all Finance users and whose access contains only the required E3 license.

Study Guide Reference: Provisioning — Roles, Access Profiles, Automated Provisioning, Assignment Criteria and Least-Privilege Access Design.

===============

The statement is correct. In SAML federation, the Entity ID uniquely identifies a participant in the trust relationship. When Identity Security Cloud is configured to use an external Identity Provider, the Identity Provider Entity ID entered in SailPoint must correspond to the EntityID specified in the IdP's SAML metadata.

This identifier helps Identity Security Cloud determine which trusted Identity Provider issued the authentication assertion. If the configured Entity ID does not match the expected IdP identifier, authentication processing can fail because the received federation information does not correspond to the configured trust relationship.

Administrators must also configure other SAML components correctly, including the Identity Provider login endpoint and signing certificate. The signing certificate enables Identity Security Cloud to validate the authenticity and integrity of SAML assertions received from the IdP.

It is also important to distinguish between the IdP Entity ID and the Identity Security Cloud Service Provider Entity ID. Each identifies a different side of the SAML relationship.

Study Guide Reference: Access Management — SAML Authentication, Identity Provider Configuration, Entity IDs and Federation Trust.

===============

The statement does not accurately describe how governance-group approval and escalation operate. When a governance group is configured as an approver, the request is associated with the group's members, and a member of that governance group can perform the approval on behalf of the group. The system is not designed to send the request exclusively to the manager of one active group member.

Escalation behavior is also broader than the proposed statement suggests. SailPoint documents that when governance-group approvals are escalated to a manager level, the request can be escalated to each member's manager . If a particular member does not have a manager, that member's approval can remain assigned while other members' assignments are escalated. If none of the members has a manager, the applicable approvals can progress to the configured fallback approver.

Therefore, "only to the manager of an active member" incorrectly reduces a multi-member governance-group escalation process to one manager and does not reflect the documented routing behavior.

Study Guide Reference: Access Management — Governance Group Approvals, Escalation Chains, Access Request Reviewers.

===============

The statement correctly describes the relevant Configuration Hub capability, although current SailPoint terminology generally refers to configuration backups, configuration files, and drafts rather than simply "templates." Configuration Hub is specifically designed to manage supported Identity Security Cloud configuration objects through backup, comparison, migration, and deployment operations.

An administrator can back up configuration objects from one tenant, establish a tenant connection, prepare a deployment draft, and migrate configurations into another tenant. This directly supports maintaining consistency between environments such as sandbox/staging and production. SailPoint explicitly documents deploying backups from one connected tenant to another.

Configuration Hub also supports exported sp-config JSON configuration files. Those files can subsequently be uploaded and used to migrate configurations between tenants, including tenants in different domains or regions where supported.

For recovery, Configuration Hub can restore supported configurations from previous automated or manual backups by preparing and deploying a draft. It is a configuration-management mechanism rather than a full business-data backup system.

Study Guide Reference: Platform — Configuration Hub, Configuration Backups, Tenant Connections, Configuration Files and Cross-Tenant Deployment.

===============