SailPoint Identity-Security-Administrator SailPoint Certified Identity Security Administrator Exam Practice Test

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 correct. Identity Security Cloud defines several identity attributes by default, but User Name (uid) , Work Email (email) , and Last Name (lastname) have special required-status rules. SailPoint documentation states that these three attributes must have mappings for every identity profile and cannot be null for any identity.

User Name has an additional uniqueness requirement: it must be unique across identities from all identity profiles in the tenant. Work Email must contain a non-null value, although Identity Security Cloud does not itself validate that the value conforms to a syntactically valid email-address format. Last Name likewise must be populated.

Administrators therefore need to ensure that the authoritative-source data, source mappings, transforms, or rules reliably generate these required values. If authoritative data cannot directly populate a required field, a transform or other supported mapping mechanism should be used to derive the necessary value.

These requirements help maintain consistent identity representation and support core platform functions such as identity correlation, display, authentication, and governance.

Study Guide Reference: Identity and Lifecycle Management — Identity Profile Attributes, Required Attribute Mappings, User Name, Last Name and Work Email.

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.

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

Yes. Checking these mapped attributes is a primary troubleshooting action for an Identity Exception. Identity Security Cloud defines User Name (uid) , Work Email (email) , and Last Name (lastname) as required identity attributes. Every identity profile must contain mappings for these attributes, and none of the resulting identity values can be null. User Name carries the additional requirement of being unique across identities in the tenant.

When an authoritative-source account is missing one or more required values during aggregation, Identity Security Cloud generates an Identity Exception instead of creating the identity normally. A duplicate User Name can also produce an exception. The administrator should therefore inspect the Identity Exceptions report, identify which required attribute is absent or invalid, and verify the corresponding source-account data and identity-profile mappings.

SailPoint's documented remediation is to correct the problematic source information and then aggregate the source again, either manually or through the next scheduled aggregation. If direct mapping cannot generate a required value, a transform or supported rule can derive it.

Study Guide Reference: Identity and Lifecycle Management — Identity Profiles, Required Identity Attributes, Identity Exceptions and Attribute Mappings.

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

This statement accurately describes one of the principal purposes of the Virtual Appliance. Identity Security Cloud is a SaaS platform, but many enterprise identity sources are located inside customer-controlled networks and cannot safely accept direct inbound connections from an external cloud service. The VA provides the secure intermediary required for these integrations.

SailPoint defines the VA as a Linux-based virtual machine deployed on the customer's infrastructure that connects Identity Security Cloud to organizational sources and applications through supported APIs, connectors, and integrations. The architecture is designed around outbound-only communication from the VA toward SailPoint's cloud environment. SailPoint does not initiate a direct inbound connection to the VA.

This architecture enables account and entitlement aggregation, account correlation support, provisioning, password-related operations, and other connector activities against internal sources while avoiding the need to expose those systems directly through the firewall.

SaaS connectors can eliminate the VA requirement for supported cloud services, but VA-based connectors remain fundamental when direct customer-network connectivity is required.

Study Guide Reference: Virtual Appliances — VA Purpose, On-Premises Source Connectivity, Outbound-Only Architecture and Source Integration.

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

The statement is incorrect. A disabled role is not the appropriate state for validating actual automated role assignment through identity processing. Identity Security Cloud documents that disabling a role prevents future automated assignment and removes the role association from identities. Consequently, keeping the role disabled and performing identity processing does not provide a valid operational test of whether the configured membership criteria will assign the role as intended.

For an automatically assigned role, administrators define the assignment criteria, configure the required access, and enable the role. Identity Security Cloud then evaluates identities against the assignment criteria during identity processing. An administrator can manually initiate this evaluation by selecting Apply Changes from the Roles page. Identities satisfying the criteria receive the role and its configured access; identities that no longer satisfy the criteria can have the assignment removed.

Administrators should carefully validate role criteria before broad production application, but disabling the role specifically prevents it from functioning as an automated role assignment.

Study Guide Reference: Access Management — Role Management, Role Assignment Criteria, Enabling Roles and Identity Processing.

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

Gather data from requestor to build search query.

Run the query to gather results.

Save and name the search query.

Schedule saved search query on a month cadence as requested.

