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

Yes. In SailPoint IdentityIQ, marking an application account schema attribute as managed identifies that attribute as governance-relevant access data. This is commonly applied to attributes that contain entitlement-like values, such as groups, roles, permissions, or application access assignments. When the attribute is managed, IdentityIQ can create and maintain managed attribute records for the values discovered during aggregation, allowing those values to be represented in the entitlement catalog with business metadata such as display name, description, owner, requestability, and classification.

This managed designation supports governance processes, including certifications. In an access review, reviewers need to evaluate meaningful access items rather than raw account data. Managed entitlement values can therefore be surfaced as reviewable access so managers, application owners, or entitlement owners can approve, revoke, or otherwise act on them during certification campaigns.

This does not mean the attribute itself is simply editable in IdentityIQ; editability is controlled separately through provisioning policies, forms, workflows, and connector support. The managed flag is primarily about governing the attribute’s values as access.

Reference topics: Applications — schema attribute properties; Access Modeling — entitlement catalog; Governance — certification review items.

Yes. In SailPoint IdentityIQ, correlation logic can be specified for authoritative applications. An authoritative application is commonly used as a trusted source for identity data, such as HR or another system of record. During aggregation, IdentityIQ reads account or source records from the application and uses correlation logic to determine whether each record should be linked to an existing IdentityCube or used in identity creation and update processing.

Correlation logic may be configured using account attributes, identity attributes, or correlation rules. For example, an authoritative source may correlate records by employee ID, user name, email address, or another unique identifier. This ensures that incoming authoritative data updates the correct identity instead of creating duplicates or leaving records uncorrelated.

The authoritative nature of the application does not eliminate the need for correlation. It defines the trust level and identity-data role of the source, while correlation defines how records from that source are matched to identities in IdentityIQ.

Reference topics: Applications, authoritative applications, correlation options, account aggregation, IdentityCube creation, identity attribute mapping, and uncorrelated account resolution.

This is not a standard example of a policy that can be defined in IdentityIQ. IdentityIQ policies are governance controls used to detect inappropriate access, risky access combinations, account conditions, identity conditions, or activity-related violations based on configured policy logic. Common policy examples include separation of duties policies, account policies, identity policies, risk policies, and activity policies. These policies evaluate identities, accounts, roles, entitlements, attributes, and access relationships to determine whether a violation exists.

The wording “administrator policy” is not a standard IdentityIQ policy category. IdentityIQ can audit administrative activity and can secure administrative functions through capabilities, scopes, workgroups, permissions, and object-level controls, but that is different from defining an “administrator policy” as a governance policy type. Risky actions performed within IdentityIQ itself are generally handled through audit events, administrative security configuration, logging, and operational monitoring rather than a standard policy definition named administrator policy.

Therefore, this statement does not describe a valid common IdentityIQ policy example. Reference topics: Governance — examples of common policies, policy detection, policy violations; Foundational Concepts — common objects and components; Identity Modeling — IdentityCube attributes and access context.

Yes. The Identity Warehouse in SailPoint IdentityIQ is used to display identity-centered information from the IdentityCube and related IdentityIQ object relationships. In addition to core identity attributes, accounts, roles, entitlements, manager relationships, and direct reports, IdentityIQ can show objects for which the identity is designated as the owner. Ownership is an important governance concept because owners may be responsible for approving access, maintaining roles, reviewing entitlements, managing applications, or participating in certification and remediation processes.

An object owner in IdentityIQ may be associated with configurable objects such as roles, applications, managed attributes, policies, or other governance-related items. Displaying owned objects from the identity view helps administrators and governance users understand the responsibilities assigned to that identity, not just the access held by the identity. This distinction matters because IdentityIQ models both “what access the identity has” and “what governance responsibilities the identity owns.”

