SailPoint Certified IdentityIQ Associate IdentityIQ-Associate Exam Questions

Answer : B

The statement is false. The Identity Refresh task does not execute aggregation rules configured on an application definition. Aggregation rules are part of the application aggregation process, where IdentityIQ connects to a source system, reads account or group data, applies connector and application-level processing, and stores account links, entitlement values, and related data in the IdentityIQ repository.

The Identity Refresh task operates after data is already present in IdentityIQ. Its function is to update IdentityCubes and recalculate identity-level governance information. Depending on selected options, Identity Refresh may update identity attributes, refresh role assignments, detect assigned or detected roles, evaluate policies, process lifecycle events, refresh manager relationships, or recalculate risk and access-related identity state.

Application aggregation and identity refresh are separate task functions. Aggregation obtains and normalizes data from applications; Identity Refresh interprets and recalculates identity governance state using that aggregated data. Therefore, rules tied specifically to aggregation on the application definition are execute during aggregation, not during Identity Refresh.

Reference topics: Identity Modeling --- Identity Refresh task options; Applications --- aggregation rules and application definitions; Foundational Concepts --- tasks and workflows.

Answer : B

No. The ''Detect deleted accounts'' aggregation task option is not used to ignore accounts that were previously deleted from IdentityIQ. Its purpose is to compare the accounts returned by the current aggregation with the accounts already stored in IdentityIQ for that application. When an account exists in IdentityIQ but is no longer found in the authoritative aggregation results from the source application, IdentityIQ can treat that account as deleted or removed from the target system.

This option helps keep IdentityIQ's account inventory accurate by identifying stale Links that remain in IdentityIQ even though the corresponding account is no longer present on the application. It is especially important for governance accuracy because certifications, policy checks, identity warehouse views, and access reporting rely on current account and entitlement data.

The statement is incorrect because it reverses the behavior. Detecting deleted accounts is about recognizing accounts missing from the source during aggregation, not ignoring newly returned source accounts that were once deleted in IdentityIQ.

Reference topics: Applications, aggregation task options, account aggregation, deleted account detection, Link maintenance, IdentityCube account data, and application data reconciliation.

Answer : B

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.

Answer : A

The statement is accurate. In SailPoint IdentityIQ LifeCycle Manager, the Manage Accounts feature is used for account-level request operations. It allows authorized users to request account changes on connected applications, including requesting an additional account when the target application and IdentityIQ configuration support multiple or additional accounts for the same identity.

This capability is controlled through the application definition, request configuration, QuickLink availability, provisioning policies, and workflow approvals. When an application supports additional accounts, IdentityIQ can present account-request options that allow the requester to create another account rather than only modifying or removing an existing one. The request is then converted into a provisioning plan, routed through configured approval logic, and fulfilled either automatically through the connector or manually through a work item.

This is different from requesting entitlements alone. Manage Accounts focuses on account lifecycle operations such as create, modify, delete, enable, disable, or unlock, depending on connector and application support. Therefore, allowing users to request additional accounts on applications configured to support them is a valid Manage Accounts function.

Reference topics: User-Driven Requests --- account request types and operations; Provisioning --- provisioning plans and provisioning policies; Applications --- application configuration and connector support.

Answer : B

No. In SailPoint IdentityIQ, tasks are execution mechanisms used to perform system operations such as aggregation, identity refresh, certification generation support, report execution, maintenance processing, and other repeatable administrative jobs. A task can collect data, refresh calculated identity information, process objects, or execute configured logic, but it does not itself provide the business review function of confirming whether an account group provides the correct access.

Confirming that an account group provides appropriate access is a governance activity. That type of validation is performed through access reviews or certifications, where a designated reviewer evaluates group membership, permissions, ownership, or entitlement meaning and decides whether the access remains appropriate. This requires human or configured governance judgment, not simply execution of a background task.

A task may support the process indirectly by aggregating current account group data or preparing certification data, but the actual confirmation of correctness belongs to certification and governance review functionality.

Reference topics: Foundational Concepts, tasks versus workflows, Governance, certifications, account group reviews, access reviews, and Access Modeling.

Answer : B

The statement is false. In SailPoint IdentityIQ, groups and populations are used to classify, filter, and organize identities for governance, reporting, certifications, and targeted user experiences. A population is a defined collection of identities, and group factories can dynamically create identity groups based on configured identity attributes. These constructs are useful for segmentation, analysis, and campaign targeting, but they are not the standard objects assigned as owners of IdentityIQ objects.

Ownership in IdentityIQ is normally assigned to an identity or to a workgroup. A workgroup is used when ownership or responsibility must be shared by multiple users, such as application owners, certification owners, entitlement owners, or approval groups. This distinction matters because ownership drives accountability, work item assignment, approvals, escalations, and administrative responsibility. Populations and generated groups do not function as accountable owners in the same way workgroups do.

Therefore, while groups and populations can influence governance scope and visibility, they are not assigned as object owners. Reference topics: Identity Modeling --- groups and populations; Foundational Concepts --- common objects and usage; Governance --- ownership, certifications, and work item responsibility.

Answer : A

Yes. In SailPoint IdentityIQ, BeanShell rules used during aggregation are optional processing extensions, and task configuration can control whether rule processing is applied for a particular aggregation run. Aggregation itself is performed through the application definition, connector, schema, and aggregation task. Rules may be added to customize behavior, such as transforming incoming account data, applying custom correlation logic, handling identity creation, or modifying account information before it is stored.

Because rules can significantly affect aggregation behavior, IdentityIQ provides task-level controls that allow administrators to disable rule processing when appropriate. This can be useful for testing connector behavior, isolating troubleshooting scenarios, improving performance during certain runs, or validating source data without custom transformation logic. When rule processing is disabled, aggregation relies on standard connector and configuration behavior rather than custom BeanShell execution.

Therefore, the statement is accurate. Rule execution is not mandatory for aggregation and can be controlled from the task definition. Reference topics: Applications, aggregation tasks, BeanShell rules, connector configuration, account schema, correlation rules, creation rules, and aggregation task options.