The sequence follows the correct Identity Security Cloud Search workflow. First, the administrator must gather the audit requirements from the requestor, including which distribution list, identities, access attributes, or other conditions must be evaluated. Those requirements are then translated into an appropriate Search query. Second, the query must be executed so the administrator can confirm that it returns the intended records before automating it.

After validating the output, the administrator saves and names the query. Identity Security Cloud requires the query to exist as a saved search before a recurring subscription can be configured. Finally, the saved search is scheduled according to the requested monthly cadence. SailPoint supports subscriptions to saved searches with Daily, Weekly, and Monthly schedules and allows administrators to specify the numerical days of the month and execution times. Therefore, scheduling must occur after the query has been constructed, tested, and saved.

Study Guide Reference: Platform — Search, Building Search Queries, Saved Searches, Search Subscriptions and Scheduled Reporting.

The statement accurately describes the cryptographic trust model underlying SAML federation. In a typical SAML configuration, the Identity Provider (IdP) authenticates the user and issues a SAML assertion. The Service Provider (SP) validates the assertion, particularly its digital signature, by using certificate/public-key information associated with the trusted IdP. Private keys remain protected by their owners; the corresponding certificates containing public keys can be exchanged through configuration or SAML metadata.

For Identity Security Cloud operating as a SAML Service Provider, SailPoint requires administrators to obtain the IdP's signing certificate and configure it in Identity Security Cloud. SailPoint also provides Service Provider metadata that can be supplied to the IdP. This establishes the federation relationship and allows the participating systems to validate SAML messages according to the configured trust model. The critical concept is that passwords are not shared between the IdP and SP. Authentication assertions are trusted because they originate from an established federation partner and can be cryptographically validated.

Study Guide Reference: Access Management — Authentication Methods, SAML Federation, Identity Provider and Service Provider Trust.

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

This is not a valid description of how a canceled access request is handled. A cancellation terminates the request before it completes. Once an access request has entered a concluded Canceled state, it is no longer simply a pending approval waiting for an administrator to substitute a decision for the assigned reviewer.

Approval Management does give administrators powerful controls over pending governance work. Administrators can inspect requests, reassign current approvers, send reminders, cancel requests, and, where supported, overwrite the current approval step. Overwriting an approver is fundamentally different from reversing an already canceled request: the administrator is acting on the current approval step of an active request.

SailPoint documentation explicitly identifies Canceled as a concluded status and defines cancellation as termination of the request. The administrator's overwrite capability applies to an approval step, not to resurrecting a request after cancellation. A new request would normally be required when access is still needed after the original request has been terminated.

Study Guide Reference: Access Management — Approval Management, Access Request Status, Administrative Approval Actions.

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

This is a valid description of Separation of Duties (SoD) as an identity-governance control. SoD policies define combinations of access that should not be held by the same identity because combining those privileges could enable fraud, unauthorized transactions, or circumvention of internal controls. A detective implementation analyzes existing access and identifies identities that already violate a defined policy, allowing administrators to investigate, mitigate, revoke access, or document an approved exception.

Preventive policy evaluation applies the same governance principle before problematic access is granted. During an access-request or provisioning process, the proposed access can be evaluated against policy rules so that a potential conflict is identified before the access change is completed. SailPoint documents SoD policies as conflicting-access definitions and also documents preventive policy evaluation in its governance model. These controls provide measurable evidence that an organization is actively enforcing access-risk policies rather than merely documenting them.

Study Guide Reference: Supporting Governance — Separation of Duties, Policy Rules, Detective and Preventive Controls.

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

The statement is incorrect. A SaaS-based application does not inherently require a "cloud-based VA." Identity Security Cloud supports SaaS connectors that can connect supported cloud applications directly without requiring the customer to deploy a Virtual Appliance cluster.

SailPoint explicitly states that organizations can use a SaaS connector when they want to upload data to Identity Security Cloud from a source without a Virtual Appliance cluster . In contrast, VA-based connectors are used when direct connector communication must occur from the customer's controlled environment.

Furthermore, a SailPoint VA is not normally a SailPoint-hosted cloud appliance. SailPoint provides the virtual appliance image, but the VA is deployed on infrastructure procured or controlled by the customer. SailPoint manages and updates the appliance software while the customer provides the hosting environment and network connectivity.

Some cloud-hosted applications can still use VA-based connectors depending on network topology and connector design, but being a SaaS application alone does not impose a VA requirement.

