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

This is not the standard Identity Security Cloud method for configuring role assignment criteria. Role membership can be automatically determined using defined identity or account-based criteria, or administrators can explicitly specify identities through an Identity List depending on the role configuration.

The Identity List mechanism is designed to identify users who should receive the role rather than create a separate universal exclusion list containing identities who must never receive it. When automatic assignment criteria are configured, identities satisfying those criteria can become role members based on the associated identity attributes, account attributes, or other supported conditions.

If a particular identity must not receive a role, administrators should design the role-assignment criteria so that the identity does not satisfy the required conditions or use another appropriate assignment strategy. Introducing an unsupported exclusion mechanism could create incorrect expectations about how role membership is calculated.

Roles are intended to package business-relevant access and automatically assign that access to identities meeting defined organizational criteria.

Study Guide Reference: Access Management — Roles, Role Assignment Criteria, Standard Criteria, Identity Lists.

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

1. Section of the UI that allows users to ask for access.

Select a match:

Answer: Request Center

2. Provide an interface to read user account data and provision changes from Identity Security Cloud to target systems and applications.

Select a match:

Answer: Direct Connection

3. A ticket is created in ServiceNow and assigned to the operations team that manages the source application.

Select a match:

Answer: Service Desk Integration

4. A task is created and assigned to a source owner to provision the users' access being requested.

Select a match:

Answer: Manual work Item

Request Center is the end-user interface through which users browse and request configured roles, access profiles, and entitlements. Direct Connection represents the connection model through which Identity Security Cloud communicates with a managed source and, when provisioning is supported and enabled, performs changes directly rather than requiring manual intervention. SailPoint distinguishes directly connected sources from flat-file/manual provisioning sources.

Service Desk Integration is appropriate when fulfillment is delegated to an external service-management platform such as ServiceNow. The resulting ticket is routed to the operational team responsible for implementing the requested change. Manual work Item applies when Identity Security Cloud cannot automatically provision the requested change; instead, a provisioning task is assigned to the responsible source or entitlement owner for completion outside the automated connector path. SailPoint explicitly documents manual provisioning tasks for sources that cannot be automatically written to.

Study Guide Reference: Provisioning — Provisioning Methods, Direct Connections, Manual Provisioning, Service Desk Integration and Request Center.

The statement is valid for identities whose role assignment is actively enforcing the role's access. Identity Security Cloud roles represent collections of access that can include entitlements and access profiles. When role access is expanded, the role's existing members are expected to receive the additional required access so their actual source access continues to satisfy the role definition.

Role configuration changes are not necessarily applied to every identity immediately at the moment the administrator saves the role. SailPoint states that access additions are handled by identity processing . Administrators can select Apply Changes on the Roles page to initiate processing across identities, or the change can be applied when relevant identity processing subsequently occurs. During that processing, the system recalculates the role-based access requirements and provisions new access to applicable source accounts.

This behavior is important to understand operationally: editing a role changes its access model, and Identity Security Cloud must then propagate those additions to identities holding the role.

Study Guide Reference: Access Management — Roles, Managing Role Access, Role Change Processing and Automated Provisioning.

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

This is not the primary purpose of an Identity Profile. In Identity Security Cloud, an Identity Profile establishes how identities are created and governed from an authoritative source . It determines the authoritative source associated with a population, maps source account attributes into identity attributes, defines authentication and security settings, and configures lifecycle-state behavior. SailPoint states that configuring an Identity Profile makes the associated source authoritative and creates identities from accounts on that source.

Assigning permissions based on business roles belongs instead to the access model . Roles can bundle access profiles and associated entitlements and can be automatically assigned to identities by Standard Criteria or by explicitly selecting identities through an Identity List.

An Identity Profile may indirectly affect access through lifecycle-state provisioning, but this is materially different from assigning specific permissions based on roles. Consequently, the proposed statement confuses identity population and lifecycle configuration with role-based access assignment.

Study Guide Reference: Identity and Lifecycle Management — Identity Profiles, Authoritative Sources, Identity Attribute Mapping and Lifecycle Configuration.

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

