SailPoint Certified IdentityIQ Associate IdentityIQ-Associate Exam Questions

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

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.

Answer : B

The statement is false. The Edit Identity QuickLink is not intended merely to view identity details; its purpose is to initiate an identity modification request. In IdentityIQ, QuickLinks are request-entry mechanisms that expose controlled actions to users based on QuickLink Population rules, capabilities, request configuration, and target permissions. The Edit Identity QuickLink allows an authorized user to update configured identity attributes, typically through a form-driven request process that may include validation, approval, audit tracking, and workflow execution.

Viewing identity details is a separate functional concept. Identity information is normally reviewed through identity search, identity warehouse views, certification access review context, or identity detail pages, where the user can inspect IdentityCube data such as attributes, accounts, roles, entitlements, manager, and policy violations. Edit Identity may display current values so the requester understands what is being changed, but display is contextual, not the primary function.

Therefore, ''It is used to view details about an identity'' describes a view-oriented function, not the Edit Identity QuickLink. Reference topics: User-Driven Requests, QuickLink Populations, create/edit/self-service identity requests, Identity Modeling, and IdentityCube usage.

Answer : B

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 as memberOf, department, title, or accountStatus belongs 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.

Answer : A

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.

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 : A

Detecting and addressing inappropriate access is a core purpose of Identity Governance and Administration in SailPoint IdentityIQ. IdentityIQ is designed to provide visibility into who has access, what access they have, how that access was obtained, whether it is appropriate, and what corrective action should occur when access violates business or security policy. Inappropriate access may be identified through access certifications, policy violations, role analysis, entitlement review, account aggregation, and identity correlation.

IdentityIQ supports this purpose by building IdentityCubes that consolidate identity, account, entitlement, role, and manager data from connected applications. Once access is visible, governance controls such as certifications allow managers, application owners, or entitlement owners to approve, revoke, or delegate access decisions. Policies can also detect toxic combinations, prohibited access, or access inconsistent with business rules. Remediation can then be routed through provisioning, work items, or manual fulfillment processes.

Therefore, the statement aligns directly with IGA and IdentityIQ's identity security model. Reference topic: Foundational Concepts --- purpose of identity security; also related to Governance --- certifications, policy detection, and remediation.