Study Guide Reference: Virtual Appliances — VA-Based versus SaaS Connectors, VA Deployment Architecture and Cloud Application Connectivity.

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

The statement is incorrect. Purchasing or using an IGA platform that maintains security certifications or demonstrates alignment with regulatory frameworks does not automatically make the customer organization compliant with those requirements.

Regulatory compliance depends on the organization's own controls, processes, system configurations, access-governance practices, data-handling procedures, evidence collection, risk-management activities, and remediation processes. Identity Security Cloud provides capabilities that can support compliance obligations, but organizations must configure and operate those controls appropriately.

For example, Separation of Duties policies can detect conflicting access combinations. Certification campaigns enable managers, application owners, and other reviewers to validate whether users should retain particular access. Audit data provides evidence of governance decisions, access changes, and administrative actions. These features can materially support compliance assessments and audits.

However, the organization's auditors still evaluate whether applicable legal, regulatory, and internal-control requirements have actually been implemented and continuously maintained. Vendor certifications are supporting evidence, not blanket proof of customer compliance.

Study Guide Reference: Supporting Governance — Separation of Duties, Certifications, Audit Evidence, Governance and Regulatory Compliance.

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

The statement is correct. Identity Security Cloud supports two documented methods for defining role assignment: Standard Criteria and Identity List . SailPoint explicitly presents these options under Define Assignment > Choose Criteria Type when configuring automated role assignment.

Standard Criteria is the dynamic, data-driven option. Administrators can construct criteria using supported identity attributes, account attributes, or entitlements. Operators such as Equals, Does Not Equal, Contains, Starts With, and Ends With can be used where applicable, and multiple conditions can be organized with AND/OR logic. During identity processing, qualifying identities are assigned the role automatically.

Identity List provides a direct membership approach. Administrators search for and explicitly select the identities that should receive the role. It is appropriate when membership cannot conveniently be expressed through business attributes or when a controlled list of named identities is required.

After assignment configuration is saved and the role is enabled, Identity Security Cloud evaluates the role during identity processing; administrators can also initiate processing using Apply Changes.

Study Guide Reference: Access Management — Role Assignment, Standard Criteria, Identity List and Automated Role Provisioning.

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

Yes. This is an appropriate scenario for applying Separation of Duties (SoD). The fundamental purpose of SoD is to prevent a single identity from accumulating combinations of privileges that provide excessive control over a sensitive business or technical process. Assigning one person responsibility for user administration, application administration, and data backup management creates significant concentration of privilege. Such a person could potentially create or modify accounts, change application configuration or permissions, and manipulate or restore protected data without independent oversight.

Identity Security Cloud supports SoD policies by defining two sets of conflicting access. A violation occurs when an identity possesses qualifying access from both sides of the policy. Administrators can then investigate, remediate, or formally manage exceptions. SailPoint describes SoD as an internal control intended to reduce risk by preventing identities from possessing inappropriate combinations of access.

Therefore, separating these powerful administrative capabilities among different responsible individuals is consistent with least privilege and defense-in-depth governance.

Study Guide Reference: Supporting Governance — Separation of Duties, Conflicting Access, SoD Policies and Privileged Access Governance.

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

The statement is correct. Identity Profiles have a priority property that determines precedence when an identity is associated with accounts on more than one authoritative source. Lower numerical priority values represent higher precedence. This becomes important when several authoritative sources could potentially establish the same Identity Security Cloud identity.

SailPoint's Identity Profile REST API supports updating an existing Identity Profile through a PATCH operation. The Identity Profile data model contains the priority property, and it is not included among the properties that the Update Identity Profile endpoint prohibits from being modified. Consequently, an administrator can issue a JSON Patch operation against the /priority path to change that profile's precedence. SailPoint's published API documentation exposes both the priority field and the Identity Profile update operation.

Priority changes should be performed carefully because changing authoritative-source precedence can affect how identities are represented and which Identity Profile governs them when multiple authoritative accounts exist.

Therefore, using the REST API to modify Identity Profile priority is supported.

Study Guide Reference: Identity and Lifecycle Management — Identity Profile Priority, Authoritative Source Precedence and Identity Profile REST APIs.

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

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 correct. Identity Security Cloud allows administrators to configure a requestable role so that reviewers must provide justification when denying the requested access.