Yes. This is a classic Separation of Duties scenario. The individual requesting a significant system configuration change should not also possess the authority to independently approve that same change. Combining requester and approver responsibilities eliminates an important independent-control checkpoint and allows one person to initiate and authorize a potentially high-impact administrative operation.

SailPoint's official SoD guidance specifically uses major system configuration changes as an example: significant configuration changes should be approved by someone other than the person requesting the change. SoD policies are designed to identify and govern combinations of access that would enable such conflicting responsibilities.

From a governance perspective, the requester initiates the business or technical need, while an independent reviewer determines whether the requested change is appropriate, authorized, and sufficiently controlled. Separating these functions reduces fraud, accidental misconfiguration, privilege abuse, and unauthorized system modification. Where conflicting access already exists, Identity Security Cloud can identify the associated SoD violation for investigation and remediation.

Therefore, allowing the requester to approve their own major system change represents exactly the type of control conflict that SoD is intended to prevent.

Study Guide Reference: Supporting Governance — Separation of Duties, Requester/Approver Conflicts, Internal Controls and SoD Policy Enforcement.

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

The statement is correct. Identity Security Cloud normally uses optimized aggregation , which retrieves records from the source but can skip further processing for an account when the account already exists and no relevant data changes are detected. In that situation, account correlation and manager correlation do not need to be recalculated for unchanged accounts.

Disabling aggregation optimization causes an unoptimized aggregation . SailPoint explicitly states that this mode reprocesses every record regardless of whether the underlying account data has changed. It also reevaluates account-correlation and manager-correlation logic for those accounts.

This is particularly important after changing account-correlation configuration. If an account's attributes have not changed, an optimized aggregation might otherwise skip the account, leaving it uncorrelated despite the newly corrected correlation rules. SailPoint therefore recommends running an aggregation with optimization disabled when correlation logic has been modified on an already-aggregated source.

Unoptimized processing requires more resources and can take longer on large sources, so it should be used deliberately when full reevaluation is necessary rather than as the default aggregation mode.

Study Guide Reference: Sources — Account Aggregation, Optimized and Unoptimized Aggregations, Account Correlation.

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

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.

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

The statement correctly describes the standard escalation behavior represented by the access-request escalation model. Identity Security Cloud can automatically escalate an approval when the assigned reviewer fails to act within the configured timeframe. This prevents an access request from remaining indefinitely with an unavailable or unresponsive approver.

Under the standard escalation pattern, the first and second escalations can route the request to successive manager levels of the assigned reviewer. The third escalation routes the approval to the configured fallback approver. Administrators control escalation timing, frequency, escalation reviewers, and fallback behavior through approval settings. This mechanism operates alongside reminder notifications and request timeout controls.

The fallback approver is particularly important because it provides a final governance path when ordinary escalation cannot resolve the request. SailPoint's current documentation explicitly describes the first two manager escalations followed by a third escalation to the fallback approver when custom approval settings are not configured.

Study Guide Reference: Access Management — Access Requests, Global Reminder and Escalation Policy, Approval Escalation and Fallback Approvers.

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

The statement is correct. Identity Security Cloud workflows consist of triggers, actions, operators, and control-flow relationships. Each workflow action requires a name that uniquely identifies the step within that workflow. The name is operationally significant because subsequent steps and conditional logic reference workflow actions by their names.

SailPoint specifically documents that every workflow action has a name and that the action name must be unique within the workflow so it can be referenced correctly in next-step definitions and conditional logic. The workflow builder can automatically generate the initial name based on the action type, but administrators can rename steps where clearer naming improves workflow readability.

If two workflow actions shared the same underlying step name, references could become ambiguous and workflow execution could not reliably determine which action's output or transition was intended. This is particularly important because action output becomes part of the workflow data flow and can be referenced by later steps.

Therefore, uniqueness is a functional requirement rather than merely a user-interface naming preference.

Study Guide Reference: Platform — Workflows, Workflow Actions, Step Names, Data Flow and Conditional Logic.

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

