SailPoint IIQ Architect Interview Questions 2026: Design, Migration and Governance Scenarios

The pattern most commonly described in the SailPoint Developer Community is a four-host split: two hosts serving the user interface behind a load balancer with sticky sessions, and two hosts dedicated to batch work — aggregation, refresh and system tasks. The reason is contention. If a full identity refresh runs on the same JVM serving access requests, users experience the refresh as an outage.

Say explicitly that IdentityIQ lets you designate which hosts act as task servers and which act as request servers, and that you would keep that designation in configuration rather than convention so a restart does not silently rebalance work onto a UI host.

Answer in three layers, because that is how it fails. The application layer is handled by multiple hosts behind a load balancer. The database layer is handled by the database platform's own clustering or replication — IdentityIQ inherits whatever the database gives it, which is why architects are expected to have an opinion on recovery point objective. The integration layer is the one candidates forget: IQService, used for Active Directory and Windows provisioning, is a single point of failure unless you deploy multiple instances with a load balancer or a fallback configuration, a question raised repeatedly on the SailPoint Developer Community.

Strong candidates finish by naming the disaster-recovery model — a warm secondary site with database replication and a documented cutover runbook — and admitting its recovery time honestly.

Do not jump to hardware. The expected sequence is: move from full to delta aggregation where the connector supports it, narrow the schema so you are not aggregating attributes nobody governs, partition the aggregation task so it runs in parallel across request servers, then stagger schedules so aggregation and identity refresh are not competing. Only after that does adding a task server make sense.

Add the governance point that separates architects from senior developers: an application that takes fourteen hours to aggregate is usually an application whose entitlement model was never rationalised. Fixing the data is often cheaper than fixing the infrastructure.

Work down a ladder and say so: a supported direct-connect connector first, then a web services or REST connector if the system exposes an API, then the datafile connector with a scheduled extract for read-only governance, and a fully custom connector built on the connector SDK only when the system is both strategic and long-lived.

The architect-level addition is the exit question — who maintains this custom connector when its author leaves, and what happens to it if the estate later moves to Identity Security Cloud. Custom Java is precisely what does not port cleanly.

Describe segregated environments with production-like data volumes in test, IdentityIQ objects exported as XML and held in source control, a deployment pipeline that promotes those artefacts rather than hand-editing production, and a documented rollback. Mention that rules and workflows are code and should be reviewed like code.

If you have ever recovered from an unreviewed rule being deployed straight to production, tell that story. Interviewers weight a real incident far above a described process.

Start with an inventory, not an opinion: classify every artefact in the estate — applications, connectors, rules, workflows, certification campaigns, reports — as migrate, rebuild or retire. Two questions decide the shape of the programme. Does the estate depend on custom BeanShell rules or bespoke Java connectors that will not port cleanly? And does a regulator require identity data to remain in a specific geography?

Say plainly that a meaningful proportion of any long-lived IIQ estate should be retired rather than migrated. An architect who proposes to lift every legacy artefact into the cloud is proposing to pay twice for old decisions.

Much of what a BeanShell rule does in IdentityIQ is expressed as a transform or a configured workflow in Identity Security Cloud, and the mapping is good for attribute manipulation and conditional logic. What does not map cleanly is arbitrary code: rules that call external systems, hold state, or encode business logic that was never documented anywhere else.

If you want the fuller picture before an interview, our guide to SailPoint IIQ to ISC migration skills covers what the dual-platform job descriptions are actually asking for, and SailPoint IIQ rules and BeanShell covers the rule types themselves.

Name the risk first: during coexistence, two systems can both believe they own an account, and conflicting provisioning is the failure mode that reaches the audit committee. The usual answer is to migrate by application domain rather than by user population, to make one platform authoritative for provisioning per application at any moment, and to keep a reconciliation report that proves the two estates agree.

Give a realistic duration. In large enterprises, coexistence runs for months, not weeks, and an architect who promises a weekend cutover for a 200-application estate will not be believed.

The design question underneath is scope, not mechanics. A quarterly manager certification across every entitlement for 40,000 identities produces rubber-stamping, and rubber-stamped reviews fail audits more embarrassingly than missing ones. The defensible answer is risk-tiered: high-risk and privileged entitlements certified quarterly by application owners, everything else on an annual manager certification, with event-based certifications triggered on transfers.

Explain how risk scoring drives that tiering, and how you would measure the programme — completion rate, revocation rate, and time to revoke — because a certification campaign that never revokes anything is evidence that the scope is wrong. Our SailPoint IIQ access certification guide walks through the campaign types in detail.

This is the most reliable architect-level trap, because the wrong answer is to remove one entitlement. The correct answer is a documented, time-bound, approved exception with a compensating control — typically enhanced monitoring or a second-person review of the transactions the conflict enables — recorded in SailPoint IdentityIQ so the auditor sees the decision and its owner, not an unexplained violation.

Add the programme view: a policy generating hundreds of genuine exceptions is a badly written policy, and an architect owns fixing the policy, not just processing the exceptions. Our explainer on SailPoint IIQ policy management and SoD covers the policy types.

Describe the two-layer model — business roles that mirror job functions and are owned by the business, IT roles that bundle entitlements within an application and are owned by the application team — and say that the boundary between them is the thing that has to be governed. Role explosion happens when business roles are created per person rather than per function.

The credible control is a birthright core plus requestable exceptions, a periodic role-mining review, and a named owner for every role. State honestly that no enterprise reaches full role-based access control, and that chasing it is a common way to spend two years producing nothing auditable.

Ask what specifically is insufficient before defending anything — typically it is traceability from a decision back to the reviewer, the timestamp and the resulting revocation. Then show the evidence chain SailPoint IdentityIQ already produces: the certification record, the audit configuration, the provisioning transaction that executed the revocation, and the report that ties them together.

Interviewers are watching your posture as much as your answer. Architects who become defensive with auditors create expensive findings; architects who treat a finding as a specification get it closed.