When configuring a role for access requests, administrators can enable the role for requests, define its approval process, and configure Require Comments behavior. SailPoint specifically provides an option named When a reviewer denies the request . Enabling this setting requires the reviewer to enter a comment or reason when rejecting the role request.

This requirement strengthens governance and auditability. A denial without explanation provides limited evidence about why the access was considered inappropriate. Requiring a comment records the business or security reasoning behind the decision, which can later assist administrators, access owners, auditors, and compliance personnel in understanding the approval history.

Comment requirements can also be configured at other stages, including when the requester submits the access request. Similar denial-comment controls exist for directly requestable entitlements.

Therefore, requiring a reviewer to document the reason for rejection is a supported role-request configuration.

Study Guide Reference: Access Management — Requestable Roles, Approval Processes, Require Comments and Access Request Governance.

The proposed sequence is incorrect because the administrator should not first apply the Identity Profile's Block Access From settings before defining the underlying network and geography restrictions.

Identity Security Cloud tenant restrictions are configured in two logical stages. First, the organization defines the networks and geographic rules that determine what locations are trusted or untrusted. Network restrictions are based on configured IP address ranges, while geographic restrictions can use trusted or blocked-country definitions. After these global security definitions exist, restrictions are applied to specific user populations through their Identity Profiles.

The Identity Profile does indeed contain Block Access From options such as Off Network and Untrusted Geography, so that part of the statement identifies a real configuration location. However, SailPoint explicitly warns that enabling Off Network without first defining an applicable network can block all users associated with that identity profile from accessing Identity Security Cloud.

Therefore, selecting Block Access From is a required application step, but describing it as the first configuration action makes the proposed solution invalid.

Study Guide Reference: Access Management — Restricting Tenant Access, Network Definitions, Geographic Restrictions and Identity Profile Security.

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

The proposed statement is incorrect because the displayed search syntax is malformed. To search for identities whose account count falls within an inclusive numerical range, Identity Security Cloud uses range-query syntax with properly matched square brackets.

The correct expression is:

accountCount:[1 TO 4]

Square brackets indicate that both endpoints are included. Therefore, a correctly formatted query would return identities with account counts of 1, 2, 3, or 4. The displayed expression, however, is missing the closing square bracket and does not follow the documented range syntax correctly.

The accountCount field represents the number of accounts associated with an identity across connected sources. Range searches are useful when administrators need to identify identities with unusually low or high account ownership, investigate orphaned access patterns, or perform access-analysis activities.

Because the specific proposed command is syntactically incomplete, it cannot reliably be treated as the documented query that returns identities with one through four accounts.

Study Guide Reference: Platform — Search Query Syntax, Range Queries, Identity Search Fields.

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

This is a valid troubleshooting approach. An Active Directory provisioning failure such as "There is no such object on the server" indicates that the connector attempted an operation against an object or directory reference that Active Directory could not resolve. Potential causes include an account or group being deleted or moved, an outdated distinguished name, an invalid entitlement reference, replication timing, or a provisioning operation targeting an object that no longer exists.

Searching SailPoint's technical knowledge and community resources for the exact connector error is therefore useful because connector-specific errors often have previously documented causes, configuration considerations, and remediation patterns. This should complement—not replace—tenant-side investigation. An administrator should correlate the error with provisioning activity, source information, account state, and the target system. Identity Security Cloud provides Search and audit information for investigating provisioning activity, while SailPoint technical resources provide additional connector-specific context. Current SailPoint documentation explicitly identifies provisioning activity as auditable and searchable.

Study Guide Reference: Provisioning — Troubleshooting Provisioning Errors, Active Directory Connector Operations, SailPoint Support Resources.

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

The statement is valid. The Identity Security Cloud Active Directory connector supports substantial identity-lifecycle functionality, including account aggregation, creation, modification, entitlement management, password-related operations, and provisioning. SailPoint documents Active Directory account provisioning and the use of Identity Security Cloud provisioning policies to create and manage accounts on the directory.

Active Directory can also serve as an authentication source through Pass-Through Authentication (PTA) . With PTA configured for an identity profile, users can authenticate to Identity Security Cloud using the network password associated with their Active Directory account. Identity Security Cloud passes the authentication operation through to the configured directory source rather than requiring a separate local SailPoint password.