This is a correct troubleshooting step. Enabling Entitlement Requests globally makes entitlement requesting available to the organization, but it does not automatically make every aggregated entitlement available in the Request Center. Individual entitlements must also be marked as requestable.

SailPoint specifically supports managing this setting from the source. An administrator can navigate to Admin > Connections > Sources , select the source, open Entitlement Management > Entitlements , locate the required entitlement, and verify whether it is marked as requestable. The entitlement can then be updated through the applicable Actions menu. SailPoint also exposes requestable status centrally from the Access Model > Entitlements page.

Because the missing access corresponds to recently added directory groups, the administrator should also ensure that an entitlement aggregation has successfully loaded the groups into Identity Security Cloud. If the group exists but is not requestable, users will not receive the expected direct entitlement-request experience.

Therefore, checking the entitlement's Requestable status is a technically appropriate diagnostic action.

Study Guide Reference: Sources — Entitlement Management, Entitlement Aggregation, Requestable Entitlements and Access Request Configuration.

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

The statement is incorrect. Identity Profiles remain administratively manageable after identities have been created from their associated authoritative sources. Administrators can edit supported Identity Profile properties, including identity attribute mappings, lifecycle-related configuration, ownership information, and other profile settings. When a change affects identity data, Identity Security Cloud marks the profile as requiring processing, and the administrator can use Apply Changes to recalculate affected identities.

Identity Profiles can also be managed programmatically. SailPoint exposes APIs for updating and deleting Identity Profiles. Some fields have restrictions—for example, system-generated properties cannot be modified, and changes to authoritative-source configuration and identity-attribute configuration have specific processing constraints—but the existence of identities under the profile does not make the profile permanently immutable. The V3 API explicitly provides both update and delete Identity Profile operations.

Because at least the assertion that administrators cannot modify an Identity Profile after identities are assigned is demonstrably false, the overall proposed statement is false.

Study Guide Reference: Identity and Lifecycle Management — Identity Profiles, Editing Identity Profiles, Processing Identity Changes and Identity Profile Administration.

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

The statement correctly describes Identity Security Cloud's default self-approval prevention behavior when the requester is assigned as an individual reviewer . SailPoint does not normally permit a person to approve their own access request. This applies whether the request is submitted directly for themselves or whether the affected access recipient otherwise appears as a reviewer in the approval sequence.

When the requester or recipient is assigned an approval directly as an individual, Identity Security Cloud automatically reassigns that review responsibility to the individual's manager . If a valid manager is unavailable, the system can continue through alternative fallback mechanisms, eventually reaching an administrator when necessary.

There is an important distinction for Governance Groups: if the requester belongs to a Governance Group configured as reviewer, the requester is normally omitted while other group members remain eligible to approve. Only when that user is effectively the group's sole valid reviewer does manager reassignment occur.

An optional API setting can permit auto-approval for individual reviewers, but the default behavior described by the scenario is manager reassignment.

Study Guide Reference: Access Management — Preventing Self-Approval, Approval Reassignment, Manager Review and Access Request Governance.

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

The statement does not describe the purpose of a SailPoint Virtual Appliance. A VA is primarily a secure connectivity and connector-execution component . It allows an Identity Security Cloud tenant to communicate with enterprise sources and applications that require connectivity from within the customer's controlled environment.

SailPoint describes a VA as a Linux-based virtual machine that connects the tenant to applications and sources by using SailPoint APIs, connectors, and integrations. The VA continuously makes outbound calls to the SailPoint cloud for operations such as polling its cluster queue, performing data aggregation, executing provisioning operations, and receiving software updates.

The VA architecture does reduce the need to expose internal systems directly to inbound cloud connections, but that is fundamentally different from eliminating databases that contain PII. Enterprise applications, identity repositories, HR systems, directories, and other governed sources may continue to store personally identifiable information according to their own business and regulatory requirements.

Therefore, PII database elimination is neither the VA's purpose nor a consequence of deploying one.

Study Guide Reference: Virtual Appliances — VA Architecture, Secure Source Connectivity, Outbound Communication and Connector Execution.

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

