Free IDENTITYIQ-ASSOCIATE Practice Test Questions and Answers (2026)

This statement is false because of the restrictive term "only." While Lifecycle Events are most commonly triggered by data changes from authoritative applications during aggregation, this is not the exclusive method. Triggers can also be configured to respond to changes from non-authoritative sources, manual edits made directly within the IdentityIQ user interface, or even be initiated programmatically via custom rules or workflows. The trigger mechanism is flexible and not limited solely to authoritative application data.

A. Yes: This is incorrect. The word "only" makes the statement factually inaccurate, as IdentityIQ's Lifecycle Event framework supports multiple trigger sources beyond just authoritative applications.

1. SailPoint IdentityIQ 8.3 Administration Guide, "Lifecycle Manager," p. 312: "Events can be triggered by a change to an identity attribute from any source, not just authoritative applications."

2. SailPoint Compass Documentation, "Lifecycle Events": "A lifecycle event can be triggered by a change to an identity attribute, regardless of the source of that change. This includes changes from aggregations, UI edits, or even custom rules."

The statement is inaccurate. The connector used by an application definition is determined by the Application Type selected from a dropdown list during configuration, not by the Application Name. The Application Name is a user-defined, descriptive label used to identify that specific application instance within the IdentityIQ user interface (e.g., "Marketing Dept AD" or "Finance SAP"). The Application Type (e.g., "Active Directory", "Delimited File", "JDBC") is what links the application definition to the underlying connector code that handles communication with the target system.

A: This is incorrect because the Application Name is purely a display label for identification. The functional binding to a connector is made through the "Application Type" selection.

1. SailPoint IdentityIQ 8.2, Administration Guide, Chapter 6: "Application Configuration", Section: "Defining Applications". The steps and screenshots clearly show "Name" and "Application Type" as two distinct and separate fields, where "Application Type" is a dropdown list of available connectors.

2. SailPoint University, IdentityIQ Administration Courseware, Module: "Onboarding Applications". The course material demonstrates that creating an application requires providing a unique name and then selecting the appropriate connector from the "Application Type" list.

This is the primary function of the Entitlement Catalog. It translates raw, often cryptic, entitlement data aggregated from applications (e.g., Active Directory distinguished names) into human-readable display names and descriptions. This enriched data is then presented to business users in access request forms, reports, and certification campaigns to enable informed and accurate governance decisions.

B. No: This is incorrect. Providing user-friendly names for entitlements in requests, reports, and certifications is the core, defining purpose of the IdentityIQ Entitlement Catalog.

1. SailPoint IdentityIQ 8.2, User Guide, "The Entitlement Catalog," p. 121: "The Entitlement Catalog enables you to provide more user-friendly, business-oriented information about the entitlements that are discovered on your applications... This information is then displayed in certifications and in the access request interface."

2. SailPoint IdentityIQ 8.1, Technical Whitepaper: The Entitlement Catalog, Section 1.1: "The primary goal of the entitlement catalog is to associate business-friendly language and descriptions with native system entitlements."

A Lifecycle Event in IdentityIQ is a configured response to a change in an identity's data. Its core components are a trigger, which specifies the data change to monitor (e.g., an attribute change), and an associated business process (workflow) that is launched when the trigger condition is met. This mechanism is fundamental for automating Identity and Access Management (IAM) processes, such as manager transfers or departmental moves, by executing a defined workflow in response to a specific identity event.

B: This is incorrect. The statement accurately describes the primary function and configuration of a Lifecycle Event in IdentityIQ.

SailPoint IdentityIQ 8.3, Administrator's Guide, "Lifecycle Manager," pp. 15-17. This section details the configuration of Lifecycle Events, explicitly stating they are linked to business processes that execute upon a trigger.

SailPoint University, IdentityIQ Administration Courseware, Module: "Lifecycle Manager." The course material explains that a Lifecycle Event consists of a trigger (a change to an Identity) and a corresponding action (a business process).

This definition is inaccurate. An Identity Cube is a central data model in IdentityIQ that represents a unique person and consolidates all their associated information. This includes identity attributes (e.g., name, department), accounts on various applications, entitlements, risk scores, and role memberships. It provides a 360-degree view of an identity's access. A snippet of code containing custom business logic is referred to as a Rule or a script in IdentityIQ, which can be used to customize system behavior.

A. Yes: This is incorrect. The definition provided describes a Rule or script, which is a distinct concept from the Identity Cube data model.

1. SailPoint IdentityIQ 8.1, Concepts Guide, Version 8.1, "Identity Cubes," p. 11. (Defines the Identity Cube as a "multidimensional data model that represents a user in the system").

2. SailPoint IdentityIQ 8.1, BeanShell Developer's Guide, Version 8.1, "Rules," p. 7. (Defines a Rule as "a snippet of BeanShell or Java code that can be embedded at certain points in IdentityIQ execution").

The primary purpose of defining lifecycle events is to automate identity processes (provisioning, de-provisioning, updates) in response to changes in an identity's status. While this automation contributes to a stronger security and compliance posture by ensuring timely access changes, its direct function is not policy enforcement. Preventing policy violations is the primary responsibility of the IdentityIQ Compliance Manager. The Compliance Manager uses policies to detect and report on inappropriate access or separation of duty (SoD) conflicts, which is a distinct function from the event-driven process automation managed by the Lifecycle Manager.