Therefore, the AD integration is not restricted to account aggregation or read-only identity data. It can participate in both authentication and lifecycle administration, including provisioning users and managing access. Appropriate service-account permissions, VA connectivity, and provisioning configuration are required.

Study Guide Reference: Sources — Active Directory Connector, Pass-Through Authentication, Account Aggregation and Provisioning.

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

This action is valid. In Identity Security Cloud, the health state of an individual Virtual Appliance is exposed through VA status and alert indicators. A VA displaying a Connected status is operating normally and maintaining communication with the SailPoint tenant. Therefore, when an administrator reviews the appliances in a VA cluster and encounters a VA whose status is Connected, no remediation is required for that particular appliance.

The administrator should continue reviewing the remaining VAs because cluster health depends on the operational state of all participating appliances. Other statuses can require intervention. For example, an inactive or disconnected appliance can indicate network, configuration, certificate, or service-related problems. Warning and error indicators should be investigated to determine whether restart, connectivity troubleshooting, configuration correction, or escalation is required.

Consequently, treating a Connected VA as healthy and proceeding to inspect the next appliance is the correct operational response.

Study Guide Reference: Virtual Appliances — Monitoring Virtual Appliance Health, VA Status and Alert Messages.

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

This statement is correct and closely matches SailPoint's official definition of a source. Identity Security Cloud does not treat an external enterprise system itself as being physically contained within the tenant. Instead, it creates a source definition representing that application, database, directory, HR system, or other managed environment.

The source definition supplies the governance context through which Identity Security Cloud interacts with the underlying system. A connector gathers account and access information and associates that data with the source. Identity Security Cloud can then correlate source accounts to identities, aggregate entitlements, model access, perform certifications, support access requests, and—in the case of writable connectors—provision changes back to the external system.

SailPoint's current source-management documentation explicitly defines a source as the Identity Security Cloud representation of a third-party enterprise application, database, or directory-management system maintaining its own user accounts or personnel records.

This distinction between source and connector is important: the source is the governed system representation, while the connector provides the technical mechanism used to communicate with that system.

Study Guide Reference: Sources — Source Definitions, Connector Definitions, Source Accounts and Enterprise System Integration.

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

Yes. Removing the @entitlements(name:Manager_Access) portion produces a valid identity-oriented query structure. Identity Search supports the @access(...) nested object because an identity can possess multiple access items. SailPoint specifically documents @access(displayName:...) for identifying identities that possess a named access item and @access(source.name:...) for locating identities whose access originates from a particular source. Nested access queries can be combined with ordinary identity fields by using Boolean operators.

The remaining query therefore applies three conditions correctly: the identity must have been created during the specified 24-hour range, and the identity must satisfy either the New_Hire_Access condition or the Acme_HRMS source-access condition.

The problem with the original expression is the @entitlements(...) nested object. In SailPoint's searchable data models, @entitlements is used when examining objects such as access profiles or roles that contain entitlements; it is not the appropriate nested object for identity-level access searches. Identity-level entitlement holdings are searched through @access(...).

Study Guide Reference: Platform — Search, Nested Queries, Identity Access Fields and Boolean Query Construction.

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

This is a valid and specifically documented cause of missing entitlements during flat-file aggregation. When multiple rows represent different entitlements belonging to the same account, Identity Security Cloud expects the rows for that account to be grouped together according to the account identifier.

SailPoint's aggregation troubleshooting documentation explicitly addresses the condition in which only one or an incomplete set of entitlements is aggregated for accounts from a delimited file. The documented remediation is to ensure that the file is sorted by account ID . SailPoint's Generic Flat File prerequisites similarly state that all accounts and entitlements must be sorted by the account name so that all entitlement rows for an account appear together.

This requirement matters because the aggregation parser must correctly recognize consecutive records as belonging to the same logical account while assembling its multi-valued entitlement attributes. If the same account appears in separated regions of the file, the complete entitlement set may not be assembled as expected.

Therefore, sorting and grouping all rows for each account together is a fundamental preprocessing requirement when supplying multi-valued entitlement information through flat files.

Study Guide Reference: Sources — Flat File Aggregation, Delimited Files, Multi-Valued Entitlements and Aggregation Troubleshooting.

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

