Practice Free Identity-Security-Administrator SailPoint Certified Identity Security Administrator Exam Questions Answers With Explanation

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.

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

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.

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

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.

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

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 statement is correct. An uncorrelated account is a source account that Identity Security Cloud has been unable to associate with an existing identity by using the configured account-correlation criteria. SailPoint provides a supported manual-correlation process for resolving these accounts.

From the source's Uncorrelated Accounts area, an administrator can select Download Correlation File to obtain a CSV containing the uncorrelated accounts. The administrator then adds the appropriate identity Account IDs to the designated userName column beside each account that needs to be correlated. After saving the modified CSV, it can be uploaded back through the Uncorrelated Accounts page. Identity Security Cloud processes the file and creates permanent manual associations between the specified source accounts and identities.

Manual correlation differs from ordinary correlation rules because a manually correlated account remains attached to that identity even if source attributes later change. To associate it with another identity, the manual correlation must first be removed or explicitly changed.

Therefore, the download-edit-upload procedure described in the proposed statement is an officially supported method.

Study Guide Reference: Identity and Lifecycle Management — Account Correlation, Uncorrelated Accounts, Manual Correlation and Identity Assignment.

The statement is correct. Attribute synchronization is configured at the source level because administrators must determine which account attributes on a specific governed source should remain synchronized with corresponding Identity Security Cloud identity attributes.

SailPoint's documented configuration path begins by navigating to Admin > Connections > Sources and selecting or editing the appropriate source. Within the source's Account Management section, the administrator opens Attribute Sync . Identity Security Cloud then displays the account attributes that are eligible for synchronization based on the source's Create Account definition and identity-attribute mappings. The administrator selects the attributes that should synchronize and can initiate the appropriate synchronization process.

Attribute Sync applies to existing correlated accounts. It does not independently create accounts, and an uncorrelated account cannot participate because Identity Security Cloud has no authoritative identity relationship from which to determine the target attribute values.

Therefore, accessing the source through Admin > Connections > Sources and configuring Attribute Sync from its account-management configuration is precisely the supported administrative approach.

Study Guide Reference: Provisioning — Configuring Attribute Sync, Source Account Management, Identity Attribute Mapping and Correlated Accounts.

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

No. The statement is too restrictive and misunderstands SailPoint's Search data models. The nested object @entitlements(...) is available in contexts where the searched object can contain multiple entitlements. Access profiles are one such category, but they are not the only applicable category. SailPoint's searchable-field documentation also defines entitlement nested fields for roles. Therefore, @entitlements(name:Manager_Access) cannot be characterized as inherently returning only access profiles associated with that entitlement.

The search category matters. Identity Search uses the @access(...) nested object to identify the access held by identities. For example, an identity holding a Manager_Access entitlement can be searched through an appropriate @access(...) expression. Conversely, when querying access-profile or role records, @entitlements(...) can filter those objects according to entitlements contained within them.

The original query is consequently invalid as a coherent identity query because it combines identity-oriented fields and @access(...) expressions with an entitlement-container nested construct belonging to different searchable object models.

Study Guide Reference: Platform — Searchable Fields, Nested Objects, Identity Search, Access Profiles and Role Search Models.

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

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

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

The statement is false. Removing an account record from Identity Security Cloud does not necessarily permanently prevent the account from being discovered again. The decisive factor is whether the account still exists on the underlying source system.

SailPoint explicitly documents that when an administrator selects Remove Account for an account in Identity Security Cloud, the account is removed from the tenant's current source data, but it will be re-aggregated during the next complete source aggregation unless it is also removed from the source itself .

The same architectural principle applies to aggregation-driven account state. Identity Security Cloud's source data is a governed representation of accounts that actually exist on connected systems. A future full aggregation can rediscover a source account and recreate its representation in the tenant if that source account continues to exist and is returned by the connector.

To permanently eliminate the account from subsequent aggregation, it must be appropriately deleted or otherwise excluded on the actual source, subject to the organization's provisioning and governance policy.

Study Guide Reference: Sources — Account Aggregation, Removing Accounts, Complete Aggregations and Source Account Lifecycle.

This is not the correct remediation mechanism for the certificate-path error described. Active Directory source configuration allows administrators to enable Transport Layer Security (TLS) for supported connections, but the source's TLS configuration is not simply a certificate-upload repository used to resolve a Java PKIX trust failure.

The underlying problem is that the Virtual Appliance performing the TLS connection cannot validate the certificate chain presented by Active Directory. Trust must therefore exist in the VA's applicable certificate trust location. SailPoint documentation states that when TLS is enabled for a supported source, the applicable certificate should normally be copied automatically to the associated VA cluster. Where manual remediation is required, certificate trust is handled at the VA level rather than by arbitrarily uploading an AD certificate to a source TLS settings page.

Administrators should verify the server certificate, issuing CA chain, hostname correspondence, and the trusted certificates available to the VA. Changing source settings without resolving VA trust will leave the TLS handshake failure unresolved.

Study Guide Reference: Virtual Appliances — TLS Configuration on VAs, Certificate Trust, Active Directory TLS Troubleshooting.

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

This statement is incorrect. When a role uses Identity List as its assignment type, Identity Security Cloud expects administrators to explicitly search for and select individual identities that should receive the role. SailPoint's documented procedure is to select Identity List, search for a specific identity in Add Identities , add that identity, and repeat the process for additional identities. Identity List therefore functions as an explicit membership list rather than a pattern-based membership rule.

Wildcards such as * and ? are valid in Identity Security Cloud Search queries for supported text fields. For example, Search can use patterns to find records whose names match a particular character sequence. However, that Search capability must not be confused with role Identity List assignment criteria.

If dynamic membership is required, administrators should use Standard Criteria , where identity attributes, account attributes, or entitlements can be evaluated through supported comparison operators. Identity List is appropriate when named identities are deliberately selected.

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

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

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.

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

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.

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

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.

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

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.

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

This is a valid troubleshooting action because the error explicitly identifies an invalid email-address value during provisioning. When Identity Security Cloud creates an account on a source, the Create Account configuration determines which account attributes are populated and how their values are calculated.

SailPoint allows each Create Account attribute to derive its value from an identity attribute, generator, static value, or other supported provisioning configuration. For example, the source's email account attribute can be mapped directly to the identity's Work Email value. If that mapping references the wrong identity attribute, produces an incorrectly formatted value, or uses a defective generator or transformation, the target source can reject the provisioning operation.

The administrator should therefore inspect Admin > Connections > Sources > Account Management > Create Account , locate the email-related source attribute, validate its mapping, and inspect the affected identity's source value. The conflicting-action portion of the error should also be reviewed in Account Activity, but the explicit email validation failure makes the account-creation mapping a direct troubleshooting target.

Study Guide Reference: Provisioning — Create Account Configuration, Account Attribute Mappings, Provisioning Validation and Provisioning Troubleshooting.

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.

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

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.

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

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

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

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

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

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

The statement is 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.

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