Free Practice Questions for SailPoint Identity-Security-Administrator Exam

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.

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

This is a valid troubleshooting action. Identity Security Cloud provides administrators with centralized visibility into pending access requests through Approval Management / Approvals Administration . An administrator can select an access request and inspect its processing details rather than relying only on the status visible to the requester.

The request's Process view displays the progression of the approval and provisioning workflow. It identifies completed, active, and future steps and can show which approver or governance group currently owns an outstanding review. Where multiple reviewers are involved, administrators can expand approval stages to inspect individual reviewer status. The Assignees information also identifies who is currently responsible for approving the request.

This makes the administrative view particularly useful when a request appears "stuck." The administrator can determine whether it is waiting for approval, escalation, provisioning, or another processing stage and then take an appropriate supported action such as reminding or reassigning an approver.

Therefore, reviewing the request's administrative process flow is an appropriate first-line diagnostic step.

Study Guide Reference: Access Management — Approvals Administration, Tracking Access Requests, Approval Workflow and Pending Request Troubleshooting.

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

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

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

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

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

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

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

The statement is incorrect because it confuses the responsibilities of an Identity Provider with those of a Service Provider. In a federated authentication architecture, the Identity Provider, commonly called the IdP, is responsible for authenticating the user and issuing trusted identity or authentication information.

The Service Provider is the system, application, or service that the user is attempting to access. It relies on the authentication assertion provided by the IdP and determines whether the authenticated user can access the requested resource.

For example, when Identity Security Cloud is configured to use SAML federation, an external IdP can authenticate the user. The IdP then sends a signed SAML assertion to Identity Security Cloud. Identity Security Cloud acts as the Service Provider and provides the application functionality after accepting the trusted authentication information.

Therefore, the component that offers the application or service is generally the Service Provider, not the Identity Provider. The IdP establishes identity and provides authentication assertions.

Study Guide Reference: Access Management — Federated Authentication, Identity Providers, Service Providers, SAML Authentication.

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

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.

1. An IT company grants system administrators elevated permissions to manage critical servers and network configurations. These administrators use unique, secure credentials and multi-factor authentication to access sensitive systems, ensuring that only qualified personnel can perform high-risk tasks.

Select a match:

Answer: Privileged Access

2. A payroll administrator at a financial services company is responsible for processing employee salaries. Due to staffing shortages, they are also given approval access for salary disbursements, meaning they can both enter and approve payroll transactions.

Select a match:

Answer: Separation of Duties (SOD)

3. A customer support agent in a healthcare company accesses a patient's full medical history and Social Security number to verify their identity for a simple billing inquiry.

Select a match:

Answer: Personally Identifiable Information (PII)

The first scenario represents Privileged Access because system administrators hold elevated permissions that allow them to perform sensitive, high-impact operations on critical infrastructure. SailPoint identifies privileged entitlements as access that can expose sensitive data or create elevated security risk, making stronger controls such as MFA and dedicated credentials appropriate.

The second scenario represents Separation of Duties (SOD) . Allowing the same payroll administrator both to enter payroll transactions and approve salary disbursements creates conflicting responsibilities. SailPoint's SoD model specifically exists to prevent one identity from possessing combinations of access that allow them to initiate and independently authorize sensitive business transactions.

The third scenario involves Personally Identifiable Information (PII) because medical information combined with a Social Security number directly exposes sensitive information associated with an identifiable individual.

Study Guide Reference: Supporting Governance — Separation of Duties, Privileged Access, Sensitive Data and Identity Governance Controls.

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

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

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

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

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

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

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

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

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

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

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