Nail the SailPoint IdentityIQ-Associate: Identity Governance Strategy (2026)

No. BeanShell rules are not required to implement aggregation in SailPoint IdentityIQ. Aggregation is a standard IdentityIQ function performed through an application definition, connector configuration, schema definition, correlation settings, and aggregation task execution. Many common connectors can aggregate accounts and groups without any custom rule because the connector and schema configuration provide the required instructions for reading objects from the source system.

Rules are used when additional customization is needed. For example, an aggregation rule may transform incoming attribute values, filter records, normalize data, customize correlation behavior, or handle source-specific logic that cannot be expressed through standard configuration. However, this makes rules optional extension points, not mandatory components of aggregation.

A properly configured application can aggregate accounts using its connector settings, account schema, group schema, and aggregation task options alone. Rules should be introduced only when the standard connector behavior and configuration do not satisfy the implementation requirements.

Reference topics: Applications, aggregation tasks, connector configuration, account schema, group schema, correlation options, application rules, connector rules, and IdentityIQ extensibility through BeanShell rules.

Yes. Lifecycle Events in SailPoint IdentityIQ are defined to detect significant identity changes and trigger the appropriate business process in response. Organizations commonly use them to automate joiner, mover, and leaver scenarios. A joiner event may be triggered when a new identity is created or becomes active. A mover event may be triggered by changes such as department, job title, manager, location, or business unit. A leaver event may be triggered when an identity’s employment status or lifecycle state indicates termination.

The lifecycle event configuration defines the condition to monitor and the business process or workflow to execute when that condition is met. This allows IdentityIQ to automate access provisioning, role assignment, account creation, access removal, account disablement, approvals, notifications, and other lifecycle-driven actions.

Therefore, the statement is accurate. Lifecycle Events are specifically used to define what identity data changes should initiate joiner, mover, or leaver processing.

Reference topics: Provisioning, Lifecycle Events, joiner-mover-leaver processing, identity attribute changes, business processes, workflows, and event-driven provisioning.

The statement is false. In IdentityIQ, an account attribute is defined within a specific application account schema and represents data stored on an account link for that application. Its value is obtained from the account data aggregated from that particular application connector. For example, an account attribute such asmemberOf,department,title, oraccountStatusbelongs to the account schema of a defined application and is populated from that application’s aggregation results.

The concept of sourcing values from several applications applies more directly to identity attributes, not account attributes. Identity attributes reside on the IdentityCube and may be derived from authoritative sources, account links, rules, mappings, or precedence logic across multiple applications. IdentityIQ uses identity attribute configuration to normalize data such as department, location, manager, email, or lifecycle state at the identity level.

Therefore, while multiple applications may contain similarly named account attributes, each account attribute value is tied to its own application account schema and account link. It is not a single shared account attribute sourced from several applications.

Reference topics: Applications — account schema attributes; Identity Modeling — identity attributes versus account attributes; Identity Refresh — updating IdentityCube attributes.

The statement is false. In SailPoint IdentityIQ, account attributes are updated through application aggregation, not through the Identity Refresh task. Account attributes belong to account links for a specific application and are defined in that application’s account schema. When an aggregation task runs, IdentityIQ connects to the target application using the application definition and connector configuration, reads account data, and updates the account/link attributes stored in IdentityIQ.

The Identity Refresh task performs a different function. It operates on IdentityCubes and recalculates identity-level information using data already present in the IdentityIQ repository. Identity Refresh can update identity attributes, refresh role assignments, evaluate policies, process lifecycle events, update manager relationships, and recalculate governance state. It does not directly re-read account attribute values from connected systems.

This distinction is central to IdentityIQ’s data model: account attributes describe accounts on applications, while identity attributes describe the consolidated user identity. Therefore, account attribute updates come from aggregation, while identity attribute updates may occur during Identity Refresh.

Reference topics: Applications — application account schema and aggregation; Identity Modeling — identity attributes versus account attributes; Identity Refresh task options.

Yes. In SailPoint IdentityIQ aggregation, correlation is attempted first to match an aggregated account to an existing IdentityCube. Correlation may use configured attribute mappings, correlation rules, or other application correlation logic. If IdentityIQ cannot correlate the account to an existing identity, the application’s creation rule, when configured, can be invoked to determine how IdentityIQ should handle identity creation for that uncorrelated account.

This is especially relevant for authoritative applications, where aggregated account records may represent people who should exist as identities in IdentityIQ. The creation rule can control identity creation behavior, populate required identity attributes, and apply implementation-specific logic when standard correlation does not find a match. Without appropriate creation behavior, the account may remain uncorrelated and require later remediation through corrected correlation logic, re-aggregation, or manual correlation.

