SailPoint IIQ Interview Questions for Freshers and Working Professionals

Identity and Access Management (IAM) is the discipline of ensuring that the right people in an organisation have the right access to the right resources — at the right time and for the right reasons. It covers the full lifecycle of digital identities: creating accounts when someone joins, adjusting access when they change roles, and revoking it when they leave. IAM is a foundational security layer required by virtually every regulated enterprise.

SailPoint IdentityIQ (IIQ) is an enterprise identity governance and administration (IGA) platform. It helps large organisations manage who has access to what across hundreds of connected applications and systems — from Active Directory to SAP to Salesforce. The business problem it solves is access sprawl: without IIQ, enterprises have no single view of who has access to what, making compliance audits, access reviews, and deprovisioning manual and error-prone. IIQ automates identity lifecycle management, access certification campaigns, and policy enforcement. SailPoint Technologies is the product vendor. SailPoint Academy is an independent training provider and is not affiliated with SailPoint Technologies.

Authentication is the process of verifying who you are — confirming your identity (e.g., username + password, MFA). Authorisation is the process of determining what you are allowed to do after your identity is confirmed. SailPoint IIQ operates primarily in the authorisation space — it manages which users have which entitlements and enforces that those entitlements are appropriate, current, and auditable.

An Identity Cube is SailPoint IIQ's core data model for a user's identity. It aggregates everything IIQ knows about a person: their HR attributes (name, department, manager, title), all their accounts across connected applications, and all the entitlements held on those accounts. Think of it as a 360° view of a user's digital identity and access footprint. The term "cube" reflects the multi-dimensional nature of the data — one person, multiple applications, multiple entitlements, multiple risk factors. Identity Cubes are refreshed through Aggregation Jobs and Refresh Jobs.

A Connector is the integration bridge between SailPoint IIQ and a target application or system. Connectors enable IIQ to read account data from (aggregation) and write provisioning actions to (provisioning) systems like Active Directory, LDAP, SAP, Salesforce, ServiceNow, and databases. SailPoint ships with a large library of native connectors. For applications without a native connector, custom Datafile Connectors (flat file-based) or Direct Connect connectors are used. Module 3 of the IIQ curriculum covers Application Onboarding with multiple connector types in depth.

Aggregation is the process by which SailPoint IIQ reads and imports account and entitlement data from a connected application into the Identity Cube. During aggregation, IIQ scans the target system, pulls all account records and their entitlements, correlates them with existing IIQ identities, and updates the Identity Cube accordingly. Aggregation is triggered through an Aggregation Job (Module 4). Full aggregation imports all data; delta aggregation imports only changes since the last run — useful for large systems where full scans are time-consuming.

RBAC is a model where access rights are grouped into roles, and users are assigned roles based on their job function rather than having entitlements assigned individually. In SailPoint IIQ, there are two types of roles: Business Roles (aligned to job functions — "Finance Analyst", "IT Support Engineer") and IT Roles (bundles of technical entitlements — specific AD groups, application accounts). Business Roles contain IT Roles. When a user is assigned a Business Role, IIQ automatically provisions the underlying IT Role entitlements via provisioning plans. This is covered in Module 7 of the curriculum.

IdentityIQ (IIQ) is an on-premise or private-cloud platform — highly customisable, suitable for complex enterprise deployments, dominant in India's BFSI GCCs and IT services sector. IdentityNow (now branded Identity Security Cloud / ISC) is SailPoint's SaaS offering — configuration-based with limited deep customisation, preferred for cloud-native greenfield deployments. For Indian IT professionals in 2026, IIQ has a significantly larger active job market. See our SailPoint online training guide for a full IIQ vs IdentityNow comparison.

An Entitlement is a specific permission or access right that a user holds on a connected application or system. Examples: membership in an Active Directory group, a specific role in SAP, a permission set in Salesforce. IIQ aggregates all entitlements for every user across every connected application and stores them in the Identity Cube. Entitlements are the granular unit of access that is reviewed during Access Certification campaigns and managed during provisioning and deprovisioning workflows.

Provisioning is the process of creating, modifying, or granting access — for example, creating an Active Directory account and assigning the correct AD groups when a new employee joins (Joiner lifecycle event). Deprovisioning is the reverse: removing or disabling access when it is no longer appropriate — such as disabling accounts when an employee leaves (Leaver event). SailPoint IIQ automates both via Lifecycle Events (Module 12) and Provisioning Rules. Timely deprovisioning is critical for compliance — orphaned accounts with active access after an employee leaves are a major audit finding.

