SailPoint IGA Interview Questions — IdentityNow / ISC Answers & Prep

① Platform & Architecture — IdentityIQ vs Identity Security Cloud

Q: What is SailPoint and what problem does IGA solve?

Model answer: SailPoint is a leading IGA vendor. IGA solves the core compliance challenge: organisations accumulate user access over time through joiners, movers and leavers, and without governance that access drifts until it violates least-privilege or regulatory rules (SOX, HIPAA, GDPR). SailPoint automates the access lifecycle — provisioning the right access on day one, adjusting it as roles change, revoking it on departure, and continuously certifying that what remains is still appropriate — reducing both risk and manual workload.

Q: What is the difference between IdentityIQ and Identity Security Cloud (ISC)?

Model answer: IdentityIQ (IIQ) is SailPoint's on-premises, Java-based platform. Large enterprises choose it for deep customisation, complex workflows written in BeanShell/Java, and full control over their data. It requires infrastructure management and patching. Identity Security Cloud (ISC) — formerly IdentityNow — is the multi-tenant SaaS platform built on microservices, delivered and maintained by SailPoint. ISC gets continuous feature updates, scales automatically, and connects to on-prem systems via a Virtual Appliance (VA) gateway. Most new SailPoint deployments start with ISC; IIQ migrations to ISC are common in 2026.

Q: What is the Virtual Appliance (VA) in ISC and why is it needed?

Model answer: The Virtual Appliance (VA) is a lightweight VM deployed in the customer's network that acts as a secure tunnel between the ISC SaaS platform in the cloud and on-premises sources (Active Directory, LDAP, HR systems, databases). Because ISC is a multi-tenant SaaS product, it cannot reach customer-internal systems directly; the VA bridges that gap without opening inbound firewall ports — it establishes an outbound encrypted connection to ISC. VAs are deployed in clusters for high availability. Sources that are cloud-native (Salesforce, ServiceNow) can use SaaS Connectors that connect directly without a VA.

Q: What are the core modules of the ISC (SailPoint Identity Security Cloud) platform?

Model answer: ISC is built around several modules: Access Lifecycle (joiner-mover-leaver provisioning and de-provisioning), Access Certifications (automated review campaigns), Access Requests (self-service request portal with approval workflows), Separation of Duties (SoD) (policy-based detection of conflicting access), Role Management (business roles and IT entitlements), Password Management (self-service reset and sync), and AI-Driven Insights (Role Discovery, Access Insights, Peer Group analysis, Harbor Pilot AI agent). Together they form a full IGA platform that answers the three questions every auditor asks: who has access, is it appropriate, and how was it granted.

② Lifecycle & Provisioning — joiner-mover-leaver, Sources and plans

Q: Explain the joiner-mover-leaver (JML) lifecycle in SailPoint ISC.

Model answer: The JML lifecycle is the core provisioning engine in ISC. A Joiner event occurs when a new identity appears in the authoritative source (usually an HR system); ISC detects it on the next account aggregation, applies birthright provisioning rules (role assignments based on attributes like department and location) and provisions accounts to the required target systems. A Mover event occurs when attributes change (e.g. department transfer); ISC revokes roles that no longer apply and grants new ones matching the new profile. A Leaver event occurs on termination; ISC triggers de-provisioning — disabling accounts, removing group memberships, revoking entitlements — within the defined SLAs. The whole flow is automated, audit-logged and measurable, replacing manual ticket-based processes.

Q: What is a Source in SailPoint ISC, and what is account aggregation?

Model answer: A Source is ISC's representation of any connected system — Active Directory, an HR platform, Salesforce, a database, or a custom application. Each Source has a connector (the technical integration) and a schema (which attributes to collect). Account Aggregation is the scheduled or on-demand process where ISC reads all accounts and entitlements from a Source into its identity warehouse. Aggregation feeds the identity cube — correlating accounts across sources to build a single identity view per person. Aggregation is the foundation: you cannot govern access you have not first discovered. Entitlement aggregation is a separate step that collects the available entitlements (groups, roles, permissions) from the source so ISC knows what can be granted or revoked.

