Identity-Security-Administrator SailPoint Exam Lab Questions

The statement is incorrect because Governance Groups are not restricted to serving only as the primary owner of a Separation of Duties policy. Identity Security Cloud provides multiple ownership and governance assignments within SoD policy configuration.

For the Policy Owner , an administrator can select either an individual identity or a Governance Group. A policy can additionally have up to ten co-owners, and those co-owners may also include individuals or Governance Groups. Furthermore, the Violation Owner —the party responsible for handling violations generated by the policy—can be configured as an individual, an identity's manager, a Governance Group, or no explicitly selected owner, in which case responsibility can fall to the policy owner. SailPoint's current policy configuration documentation explicitly identifies these distinct ownership options.

Governance Groups are also used outside SoD policies. They can participate in access-request approvals, source ownership/governance, certification-related responsibilities, and scoped administration.

Therefore, saying Governance Groups can only be assigned as policy owners incorrectly limits their supported governance functions.

Study Guide Reference: Supporting Governance — Governance Groups, SoD Policy Ownership, Co-Owners and Violation Ownership.

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

The statement is explicitly incorrect. Identity Security Cloud allows users to hold multiple User Levels in many circumstances, and permissions from compatible User Levels are cumulative. However, SailPoint defines several combinations that cannot be assigned simultaneously because their delegated administrative scopes conflict.

One of the specifically prohibited combinations is Role Admin and Source Sub-Admin . SailPoint's User Level documentation lists this pair among the User Levels that cannot coexist on the same user. Other prohibited combinations include Role Sub-Admin with Source Admin, Role Sub-Admin with Role Admin, and Source Sub-Admin with Source Admin.

The distinction is important. A Role Admin has broad role-management privileges, whereas a Source Sub-Admin receives scoped administrative capabilities based on Governance Group associations with particular sources. Combining certain global and scoped administrative models could create inconsistent authorization behavior, so SailPoint prevents those assignments.

Administrators should therefore consult the User Level compatibility matrix before granting multiple elevated permissions rather than assuming that every User Level can be stacked.

Study Guide Reference: Platform — User Level Permissions, User Level Compatibility, Role Admin and Source Sub-Admin.

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

The statement is too absolute. Identity Governance and Administration platforms substantially automate and streamline access governance processes, but they do not necessarily eliminate human judgment or fully automate every review, approval, and audit activity.

For example, an IGA platform can automatically generate access certification campaigns, identify the access requiring review, notify reviewers, record their decisions, perform supported remediation, and produce audit evidence. However, designated managers, application owners, source owners, or other certifiers are still commonly required to decide whether individual access should be retained or revoked. SailPoint describes certifications as processes in which designated certifiers review users' access and explicitly approve or revoke it.

Similarly, approval workflows automate routing and enforcement but can still require human authorization. Audit functionality generates searchable events, reports, and evidence, while auditors and compliance professionals still assess whether the organization's controls satisfy applicable requirements.

SailPoint describes IGA as streamlining certification and audit processes by automating reviews, notifications, and audit-ready reporting—not as eliminating every human governance decision.

Study Guide Reference: General knowledge for Identity Security Administrators — Identity Governance and Administration, Access Reviews, Approvals, Audit and Governance Automation.

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

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.

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