Application onboarding is the process of connecting a new system to SailPoint IIQ so it can be governed. The steps are: (1) Create the Application object in IIQ with the correct connector type (LDAP, JDBC, Flat File, etc.); (2) Configure connection details — host, credentials, schema definition; (3) Define the schema — which attributes to pull from the system (accounts, groups, entitlements); (4) Set up Identity Mapping — how IIQ correlates application accounts to existing IIQ identities (typically by employee ID or email); (5) Run a test aggregation — verify accounts are imported correctly; (6) Set up provisioning — configure how IIQ will write changes back (create, modify, delete accounts); (7) Validate and schedule the Aggregation Job. This is covered in Module 3 of SailPoint Academy's IIQ curriculum.

Both are SailPoint Job types (Module 4) but serve different purposes. An Aggregation Job reads data from a connected application and pulls account/entitlement records into IIQ — it updates the data coming in from the target system. A Refresh Job recalculates Identity Cubes using the data already in IIQ — it re-evaluates role assignments, risk scores, and policy violations without contacting the connected application again. In practice, both are run on schedules: Aggregation Jobs run more frequently for critical systems, Refresh Jobs consolidate the data already aggregated.

Lifecycle Events are triggers in SailPoint IIQ that fire when a predefined identity event occurs, automatically initiating provisioning or deprovisioning workflows. The four core ones (Module 12) are: Joiner — fires when a new user is added to the identity warehouse (new employee joins); triggers account creation and role assignment. Leaver — fires when a user's active status changes to inactive or terminated; triggers account disablement and deprovisioning. Mover — fires when a user's role, department, or location changes; triggers entitlement adjustment (remove old-role access, grant new-role access). Rehire — fires when a former employee returns to the organisation; triggers account re-enablement with appropriate access. These are configured as workflow-based triggers tied to attribute changes detected during Identity Refresh.

Access Certification (Module 11) is the periodic review process where stakeholders confirm or revoke user access. IIQ supports six certification types: Manager Certification — a manager reviews and certifies the access of their direct reports. Entitlement Certification — the owner of an entitlement (e.g., AD group owner) reviews all users holding it. Role Certification — a role owner reviews users assigned a specific role. App Owner Certification — an application owner reviews all accounts on their application. Advanced Certification — a highly flexible, rule-driven certification targeting any subset of users and entitlements. Event-based Certification — triggered automatically by an event (e.g., a Mover event triggers a certication of new-role entitlements). Each type produces a certification campaign that reviewers complete within a defined window.

An SOD policy (Module 8) prevents a single user from holding two entitlements or roles that would create a conflict of interest — for example, the ability to both raise and approve a purchase order, or both administer and audit a system. In SailPoint IIQ, SOD policies are defined as Policy objects that specify two conflicting entitlement sets. When a user holds both, IIQ flags a Policy Violation. Violations can trigger: automated notifications to the user's manager; remediation workflows; or escalation to a compliance team. SOD policies are central to SOX and DPDP Act compliance in Indian BFSI enterprises.

Module 7 distinguishes these clearly. A Business Role maps to a job function in the organisation — "Finance Analyst", "Network Engineer", "HR Business Partner". It is defined in business terms and assigned by HR or managers. A Business Role contains IT Roles. An IT Role is a bundle of technical entitlements — specific AD groups, database permissions, application accounts. When IIQ assigns a user to a Business Role, it automatically provisions all the IT Roles (and their entitlements) contained within it. This separation exists so business stakeholders can manage access using role names they understand, while the underlying IT provisioning is handled automatically by IIQ.

Module 10 covers this. A Population is a dynamic, rule-based grouping of identities — for example, "all identities in the Finance department in Hyderabad". Populations are built using filter rules and automatically include any identity matching the criteria. They are used in Access Certifications, Lifecycle Event scoping, and reporting. A Workgroup is a static, manually managed group of IIQ users (typically administrators or reviewers) used to assign IIQ system capabilities and certification responsibilities. The key difference: Populations are dynamic and identify end-user identities; Workgroups are static and manage IIQ system access for administrators and certifiers.

Application Rules (Module 6) are BeanShell scripts that customise how SailPoint IIQ interacts with a specific application. The key rule types are: Aggregation Rule — executed during aggregation to transform or enrich incoming account data. Provisioning Rule — executed when IIQ sends a provisioning action to a target application; customises how accounts are created, modified, or deleted. Connector Rule — specific to a connector's behaviour, for handling special connector scenarios. Schema Rule — customises how account attributes are mapped from the application's schema to IIQ's object model. Rules are written in BeanShell (a Java-like scripting language) and are one of the most technically tested topics for developer roles.