Q: What is a provisioning plan and how does ISC build and execute one?

Model answer: A Provisioning Plan is the structured object ISC creates when it decides to change access on a target system. It contains account requests (create, modify, delete) and attribute/entitlement requests (add or remove a group, set a value). ISC builds a plan in response to a lifecycle event, an approved access request, or a certification revocation. Before committing, ISC runs the plan through Policy evaluation (SoD checks, pre-provisioning rules) and optionally an approval workflow. The plan is then dispatched to the target source's connector via the Provisioning Broker. If the connector is authoritative-provisioning-capable (direct connect), ISC sends the change and tracks the result; if not, ISC generates a manual work item for a human to execute. Every plan and its outcome is stored in the Provisioning History for audit.

Q: What is the difference between birthright provisioning and request-based provisioning?

Model answer: Birthright provisioning is automatic — access that ISC grants based on identity attributes (department, job code, location) without any request. A new hire in Finance automatically gets the Finance-standard accounts and entitlements defined in the role model. Birthright is managed through Role Assignment Rules or Population-based assignments in ISC. Request-based provisioning is on-demand — a user or manager opens an access request through the ISC portal (or via a Service Catalog integration) for additional access beyond the birthright baseline. Request-based flows always go through an approval workflow and optionally a SoD check before provisioning. The key governance point: birthright gives the minimum needed on day one; request-based handles exceptions and elevated access with full auditability.

③ Certifications, SoD & Roles — campaign types and conflict detection

Q: What is an Access Certification campaign in SailPoint, and what types exist?

Model answer: An Access Certification campaign is a structured review process where designated reviewers — Remediators — examine user access and decide to Approve, Revoke, or Request a change. Campaigns are scheduled (quarterly, annually) or triggered by an event. ISC supports several campaign types: Manager Certification — a manager reviews all access held by their direct reports (the most common type); Entitlement Owner Certification — the owner of a specific entitlement or application reviews everyone who holds it; Role Membership Certification — a role owner reviews all identities assigned to that role; and Source Owner Certification — the owner of a connected source reviews all accounts on it. When a reviewer clicks Revoke, ISC auto-generates a provisioning plan to remove the access on the target system — closing the loop without a manual ticket.

Q: What is a Segregation of Duties (SoD) policy in SailPoint and how does it work?

Model answer: A Segregation of Duties (SoD) policy defines combinations of roles or entitlements that should never coexist on a single identity because together they enable fraud or error — for example, the ability to create a vendor and approve payment. ISC evaluates SoD policies in two contexts: during Access Requests (pre-provisioning — ISC blocks or warns before granting the conflicting access) and during Certifications (ISC flags existing violations so reviewers can remediate). SoD violations can be given a Policy Exception with an approver, business justification and an expiry date, which ISC tracks for audit. The compliance reporting view shows open violations, exceptions and remediation status — exactly what an auditor wants to see.

Q: How does SailPoint handle Role Management and what is the difference between a Business Role and an IT Role (Entitlement)?

Model answer: SailPoint's role model has two layers. IT Roles (also called Entitlement Roles or Provisioning Roles) map directly to a technical entitlement on a source — an AD group, a Salesforce permission set, a database account. They are the atomic grants that connectors actually provision. Business Roles are the business-language construct — a job function like 'Finance Analyst' that bundles one or more IT roles. A Business Role can have Required IT roles (always granted with the business role) and Permitted IT roles (the user may request these additionally). Assignment criteria (department, title, location) on the Business Role drive birthright provisioning. This two-layer model lets business stakeholders own the Business Roles without needing to understand the technical entitlements underneath. Role Discovery — an AI feature — analyses actual access patterns to suggest new business roles based on peer groups who share the same entitlements.

Q: What happens after a reviewer clicks Revoke in a certification campaign?

