Is the following statement true about the characteristics of different connector types in Identity Security Cloud (ISC)?
Proposed Solution / Statement: Active Directory (AD) connectors can handle both authentication and identity lifecycle management, including user provisioning.
Does this proposed solution meet the requirement / solve the scenario?
Answer : A
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.
===============
Is this a valid statement about Identity Security Cloud sign-in methods?
Proposed Solution / Statement: When Directory Connection is enabled, the credentials are read from an encrypted file in a directory (folder).
Does this proposed solution meet the requirement / solve the scenario?
Answer : B
No. The term Directory Connection does not mean that Identity Security Cloud reads authentication credentials from an encrypted file stored in a filesystem directory. Directory Connection is SailPoint's pass-through authentication mechanism. For an identity profile configured with this sign-in method, administrators select an aggregated authentication source that corresponds to the identities in that profile. Users then authenticate by using the network password associated with their account on that source.
During authentication, Identity Security Cloud relies on the configured external directory source to validate the user's credentials. This is particularly common with enterprise directory systems such as Active Directory. The mechanism therefore enables users to use their organizational network credentials rather than maintaining an independent Identity Security Cloud password.
A prerequisite is that the authentication source and relevant accounts have been aggregated. An identity must also have an appropriately correlated account on the configured authentication source; otherwise authentication-source mismatch errors can occur.
No encrypted credential file in a local folder forms part of the documented Directory Connection authentication architecture.
Study Guide Reference: Access Management --- Sign-In Methods, Directory Connection, Pass-Through Authentication and Authentication Sources.
Is this a valid statement regarding access request approval processes?
Proposed Solution / Statement: In a governance group approval process, the majority of the members must approve before the access is granted to the requester.
Does this proposed solution meet the requirement / solve the scenario?
Answer : B
The statement is incorrect. Identity Security Cloud does not use majority voting within a Governance Group for an access-request approval step. When a Governance Group is configured as a reviewer, only one eligible member of that Governance Group is required to approve or deny the request on behalf of the group.
SailPoint explains that when an access request reaches a Governance Group, its members receive the applicable review assignment. Once one member makes the decision, the review is treated as completed for that Governance Group and disappears from the other members' pending approval lists.
This should not be confused with a multi-step approval process containing several separate reviewers. If the access item is configured with multiple required reviewer stages, each required stage must approve before provisioning occurs. However, a Governance Group itself represents one reviewer stage, and that stage does not require approval from 50%, a majority, or every member.
Therefore, requiring a majority of Governance Group members is not how standard Identity Security Cloud Governance Group approvals operate.
Study Guide Reference: Access Management --- Governance Group Approvals, Access Requests, Multi-Approver Processes and Group Review Decisions.
===============
On 4 February 2021, the following error occurred on source Control Central of type Active Directory for identity Clarence.Harper:
Failed to update attributes. There is no such object on the server.
Is this a valid place to look for more information about what caused the error?
Proposed Solution / Statement: In Identity Security Cloud go to search and query for:
type:event AND subtype:provision AND error:TRUE AND date:>=2021-2-4 AND identity:Clarence.Harper
Open the relevant result for more details.
Does this proposed solution meet the requirement / solve the scenario?
Answer : A
This is an appropriate diagnostic method within the Search model represented by the course scenario. The query narrows the investigation to events associated with provisioning, filters for events containing errors, constrains the timeframe to the date on which the failure occurred, and associates the result with the affected identity, Clarence.Harper. Opening the corresponding event allows the administrator to investigate the contextual information associated with the failed provisioning operation.
The underlying troubleshooting principle remains central to Identity Security Cloud administration: provisioning failures should be correlated with audit events and account activity rather than evaluated only from the short error message shown in a dashboard. SailPoint Search contains audit-event information and supports filtering against event data. Event records can provide operation details, status, target information, source context, and additional attributes. SailPoint also provides a Provisioning Activity audit-report capability specifically for reviewing provisioning events.
Study Guide Reference: Provisioning --- Monitoring Provisioning, Search and Audit Events, Troubleshooting Failed Provisioning Operations.
===============
Is the following statement regarding attribute sync valid?
Proposed Solution / Statement: Attribute sync synchronizes entitlement information from the sources configured.
Does this proposed solution meet the requirement / solve the scenario?
Answer : B
The statement is incorrect because Attribute Sync does not synchronize entitlement information from a source into Identity Security Cloud. Its purpose is to keep selected source account attributes synchronized with corresponding identity attributes maintained in Identity Security Cloud.
For example, an organization's authoritative identity data might contain a user's department, title, or other business attribute. If a corresponding account attribute on a connected target source is configured for Attribute Sync, Identity Security Cloud can detect that the account value no longer matches the identity value and provision an update to the source account. SailPoint explicitly states that Attribute Sync uses identity information to keep account data on sources consistent with identity data.
Entitlements are handled through separate aggregation mechanisms. Entitlement aggregation imports entitlement objects and their metadata from external sources into Identity Security Cloud.
Therefore, the proposed statement confuses two distinct processes: Attribute Sync pushes identity-derived account-attribute changes toward target accounts, whereas entitlement aggregation loads entitlement information from governed sources.
Study Guide Reference: Provisioning --- Attribute Synchronization, Identity-to-Account Attribute Mapping and Entitlement Aggregation.
===============
Does this statement accurately describe the purpose of the Virtual Appliance (VA)?
Proposed Solution / Statement: The VA allows the tenant to connect to on-prem sources.
Does this proposed solution meet the requirement / solve the scenario?
Answer : A
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.
===============
Is this a valid statement about identity profile?
Proposed Solution / Statement: The priority of an identity profile can be updated via REST API.
Does this proposed solution meet the requirement / solve the scenario?
Answer : A
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.
===============