Role mining is the process of analysing existing user access data to identify patterns and suggest optimal role definitions — rather than manually designing roles from scratch. SailPoint IIQ supports two approaches: Bottom-Up role mining analyses the entitlements users already hold across connected applications and uses pattern-matching algorithms to identify common entitlement combinations that could be formalised into IT Roles. Top-Down role mining starts from the organisational structure — job titles, departments, or business units — and builds roles from the expected access model downward. In Indian enterprise IIQ deployments, role mining is most commonly done during initial IIQ implementation or during periodic role rationalisation projects when the role model has grown too complex. Module 7 of SailPoint Academy's curriculum covers role design and RBAC in depth.

Managed accounts are accounts on connected applications that IIQ has either provisioned itself or successfully correlated to an existing IIQ identity during aggregation. IIQ can govern, certify, and provision/deprovision managed accounts. Unmanaged or orphaned accounts exist on a connected application but could not be correlated to any identity in the identity warehouse — typically because the account belongs to a former employee whose identity has been removed, or because the correlation attribute (e.g., employee ID) is missing or inconsistent. IIQ detects orphaned accounts during aggregation and reports them. Handling options: (1) manual remediation — an admin disables or deletes the account; (2) configuring a correlation rule to match on a secondary attribute; (3) marking the account as non-authoritative. Orphaned accounts are a major audit finding under RBI guidelines and SOX compliance — interviewers at BFSI GCCs frequently ask scenario questions about them.

The standard approach is to use a Datafile Connector (flat file integration). You work with the application team to schedule an automated data extract (CSV/delimited file) containing account records and entitlements. IIQ reads this file via the Datafile Connector during aggregation. For provisioning back, you configure a provisioning integration that generates a provisioning request file, which the application team's automation picks up and processes. If the application has an API, a REST Connector or custom connector using IIQ's connector SDK is a better long-term solution. Always document the connector type, data refresh frequency, and provisioning latency in the integration design document.

(1) Define the trigger condition — typically the identity attribute that signals a new joiner (e.g., activeStatus changes to Active, or a new identity appears in the authoritative source aggregation). (2) Create the Lifecycle Event object in IIQ — set the trigger type (Identity Change or Role Assignment), the triggering attribute and value. (3) Configure the associated workflow — for a Joiner, this is typically SailPoint's built-in LCM Provisioning workflow or a customised version. The workflow evaluates the identity's Business Role assignments and generates a Provisioning Plan for all required accounts and entitlements. (4) Configure approvals — decide whether auto-provisioning or manager approval is required. (5) Test — trigger the event manually using a test identity and validate accounts are created with the correct entitlements in connected systems. (6) Schedule — ensure the Refresh Job that evaluates Lifecycle Event triggers runs on the correct schedule.

A Provisioning Plan is the structured representation of all the changes IIQ intends to make for an identity across connected applications — it lists every account to create, modify, or delete, and every entitlement to add or remove. It is the "what needs to happen" specification. A Provisioning Transaction is the execution record of an individual provisioning action against a single application — it captures what was attempted, the result (success/failure), retry attempts, and error messages. One Provisioning Plan may result in multiple Provisioning Transactions (one per application involved). In troubleshooting, you inspect Provisioning Transactions to understand why a provisioning action failed for a specific application.

Risk Scoring (Module 9) assigns a numerical risk score to each identity based on the sensitivity of the entitlements they hold. IIQ calculates a composite risk score from: (1) Entitlement risk weights — each entitlement is assigned a risk value (e.g., Admin access = high, Read-only = low) by the application owner. (2) Policy violations — active SOD violations significantly increase risk score. (3) Certification status — uncertified or overdue entitlements can increase risk. (4) Dormant accounts — accounts not used within a defined period. The composite risk score feeds governance reporting and can be used to prioritise certification campaigns (certify high-risk identities first). Risk Score configuration defines weight formulas and thresholds for High, Medium, and Low risk bands.

Direct provisioning means IIQ connects to the target application's connector and performs the account/entitlement change itself in real time — no human intervention. This is the preferred method for applications with fully supported connectors where IIQ has write-back capability (e.g., Active Directory, LDAP). Managed/Service Desk integration is used when IIQ cannot directly write to a target system — for example, legacy applications, heavily controlled production systems, or applications requiring manual approval by an external team. In this model, IIQ raises a provisioning request as a ticket in a service desk (ServiceNow, Remedy) with the required change details. A human or automation on the service desk side executes the change and closes the ticket. IIQ then checks the ticket status and updates the identity state on completion. The trade-off: direct is faster and more automated; service desk integration is safer for critical or complex systems.