Therefore, the statement is accurate: the creation rule is associated with the aggregation and correlation process and is used when an account cannot be matched to an existing IdentityCube. Reference topics: Applications, BeanShell rules, account aggregation, correlation logic, identity creation rules, authoritative applications, and uncorrelated account handling.

The statement is true. In SailPoint IdentityIQ, group factories are used to generate identity groups dynamically based on identity attribute values or configured grouping logic. A group factory defines the rule or attribute basis for grouping identities, but the actual creation or refresh of the resulting groups occurs when the appropriate task is executed. For example, a group factory might be configured to create groups by department, location, cost center, or business unit. When the task runs, IdentityIQ evaluates identities against the factory definition and creates or updates the corresponding groups.

This differs from populations, which are typically defined sets of identities used for targeting, filtering, reporting, or governance scoping. Group factories are more generation-oriented because they can produce multiple group objects from identity data. The task execution step is important because it materializes the groups so they can be used in IdentityIQ operations.

Therefore, new groups can be created as a result of executing a task tied to group factory processing. Reference topics: Identity Modeling — groups and populations, group factories, identity grouping, and task-driven group creation.

Yes. Granting an IdentityIQ capability is a valid way to provide access to additional functions within SailPoint IdentityIQ, including areas such as Advanced Analytics. Capabilities are part of IdentityIQ’s internal authorization model. They determine what a logged-in user is allowed to see and perform inside the IdentityIQ interface, such as administration, reporting, certification administration, role management, policy management, or advanced search and analysis functions.

Advanced Analytics searches are IdentityIQ functions, not external application permissions. Therefore, access to those search types is governed by IdentityIQ security controls, including capabilities, rights, and in some deployments, scoping. This is different from granting access on a connected application, which would be handled through accounts, entitlements, roles, access requests, and provisioning.

The key distinction is that capabilities grant authority inside IdentityIQ itself. They do not directly modify a user’s access on a target system. Providing access to different types of Advanced Analytics searches is therefore an appropriate reason to assign an IdentityIQ capability.

Reference topics: Identity Modeling — how IdentityIQ access is granted to users; Foundational Concepts — common IdentityIQ objects and components; Governance — analytics and access visibility.

No. Connector-based delta processing is not available to all connectors in SailPoint IdentityIQ. Delta aggregation is a performance optimization that allows IdentityIQ to process only changes since a previous aggregation, instead of reading and processing the complete account population each time. However, this capability depends on whether the selected connector and target system support reliable change detection.

Some systems can expose changes through timestamps, change logs, sequence numbers, tokens, directory synchronization controls, or similar mechanisms. Other systems, such as simple file-based sources or connectors without change-tracking capability, may only support full aggregation. Because IdentityIQ connector behavior is connector-dependent, delta processing cannot be treated as a universal aggregation option.

The application’s connector selection determines which aggregation options are available, including whether connector-based delta processing can be enabled. Administrators must verify connector capability and configure aggregation accordingly.

Therefore, the statement is false because connector-based delta processing is a performance option only for supported connectors, not for every connector in IdentityIQ. Reference topics: Applications, aggregation task options, connector-dependent capabilities, account aggregation, delta aggregation, and performance optimization.

Yes. In SailPoint IdentityIQ, an application definition represents an external system or managed source and contains the configuration IdentityIQ needs to connect to and interact with that system. The selected connector determines which connectivity settings are required, and the application definition stores those values. Examples can include server host, port, credentials, JDBC URL, file path, API endpoint, tenant information, authentication parameters, or other connector-specific settings.

This connectivity information enables IdentityIQ to perform operations such as account aggregation, group aggregation, schema discovery, entitlement collection, and provisioning where the connector supports write operations. The exact fields vary by connector type, which is why an LDAP, JDBC, Delimited File, Active Directory, or Web Services application may expose different configuration requirements.

Therefore, the statement is accurate: application definitions contain the communication and connectivity configuration used by IdentityIQ to access the application. Reference topics: Applications, application definition, connector selection, connector-dependent settings, account aggregation, schema configuration, and provisioning support.

Yes. In SailPoint IdentityIQ, some application connectors include predefined schema information because the structure of accounts and groups on those target systems is well known to the connector. When an application is created and a specific connector type is selected, IdentityIQ may automatically populate schema elements such as the account schema, native identity attribute, display attribute, common account attributes, and sometimes group or entitlement schema definitions. This is common for standard connectors where the managed system has a predictable object model.

However, predefined does not mean final or immutable. The application administrator must still review and adjust the schema to ensure it accurately represents the implementation, including which attributes are aggregated, which attributes are searchable, which attributes are entitlements, and which attributes are used for identity correlation. Other connector types, such as generic JDBC, delimited file, or custom connectors, may require more manual schema definition.

This statement is therefore accurate because connector selection can provide default schema structure. Reference topics: Applications, connector selection, account schema, group schema, schema attributes, aggregation configuration, and application definition.