This is a valid troubleshooting action. Identity Security Cloud depends on the source's entitlement schema to understand what entitlement objects and attributes should be collected. If the schema or entitlement-type configuration is incorrect, a newly created entitlement might not be recognized correctly during aggregation.

In the current Identity Security Cloud interface, this functionality is represented under Entitlement Management > Entitlement Types and Schemas . Each entitlement type has a schema that defines attributes such as its identifier, name, display name, description, and other source-specific properties. The account schema also identifies which account attributes represent entitlements. Consequently, schema configuration directly affects how source entitlement information is interpreted and linked to accounts.

Administrators should therefore confirm that the expected entitlement type exists, verify that its entitlement ID and entitlement-name attributes are mapped correctly, and then perform an entitlement aggregation. SailPoint specifically recommends examining and correcting entitlement schema mappings when entitlement information is not being aggregated correctly.

Study Guide Reference: Sources — Entitlement Types and Schemas, Entitlement Aggregation, Source Entitlement Configuration.

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

This statement correctly describes the purpose of Separation of Duties (SoD) policies. In identity governance, a toxic combination is a set of access privileges that becomes excessively risky when possessed by the same identity. A typical example would be combining permission to create a supplier with permission to approve payments to that supplier. Either permission may be legitimate independently, while the combined privileges create an unacceptable control conflict.

Identity Security Cloud implements SoD by allowing administrators to construct policies containing conflicting sets of access. Human identities possessing access from both sides of the defined conflict can generate policy violations that administrators and designated violation owners can investigate, remediate, or mitigate. SailPoint describes SoD as an internal control that provides visibility into risky access combinations and helps organizations identify where policy violations exist.

Therefore, SoD policies are specifically designed to identify and govern the toxic combinations of privileges described in the statement.

Study Guide Reference: Supporting Governance — Separation of Duties, Conflicting Access, Toxic Combinations and SoD Policy Violations.

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

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 is valid. In Identity Security Cloud, entitlements represent individual access rights or permissions that exist on connected sources. The specific form of an entitlement depends on the target system. Examples can include Active Directory groups, application roles, permission sets, security groups, database privileges, or other source-specific access constructs.

Entitlements form a fundamental layer of SailPoint's access model. Administrators can combine one or more entitlements from the same source into an access profile. Access profiles can then be incorporated into roles to create higher-level business access models.

Because SailPoint aggregates entitlement information from connected sources, administrators can govern these access rights through certifications, access requests, provisioning processes, role management, and policy analysis. Entitlement metadata can also provide meaningful descriptions and ownership information so reviewers understand the access being governed.

Therefore, describing entitlements as specific access rights on a source precisely reflects their role in Identity Security Cloud's access governance architecture.

Study Guide Reference: Access Management — Entitlements, Access Profiles, Roles and Access Model Fundamentals.

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

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.

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

The statement is not valid in the normal Identity Security Cloud identity model. An authoritative source is specifically used to establish identities. When a source is associated with an identity profile and thereby designated as authoritative, Identity Security Cloud creates an identity from each qualifying authoritative account. The authoritative account therefore forms the identity's authoritative foundation rather than behaving as an ordinary account that must subsequently be correlated to an existing identity.

Uncorrelated accounts normally arise from non-authoritative or secondary sources when Identity Security Cloud cannot match an aggregated account to an existing authoritative identity by using configured correlation criteria. SailPoint defines an uncorrelated account as an account that has not been linked to an authoritative identity. Such accounts must be resolved before their associated access can be properly governed.

Although unusual administrative edge cases can affect existing authoritative-account associations, this does not change the fundamental certification concept: authoritative accounts establish identities, while correlation attaches accounts from other sources to those identities.

Study Guide Reference: Identity and Lifecycle Management — Authoritative Sources, Identity Profiles, Account Correlation and Uncorrelated Accounts.

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

The statement is incorrect. A role does not have to be requestable in Identity Security Cloud. Requestability is an optional capability used when organizations want users to obtain a role through the Request Center.