Model answer: When a reviewer marks an access item as Revoke in a campaign, ISC does not immediately remove access — it marks the decision and waits for the campaign to be signed off (or reaches the deadline). On campaign completion, ISC processes all Revoke decisions by auto-generating provisioning plans for each revoked item and dispatching them through the connector to the target source. If the connector supports direct provisioning, the group or account is removed automatically and the result is logged. If the connector is read-only (manual provisioning), ISC creates a work item assigned to the source administrator to perform the removal, and the campaign's remediation report tracks whether it was actioned. The full decision trail — who reviewed, what they decided, when it was remediated — is stored and reportable for audit.

④ AI, Connectors & Scenarios — intelligent governance and integration types

Q: What AI features does SailPoint Identity Security Cloud provide?

Model answer: SailPoint ISC includes several AI-driven capabilities that move governance from reactive to proactive. Role Discovery analyses the actual access patterns of identities across sources and uses machine learning to suggest new Business Roles based on groups of users who share similar entitlements — reducing the manual effort of role engineering. Access Insights surfaces anomalous access — entitlements held by an identity that are not typical for their peer group — flagging them for review. Peer Group Analysis calculates what access is normal for a given population (same department, title, location) so that outliers stand out during certifications. Harbor Pilot is SailPoint's AI agent that can answer natural-language governance questions, draft certification decisions and summarise access risk. These AI features give reviewers decision support so that certifications become targeted reviews of anomalies rather than rubber-stamp exercises on thousands of entitlements.

Q: What are the connector types in SailPoint ISC and when would you use each?

Model answer: ISC supports several connector patterns. SaaS Connectors (built on the SaaS Connectivity framework) are cloud-hosted, call the target application's REST API directly, and require no Virtual Appliance — ideal for modern SaaS applications like Salesforce, Workday, or GitHub. Direct Connect connectors are SailPoint-built connectors for common enterprise sources (Active Directory, LDAP, SAP) that run through a VA and support both read and provisioning. Custom/Flat-File connectors use CSV or delimited file drops via SFTP for systems with no live API — ISC reads the file, aggregates accounts, and provisions by generating an export file. Web Services connectors wrap a REST or SOAP API using a configuration-driven approach without custom code. The right choice depends on whether the target has a live API, is cloud or on-prem, and whether provisioning (write) capability is needed or read-only aggregation is sufficient.

Q: Walk me through how you would troubleshoot a provisioning failure in SailPoint ISC.

Model answer: Start with the Provisioning History on the identity's profile — it shows every plan, its status (Success, Failed, Pending), and the connector error message. If the plan shows Failed, the error text usually identifies whether the failure is an authentication error (connector credentials expired), a schema mismatch (an attribute required by the target is missing in the plan), a SoD policy block (the plan was rejected pre-provisioning), or an approval workflow issue (the request is stuck waiting for an approver). Check the Activity Log and the VA logs (if a VA-based connector) for the raw connector error. If the VA is suspect, confirm the VA cluster is healthy in Admin ▸ Connections ▸ Virtual Appliance Clusters. The gold troubleshooting sequence: Provisioning History → error detail → VA health → connector test → re-trigger the plan once fixed.

Q: Describe a real governance scenario — how would SailPoint handle a user transferring from Finance to Engineering?

Model answer: When the HR system updates the user's department from Finance to Engineering, ISC detects the attribute change on the next Source Aggregation (or via real-time event from the HRMS connector). ISC evaluates the Role Assignment Criteria: the Finance Business Role no longer matches (department ≠ Finance) and the Engineering Business Role now matches. ISC builds a Mover provisioning plan: revoke all IT roles tied only to Finance (remove Finance AD groups, revoke Financials application access) and grant the IT roles tied to Engineering (add Engineering AD group, grant the engineering-standard tools). The plan goes through the provisioning broker — direct provisioning where connectors support it, work items where they don't. The access certifications scheduled next quarter will reflect the new access profile. Any Finance entitlements that were explicitly requested (not birthright) flag as SoD risks if they now conflict with Engineering roles. The whole flow is automated, with every action in the Provisioning History for the auditor.