Free Practice Questions for SailPoint Identity-Security-Administrator Exam

This is a valid integration approach. Identity Security Cloud does not require every authoritative source to correspond to a purpose-built SaaS connector. For custom or legacy systems, generic integration mechanisms can expose the authoritative account or personnel information needed to construct identities.

A Delimited File source can load account information exported from a system into Identity Security Cloud. SailPoint describes the Delimited File connector as a general-purpose mechanism that reads account data from files and supports customizable account schemas. A database-backed custom HR application can instead be integrated through an appropriate JDBC/database connector when its personnel information is accessible through relational tables.

After creating the source, an Identity Profile can be associated with it to make that source authoritative. SailPoint states that when a source is configured as authoritative through an Identity Profile, an Identity Security Cloud identity is created for each applicable authoritative account.

The administrator must still design a reliable schema, uniquely identify contractors, configure required identity attributes, and determine suitable correlation and lifecycle mappings. Nevertheless, Delimited File and JDBC-style integrations are legitimate approaches for legacy authoritative data.

Study Guide Reference: Sources — Authoritative Sources, Generic Connectors, Delimited File Integration, JDBC Integration and Identity Profiles.

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

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.

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

The statement is incorrect. A source in Identity Security Cloud is not primarily a backup-storage repository. A source represents an enterprise system from which Identity Security Cloud obtains account, identity, and access information or to which it performs supported provisioning operations.

SailPoint defines a source as the Identity Security Cloud representation of a third-party enterprise application, database, or directory-management system that maintains its own accounts or personnel records. Connectors are used to interact with those systems so Identity Security Cloud can aggregate accounts and access rights and associate that information with identities.

Examples include Active Directory, HR applications, databases, SaaS platforms, and flat-file feeds. Depending on connector capabilities and configuration, a source can support account aggregation, entitlement aggregation, account creation and modification, enable/disable operations, password management, and entitlement provisioning.

Backup and disaster-recovery functions are separate concerns. Configuration Hub, for example, backs up supported Identity Security Cloud configuration objects , but that does not redefine enterprise sources as backup systems.

Study Guide Reference: Sources — Source Definitions, Connectors, Account and Entitlement Aggregation, Source Management.

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

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.

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 Virtual Appliance is primarily a secure connectivity and connector-execution component that enables Identity Security Cloud to communicate with sources located inside an organization's private network or otherwise inaccessible directly from the SailPoint cloud environment.

During aggregation, the VA can communicate with the source and transmit relevant account, identity, group, and entitlement information to Identity Security Cloud. However, the Virtual Appliance is not intended to function as the persistent entitlement repository or search-indexing database.

Entitlement information used for access modeling, certifications, governance, search, roles, access profiles, and policy analysis is managed within the Identity Security Cloud platform. The VA facilitates source communication and executes connector-related operations such as aggregation and provisioning when required.

This architectural distinction is important because Virtual Appliances should not be treated as local databases containing governance data. Their primary responsibilities are secure connectivity, execution of integration workloads, and communication between SailPoint's cloud services and enterprise-managed systems.

Study Guide Reference: Virtual Appliances — VA Architecture, Source Connectivity, Aggregation and Provisioning Operations.

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

This can be a valid reason, depending on the manager-review campaign mechanism being used. In a search-based certification campaign where Manager is selected as the reviewer, Identity Security Cloud determines the reviewer from each identity's manager relationship. If an identity does not have a manager defined, SailPoint documents that the certification is reassigned to the creator of the campaign . If the campaign creator is an administrator, the certification therefore appears assigned to that administrator instead of a manager.

The absence of a manager can originate from authoritative HR data, an incomplete manager attribute mapping, failed manager correlation, or otherwise missing manager information on the identity.

A distinction is important: traditional Manager Campaigns require identities to have managers defined and identities without managers are normally excluded. SailPoint recommends using a Search-based campaign with Manager selected as reviewer when identities without managers must still be included.

Given the scenario explicitly states that the certification was reassigned to an admin, missing manager information is therefore a technically valid explanation for the observed fallback assignment.

Study Guide Reference: Supporting Governance — Certifications, Manager Review, Search-Based Campaigns and Identities Without Managers.

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

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.

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

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 is a valid network-isolation troubleshooting step. Virtual Appliances depend on continuous outbound network connectivity to Identity Security Cloud. A VPN, firewall, proxy, routing policy, or network-security device positioned in the communication path can prevent the VA from reaching required SailPoint endpoints even when the VA itself is otherwise healthy.

Testing connectivity with and without the VPN helps determine whether the VPN path, its routing tables, security policies, DNS handling, or tunnel configuration is responsible for the failure. SailPoint requires VA outbound connectivity, including HTTPS communication over TCP port 443, and documents network connectivity as a primary dependency for proper VA operation. Network connectivity errors should therefore be investigated by validating the path between the appliance and required endpoints.

This does not mean permanently bypassing required enterprise security controls. The objective is diagnostic isolation: establish whether connectivity succeeds when the suspected network component is removed from the path, then correct the underlying VPN or routing configuration.

Study Guide Reference: Virtual Appliances — VA Network Troubleshooting, Outbound Connectivity, VPN and Firewall Configuration.

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