Therefore, a list of objects the user owns is appropriately displayed in the Identity Warehouse when ownership relationships exist and the viewer has sufficient permission. Reference topics: Identity Modeling, IdentityCube contents, Identity Warehouse, object ownership, manager relationships, and governance responsibility modeling.

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 not technically accurate. In SailPoint IdentityIQ, applications are defined to represent external systems, platforms, directories, databases, or resources from which account, group, entitlement, and attribute data are aggregated, and in some cases to which provisioning changes are written. IdentityIQ does not generally “read identities” directly from applications. Instead, it reads account records and associated attributes from applications, then uses identity correlation, authoritative-source logic, and identity refresh processing to construct or update IdentityCubes.

This distinction is fundamental. An application may be an authoritative source, such as an HR system, where account attributes contribute heavily to identity creation and lifecycle state. However, the object read from the source is still an account or source record, not an IdentityIQ identity object. The identity is modeled inside IdentityIQ after aggregation and correlation occur.

Therefore, the more precise statement is that applications represent systems from which IdentityIQ reads account and access data, not systems from which IdentityIQ simply reads identities. Reference topics: Applications, application definition, account aggregation, authoritative applications, correlation, IdentityCube creation, and Identity Modeling.

The statement is true in the context of IdentityIQ manager correlation. IdentityIQ does not infer an identity’s manager relationship without source data that identifies the manager. The authoritative application, typically an HR or personnel source, provides the trusted identity records and should include a manager reference attribute, such as manager ID, employee number, username, distinguished name, or another value that can be correlated to an existing IdentityIQ identity.

During aggregation and identity refresh, IdentityIQ uses configured manager correlation logic to resolve that manager reference to an IdentityCube representing the manager. Once resolved, the manager relationship can support governance functions such as manager certifications, access request approvals, lifecycle approvals, escalations, and reporting hierarchy-based controls. Without a manager reference from the authoritative source, IdentityIQ may still contain identities, accounts, and access, but it cannot reliably establish reporting relationships for those identities through standard manager correlation.

This is distinct from manually assigning relationships or using custom logic; the standard governance model expects manager data to originate from the authoritative identity source. Reference topics: Identity Modeling — manager correlation, IdentityCube attributes, authoritative identity data; Governance — manager-based certifications and approvals; User-Driven Requests — manager approval routing.

Recording which data a user downloads is not a core purpose of Identity Governance and Administration in SailPoint IdentityIQ. IGA is concerned with governing identities, accounts, access, entitlements, roles, policy violations, certifications, access requests, and provisioning. Its central objective is to answer questions such as who a user is, what access they have, whether that access is appropriate, who approved it, and whether access complies with defined business and security policies.

Tracking the specific files, records, or data objects downloaded by a user is typically associated with data activity monitoring, data loss prevention, security information and event management, or user behavior analytics. IdentityIQ may integrate with other systems and can govern access to applications or repositories that contain sensitive data, but it does not primarily function as a tool for recording every data download event.

In IdentityIQ terms, the governance focus is identity security: access visibility, access certification, policy enforcement, role modeling, lifecycle management, and provisioning controls. Reference topics: Foundational Concepts, purpose of identity security, common IdentityIQ terms, governance model, certifications, policies, and provisioning.

Yes. In SailPoint IdentityIQ, connector selection determines not only how IdentityIQ communicates with the target application, but also which operations the connector is capable of supporting. The connector featureString identifies connector capabilities exposed to IdentityIQ. These capabilities can include whether the connector supports account aggregation, group aggregation, schema discovery, provisioning, password management, authentication, or other connector-specific functions.

This is important because IdentityIQ uses connector capabilities to determine which configuration options and operational behaviors are valid for the application. For example, a connector that supports provisioning can write account or entitlement changes back to the managed system through provisioning plans. A read-only connector, by contrast, may support aggregation but not allow IdentityIQ to create, modify, disable, or delete accounts on the target. Therefore, the featureString helps define whether the connector can perform write operations against the application.

The statement is accurate because the connector’s advertised features directly describe functional capabilities, including the ability to write changes where supported. Reference topics: Applications, connector selection, application definition, connector-dependent settings, provisioning support, aggregation behavior, and connector capabilities.