This is one of the most common scenario questions at mid-to-senior level interviews. The debugging sequence: (1) Check Task Results in IIQ (Admin → Tasks) — the Task Result object logs the exact failure point, error message, and number of accounts processed before the failure. (2) Review iiq.log — for the IIQ server log, configured via Log4j in Module 5 (log4j2.properties or the Logging Configuration page). Filter by the application name or connector class. (3) Test the connection in the Application Configuration page — confirms if the connector can still reach the target system. (4) Check iiq.properties — connection pool settings, timeouts, and max retry counts may need adjustment. (5) If a schema issue: re-inspect the schema definition and attribute mappings for the failing account type. (6) Consider delta aggregation as a temporary workaround if the full aggregation consistently times out on large systems. Knowing the log4j location and iiq.properties path is a common quick-fire question — Module 5 covers both.

SailPoint IIQ integrates with ServiceNow in two primary modes: (1) Ticketing Integration (Service Desk provisioning) — when IIQ cannot directly provision to a target application (e.g., a legacy system with no connector write capability), it raises a provisioning request as a ServiceNow incident or change request. A ServiceNow agent or automation fulfils the change manually and closes the ticket. IIQ polls the ticket status and updates the identity record when the ticket is resolved. (2) Work Item Integration — IIQ approval work items are surfaced in ServiceNow so approvers can approve or reject access requests from within their familiar ITSM interface, without logging into IIQ directly. ServiceNow integration is very common in India's BFSI GCCs and large IT services firms where ServiceNow is the standard ITSM platform — expect this question if the job description mentions ServiceNow.

HR systems are configured as Authoritative Applications in IIQ — they are the system of record for identity attributes. Connection options: (1) Native connectors — SailPoint ships dedicated Workday and SAP SuccessFactors connectors. (2) Flat file / SCIM feeds — if no native connector is available, the HR system exports employee records as CSV/flat files on a schedule, and IIQ aggregates via the Datafile Connector. During aggregation, IIQ reads employee attributes (hire date, department, manager, employment status, title) and populates Identity Cubes. When an employee's status changes in Workday — termination, transfer, hire — the next aggregation run detects the attribute change and fires the corresponding Lifecycle Event (Leaver, Mover, or Joiner). The reliability of Lifecycle Event automation is therefore directly dependent on the quality and frequency of HR system aggregation. This is a critical point that interviewers at HR-heavy enterprises (BFSI GCCs with large headcount) test specifically.

Identity Mapping is the configuration that tells IIQ how to correlate an account on a connected application to an existing identity in the identity warehouse. For example: map the application account's employeeID attribute to the IIQ identity's employeeID attribute. Without accurate Identity Mapping, IIQ cannot link accounts to the correct identities — which leads to unlinked accounts, incorrect certification assignments, and failed provisioning. This is one of the most critical and error-prone steps in onboarding. If the correlation attribute is inconsistent in the source data (e.g., employee IDs with different formatting), you need an Aggregation Rule to normalise the data before correlation is attempted.

An Authoritative Application is the system of record for identity attributes — typically an HR system (Workday, SAP HR) or an LDAP directory. When IIQ aggregates from an Authoritative Application, it creates new identities and updates the primary identity attributes (name, department, manager, title, employment status). A Non-Authoritative Application is any other connected system — it provides additional accounts and entitlements for existing identities but cannot create new ones or override authoritative attributes. The distinction matters because if you mark the wrong application as Authoritative, IIQ may create duplicate or incorrect identities.

When a reviewer selects Revoke for an entitlement in a certification campaign, IIQ generates a Remediation Request for that entitlement. Depending on the certification configuration, this either: (1) triggers an automatic provisioning plan to remove the entitlement from the application connector directly, or (2) routes to a remediation workflow where an administrator or provisioner approves and executes the removal. After the certification campaign is signed off, IIQ tracks the completion status of all remediation actions. If remediation is not completed within the configured window, IIQ can escalate. Revocations are logged as audit evidence for compliance reporting.

A Custom Workflow (Module 13) is a BeanShell-based process definition that orchestrates a multi-step identity governance action in IIQ. You build custom workflows when SailPoint's built-in workflows do not cover your specific business requirement — for example: a multi-tier approval process where a manager, a security officer, and an IT admin must all approve an access request; or a Joiner workflow that sends a welcome email, creates accounts in three specific systems in a defined sequence, and triggers a Slack notification when complete. Workflows contain Steps, Variables, Approvals, and Work Items. They are one of the most valued skills in senior IIQ Developer interviews.

BeanShell is a lightweight Java-based scripting language used throughout SailPoint IIQ to add dynamic logic wherever configuration alone is insufficient. It is used in: Rules (Aggregation Rules, Provisioning Rules, Connector Rules, Schema Rules), Custom Workflows (step logic, variable assignment, conditional branching), and Lifecycle Event conditions. BeanShell code has direct access to IIQ's Java API, meaning you can query the identity warehouse, execute provisioning actions, send emails, and interact with any IIQ object programmatically. For developer roles, interviewers often ask you to explain or write a simple BeanShell rule on the spot.