A. Yes: This is incorrect. Policy violation prevention is the main function of the Compliance Manager component, not Lifecycle Events, which focus on automating JML processes.

1. SailPoint IdentityIQ 8.1, Technical Whitepaper: Compliance Manager, Page 3: "The SailPoint Compliance Manager automates the enforcement of corporate and regulatory policies for user access... It provides the tools to define policies, scan for violations, and manage the remediation process."

2. SailPoint IdentityIQ 8.2, Concepts Guide, Chapter: "Compliance Management", Page 55: "IdentityIQ enables you to define policies to check for things like separation of duty violations... Policy scanning can be run on a scheduled basis to identify violations." This contrasts with the description of Lifecycle Manager's role in the same document.

The statement does not correctly describe Lifecycle Manager (LCM). The description provided—automating the collection and provisioning of identity data across all enterprise resources—accurately defines the entire SailPoint IdentityIQ platform, not just one of its modules. Lifecycle Manager is a specific component of IdentityIQ focused on providing a user-friendly, business-oriented interface for managing identity-related events. Its primary functions include handling self-service access requests, managing automated workflows for joiners, movers, and leavers (JML processes), and password management. It is the front-end for business users to interact with the platform's core capabilities.

A. Yes: This is incorrect because the description is too broad. It defines the entire IdentityIQ product, not the specific functions of the Lifecycle Manager module.

1. SailPoint IdentityIQ 8.2, User Guide for Lifecycle Manager, Chapter 1: "Introduction to Lifecycle Manager." This guide defines LCM as the module for managing access requests, lifecycle events, and passwords through a simplified interface for business users.

2. SailPoint University, IdentityIQ Administration Courseware, Module: "Lifecycle Manager Configuration," Section 1.1: "What is Lifecycle Manager?" The material distinguishes LCM as the user-facing component for requests and events, which leverages the core platform's aggregation and provisioning engine.

The statement is false because it confuses an "account attribute" with an "Identity attribute." An account attribute exists on a single, specific application and its value is sourced only from that application (e.g., the employeeID on a Workday account comes only from Workday). In contrast, an Identity attribute (on the Identity Cube) is a composite attribute that can be sourced and aggregated from multiple different applications. For example, an Identity's email attribute could be mapped from an HR system, Active Directory, and an email system.

A. Yes: This is incorrect. A specific account attribute is, by definition, tied to a single account on a single application and thus has a single source.

1. SailPoint IdentityIQ Administration Guide Version 8.2, "Part II: The Identity Cube," Chapter 5: The Identity Cube, Section: "Identity Attributes vs. Application Account Attributes," p. 102. (Clearly distinguishes that Identity attributes can be mapped from multiple sources, while account attributes are specific to one application).

2. SailPoint IdentityIQ 7.1 Concepts Guide, "The Identity Cube," p. 5. (Explains that the Identity Cube is a central repository that aggregates data, including account attributes from various sources, into a single logical representation of a user).

This statement is false for two reasons. First, the term "Uncorrelated Identity Cubes" is incorrect; the proper term is "uncorrelated accounts" or "native identities," which are application accounts not linked to an Identity Cube. Second, and more importantly, IdentityIQ does not have a default, time-based rule that automatically removes uncorrelated accounts after 30 days. Uncorrelated accounts persist in the system until they are either manually correlated, automatically correlated by a new rule or aggregation, or explicitly deleted by an administrator or a custom-configured task.

A: This is incorrect as there is no standard 30-day automatic cleanup process for uncorrelated accounts in IdentityIQ. Their lifecycle is determined by administrative action or specific configuration.

1. SailPoint IdentityIQ 8.1, Concepts Guide, Version 8.1, "Chapter 2: IdentityIQ Terminology," p. 13. The guide defines Correlation and the Identity Cube, clarifying that accounts are correlated to cubes, not the other way around. There is no mention of an "uncorrelated Identity Cube."

2. SailPoint IdentityIQ 8.1, Administration Guide, Version 8.1, "Chapter 10: Correlation," pp. 249-251. The chapter details the management of uncorrelated accounts, describing manual correlation and automated creation rules, with no mention of a default 30-day deletion period.

IdentityIQ capabilities are used to grant authorization to perform actions within the IdentityIQ platform itself, such as running reports, managing roles, or configuring system settings. They do not directly grant permissions or entitlements on external, connected applications. Access to a connected application is managed through the accounts and entitlements on that specific application, which IdentityIQ aggregates and governs. Granting an IdentityIQ capability will not give a user elevated permissions on a target system like Active Directory or a database.

A. Yes: This is incorrect because capabilities control access to IdentityIQ's own user interface and functions, not the permissions within external systems.

1. SailPoint IdentityIQ Administration Guide Version 8.2, "Part V: IdentityIQ Configuration," Chapter 21: The System Setup Menu, Section: "Defining Capabilities," p. 615. (Explains that capabilities are rights assigned to users to control access to IdentityIQ functionality).

2. SailPoint IdentityIQ Concepts Guide Version 7.1, "Authorization in IdentityIQ," p. 10. (Describes the internal authorization model, differentiating between capabilities for UI access and entitlements on external resources).