Roles can instead be assigned automatically according to Standard Criteria or an Identity List. When an identity satisfies automated assignment conditions, the role and associated access can be granted through identity processing without the user submitting an access request.

SailPoint specifically states that organizations can allow users to request roles when the role cannot easily be auto-assigned or when someone who does not meet its ordinary assignment criteria might legitimately require the access. To enable this behavior, an administrator edits the role's Access Requests configuration and turns on Allow Access Requests . The presence of an enable/disable setting itself demonstrates that requestability is optional rather than mandatory.

A role can therefore exist purely as automatically assigned business access, purely as requestable access where appropriate, or be configured according to the organization's access-governance design.

Study Guide Reference: Access Management — Roles, Access Requests, Requestable Roles and Automated Role Assignment.

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

This statement accurately describes core Identity Governance and Administration capabilities. Effective IGA provides centralized visibility into identities, accounts, entitlements, roles, applications, and the relationships between identities and their access. This allows security and governance teams to determine who has access, how that access was obtained, whether it remains appropriate, and where excessive or conflicting privileges exist.

IGA also provides policy-driven control. Organizations can implement lifecycle-based provisioning and deprovisioning, access-request approvals, role-based access, periodic certification campaigns, privileged-access governance, and Separation of Duties policies. These mechanisms enable organizations to enforce least privilege while maintaining an auditable record of access-related decisions.

SailPoint describes IGA as providing visibility and oversight of user access across systems and applications while strengthening security through policy-based controls, access reviews, provisioning automation, and SoD. SailPoint also describes its identity-security capabilities as providing detailed visibility into identities, access privileges, and policies throughout an organization.

Therefore, access visibility combined with policy-based governance is a defining IGA capability.

Study Guide Reference: General knowledge for Identity Security Administrators — IGA Fundamentals, Access Visibility, Governance Policies, Least Privilege and Access Controls.

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

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.

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

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.

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

The statement correctly describes the communication model used by SailPoint Virtual Appliances. The critical architectural principle is that communication between a customer-hosted VA and Identity Security Cloud is initiated outbound from the VA . SailPoint does not establish unsolicited inbound connections from its cloud environment directly into the customer's VA.

SailPoint specifically documents that each VA makes continuous outbound-only calls to the cloud environment and polls the cluster queue for requested actions , including aggregation and provisioning work. The appliance retrieves the work assigned to its cluster, executes the appropriate connector operation against the customer source, and communicates the resulting information back to Identity Security Cloud.

This polling model is significant from a network-security perspective because customers do not need to create inbound firewall rules allowing Identity Security Cloud to initiate sessions into their internal environment. Instead, the VA requires appropriate outbound connectivity to SailPoint's required endpoints.

Therefore, describing VAs as initiating communication to their cluster queue accurately reflects the supported VA architecture.

Study Guide Reference: Virtual Appliances — VA Cluster Architecture, Cluster Queue Polling, Outbound-Only Communication and Connector Operations.

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

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 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.

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

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.

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

This is an essential and valid troubleshooting step. Lifecycle-state provisioning is triggered according to the lifecycle state calculated for an identity. If Identity Security Cloud does not actually consider the affected user to be in the Terminated state, the account-disable operations configured for that lifecycle state will not be initiated.

The administrator should therefore inspect the identity and confirm that its Lifecycle State value resolves to Terminated. If it does not, the next investigation should focus on the identity profile's lifecycle-state configuration, authoritative source attribute mapping, transforms or rules used to calculate lifecycle state, and whether the identity has been properly reprocessed after the source data changed.

Once an identity enters the configured lifecycle state, Identity Security Cloud can apply account actions defined under Settings for Previous Accounts , including disabling accounts across all sources or specified sources. SailPoint specifically uses Terminated and Archived states as examples where access removal and account disablement are commonly configured.

Consequently, validating the identity's actual lifecycle-state value is one of the first diagnostic checks that should be performed before investigating downstream connector or provisioning failures.

Study Guide Reference: Identity and Lifecycle Management — Lifecycle States, Terminated Identities, Lifecycle Attribute Calculation and Account Actions.

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

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.