Prepare Smarter for the IdentityIQ-Associate Exam

No. Marking an attribute as multi-valued does not, by itself, cause IdentityIQ to treat that attribute as an entitlement or include its values in the Entitlement Catalog.

In an application schema, the multi-valued setting only indicates that the account attribute can contain more than one value. It describes data structure, not governance meaning.

To include access values in the Entitlement Catalog, the relevant schema attribute must be configured as an entitlement-bearing attribute, or group objects

must be properly configured and aggregated through the application’s group schema where applicable. IdentityIQ then

recognizes those values as governable access rights and can represent them as managed attributes in the Entitlement Catalog. Once cataloged, they can be

reviewed, certified, requested, described, owned, risk-scored, and governed by policy.

For example, an account attribute such as “groups” may be multi-valued, but IdentityIQ must also know that those

values represent access rights. Without entitlement configuration, the aggregation stores attribute values

on the account but does not properly model them as catalog entitlements.

Reference topics: Access Modeling, Entitlement Catalog, managed attributes, application schema attributes,

entitlement attribute configuration, group schema, and account aggregation

The statement is false. The Identity Refresh task is used to update and recalculate identity-related data in IdentityIQ, not to manage open work

item reminders. Its purpose is to refresh IdentityCubes after aggregation or identity data changes. Depending on selected task options,

Identity Refresh can recalculate identity attributes, apply correlation-related updates, refresh role assignments and detections, evaluate

policies, process lifecycle events, update risk-related data, and ensure that the identity model reflects the current state of authoritative and application data.

Open work items belong to IdentityIQ’s workflow and governance execution layer. Reminders, escalations, expirations, and related work item follow-up behavior are handled through work item configuration, workflow behavior, certification configuration, and maintenance-style processing rather than the Identity Refresh task. Although Identity Refresh may trigger

downstream actions such as lifecycle events or policy evaluation, it is not the task responsible for notifying users about pending approvals or review items.

Therefore, sending reminders for open work items is outside the purpose of Identity Refresh. Reference topics: Identity

Modeling — common Identity Refresh options; Foundational Concepts — tasks versus workflows; Governance — work items,

certifications, reminders, and escalation behavior.

Yes. Aggregation partitioning in SailPoint IdentityIQ is a performance and scalability option used to divide a large aggregation

workload into smaller units of work. Instead of processing the entire aggregation as one continuous task on a single execution thread,

IdentityIQ can partition the work so multiple task executors can process different portions of the aggregation workload concurrently.

This is especially useful in large environments where applications contain many accounts, groups, or entitlement records.

Partitioning can improve throughput by distributing processing across multiple hosts in an IdentityIQ deployment and by

allowing multiple threads per host to participate in the aggregation workload. The goal is to reduce total aggregation runtime while

maintaining controlled processing of account and entitlement data.

Partitioning is not the same as connector-based delta processing. Delta processing depends on connector support for identifying changed records,

while partitioning concerns how the aggregation workload is divided and executed. Therefore, the statement is accurate.

Reference topics: Applications, aggregation task options, aggregation partitioning, account aggregation, performance optimization, task execution, and multi-host processing.

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.

The statement is true. In SailPoint IdentityIQ, account attributes are defined on the application’s account schema. The application definition tells IdentityIQ how

to represent accounts from a connected source, and the account schema specifies which attributes exist on those accounts. Examples may include account ID,

display name, email, status, department, groups, roles, permissions, or other source-specific fields returned by the connector during aggregation.

This is distinct from identity attributes, which are stored on the IdentityCube and represent normalized identity-level data used across IdentityIQ.

Account attributes belong to application account links, while identity attributes belong to the identity model. During aggregation, IdentityIQ reads

account data according to the application schema and stores the discovered values as account/link attributes. Some account schema attributes may

also be marked as managed when their values represent entitlement-like access that should be governed through the Entitlement Catalog.

Therefore, account attributes are correctly defined in the application account schema. Reference topics: Applications — application definitions,

account schema attributes, schema attribute properties; Identity Modeling — identity attributes versus account attributes; Access Modeling — managed

attributes and entitlement catalog.