Waiting for an identity refresh is not the correct remediation for a missing source entitlement. Identity processing and entitlement aggregation perform different functions. Identity processing recalculates identity-related information and access relationships based on information already known to Identity Security Cloud; it does not independently discover a newly created entitlement that has never been successfully loaded from the external source.

New entitlement objects are discovered through entitlement aggregation or through supported account aggregation behavior, depending on the source and connector. SailPoint defines entitlement aggregation as the process of loading entitlement data from an external source into Identity Security Cloud. The completed aggregation records how many entitlements were discovered.

If an expected entitlement is absent, the administrator should inspect the source's entitlement configuration and schema, review aggregation status/history, confirm that the external entitlement exists, and run or troubleshoot an entitlement aggregation. SailPoint's troubleshooting guidance specifically directs administrators to perform entitlement aggregation when entitlement metadata is not being imported correctly.

Study Guide Reference: Sources — Entitlement Aggregation, Entitlement Schemas, Aggregation Troubleshooting and Identity Processing.

1. Define what values are needed to onboard a user in a managed system.

Select a match:

Create Account

2. Update an identity's phone number in Active Directory.

Select a match:

Attribute Sync

3. Customizable logic to match an account to an existing identity.

Select a match:

Correlation Rule

4. Supports user management in Active Directory.

Select a match:

IQService

The correct mappings correspond directly to the functions of SailPoint Identity Security Cloud provisioning and integration components. Create Account defines the account attributes and values that Identity Security Cloud uses when provisioning a new account on a managed source. SailPoint states that the Create Account configuration specifies which attributes are populated and how their values are determined.

Attribute Sync keeps account attributes on a target source synchronized with identity attributes. Therefore, if an identity's mapped phone-number attribute changes, Attribute Sync can provision the corresponding change to Active Directory.

A Correlation Rule provides customizable logic for matching source accounts to existing identities when straightforward attribute correlation is insufficient. Correlation fundamentally determines which identity owns a source account.

Finally, IQService is SailPoint's Windows service used with Active Directory to support provisioning and Windows-specific management operations. SailPoint explicitly requires IQService for Active Directory provisioning and related Windows functionality.

Study Guide Reference: Provisioning — Create Account; Attribute Sync; Account Correlation; IQService and Active Directory Integration.

No. Current Identity Security Cloud behavior does not automatically assign sp:scopes:all when an administrator or user creates a Personal Access Token without explicitly selecting scopes. SailPoint documents that when no scopes are selected, the default scope is assigned. That default provides permission only for API endpoints that do not require authorization; it is not equivalent to unrestricted access under sp:scopes:all.

The sp:scopes:all scope must be intentionally selected when required. Even then, it does not grant arbitrary privileges beyond the token owner's authority. Instead, it authorizes API scopes that are available through the user levels assigned to the user who created the PAT. Consequently, PAT permissions remain bounded by that identity's effective Identity Security Cloud privileges.

This behavior supports the principle of least privilege. SailPoint recommends selecting only the scopes necessary for the application or integration using the token rather than broadly assigning sp:scopes:all.

Therefore, leaving all scope checkboxes unselected does not implicitly grant all available API scopes.

Study Guide Reference: Platform — Personal Access Tokens, OAuth/API Scopes, sp:scopes:all and Least-Privilege API Authentication.

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

Yes, when the user's application access is governed through attribute-driven role assignment, a department change can trigger deprovisioning of access that is no longer appropriate. Identity Security Cloud roles can use mapped identity attributes such as Department as membership criteria. During identity processing, SailPoint evaluates whether the identity continues to satisfy those criteria.

If the user moves to another department and consequently ceases to satisfy the role's assignment criteria, the identity is removed from the role. SailPoint explicitly documents that when identities are removed from roles because of assignment-criteria changes, access assigned by those roles is removed or deprovisioned , unless the same access is independently provided through another role or assignment.

This implements birthright and role-based lifecycle governance: business changes such as department transfers should automatically cause obsolete access to be removed while new access appropriate to the destination department can be provisioned. SailPoint even provides a workflow template specifically addressing identity department changes and reassessment of old versus new access.

Thus, a department change is a valid deprovisioning trigger when the former application's access derives from criteria that the identity no longer satisfies.

Study Guide Reference: Provisioning — Automated Role Assignment, Attribute Changes, Role Deprovisioning and Department-Based Access Lifecycle.