Study guide
2.1 IdentityIQ Infrastructure Components
SailPoint Certified IdentityIQ Engineer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: The IdentityIQ Engineer Exam
1.1 Exam Format, Official Blueprint, and Study Strategy
2 Chapter 2: Infrastructure, Installation, and Extended Attributes
2.1 IdentityIQ Infrastructure Components 2.2 Installation Steps and Procedures 2.3 Creating Extended Attributes and the Objects That Support Them
3 Chapter 3: Build, Deployment, Patching, Access, and Email
3.1 Ongoing Build and Deployment 3.2 Installing Patches and Performing Upgrades 3.3 Configuring End-User Access 3.4 Email Server Settings and Email Redirection
4 Chapter 4: Lifecycle Manager Configuration, Provisioning Policies, and Workflows
4.1 Configuring Lifecycle Manager 4.2 Identity Provisioning Policies 4.3 Configuring LCM Workflows
5 Chapter 5: Lifecycle Events, QuickLinks, Batch Requests, and Rapid Setup
5.1 Lifecycle Events and Their Workflows 5.2 QuickLinks and QuickLink Populations 5.3 Configuring and Using Batch Requests 5.4 Rapid Setup in Lifecycle Events and Identity Operations
6 Chapter 6: Certification Campaigns and Certification Rules
6.1 Configuring and Scheduling Certification Campaigns 6.2 The Purpose of Common Certification Rules
7 Chapter 7: Policies and Policy Violations
7.1 Configuring and Leveraging Policies 7.2 Responding to Policy Violations
8 Chapter 8: Reporting, Advanced Analytics, and Auditing
8.1 Executing and Leveraging Reports 8.2 Leveraging Advanced Analytics 8.3 Configuring and Using Auditing
9 Chapter 9: Rules, Rule Libraries, and the SailPoint API
9.1 The Purpose and Use of Rule Libraries 9.2 Rule Input and Output Arguments 9.3 Common SailPoint API Objects and Methods
10 Chapter 10: Workflow Development
10.1 Workflow Variables, Transitions, and Step Conditions 10.2 Workflow Steps That Generate Work Items 10.3 The Different Workflow Step Usages 10.4 Leveraging Sub-Workflows
11 Chapter 11: Email Templates, Branding, and Localization
11.1 Customizing and Using Email Templates 11.2 Branding the SailPoint User Interface 11.3 Localizing the SailPoint UI
12 Chapter 12: Application Definitions, Connector Settings, and Rapid Setup Aggregation
12.1 Configuring Application Definitions 12.2 Configuring Common Connector Settings 12.3 Configuring Rapid Setup Aggregation Settings
13 Chapter 13: Data-Loading Tasks and Application and Connector Rules
13.1 Scheduling Tasks for Data Loading and Processing 13.2 Common Application Rule Types 13.3 Common Connector Rule Types
14 Chapter 14: Debugging with log4j, Syslog, and the IdentityIQ Console
14.1 Configuring and Leveraging log4j 14.2 Configuring and Leveraging Syslog 14.3 Leveraging the IdentityIQ Console for Debugging
15 Chapter 15: Debug Pages and the Administrator Console
15.1 Leveraging the Debug Pages for Debugging 15.2 Leveraging the Administrator Console for Debugging
16 Chapter 16: Role Model and Identity Attribute Mappings
16.1 Default Role Models and Role Types 16.2 Configuring Roles and Role Options 16.3 Configuring Identity Attribute Mappings
17 Chapter 17: Data Objects, Relationships, and Group Types
17.1 Common IdentityIQ Data Objects 17.2 Relationships Between Common Data Object Models 17.3 The Difference Between Group Types
2.1 IdentityIQ Infrastructure Components
Key Takeaways Explain This Topic AI
IdentityIQ is a Java web application (identityiq.war) deployed on a supported application server; Apache Tomcat is the most common choice.
The install scripts create separate databases for IdentityIQ data, plugins (identityiqPlugin), and, from 8.4, Access History, which is required even when the feature is unused.
The IQService is a native Windows service that IdentityIQ needs to provision Active Directory, including password changes.
Every IdentityIQ instance keeps a Server object with a heartbeat; multiple instances on one machine need unique iiq.hostname values.
Hosts can be specialized by turning services such as Task and Request on or off and by listing hosts in RequestDefinition objects and task definitions.
Last updated: September 2026
IdentityIQ Infrastructure Components
Blueprint objective 1.1 asks you to understand the different infrastructure components of IdentityIQ deployments . Expect exam scenarios such as a new customer asking what they must provide, or a failed Active Directory password change traced to a missing Windows component. You need to know what each piece does and where it runs.
The Core Stack
Component What it is Why it matters
Application server A Java EE servlet container that runs the identityiq web application from identityiq.war Hosts the UI, REST endpoints, the task scheduler, and the request processor. Tomcat is the most common choice.
Java runtime (JDK) The Java version supported for the IdentityIQ release The release notes pair each IdentityIQ version with supported JDKs.
Relational database server Holds the IdentityIQ database and its companion databases All object data, task results, work items, and audit events live here.
Browser clients End users, managers, and administrators IdentityIQ is managed through the web UI.
Mail server (SMTP) Outbound email for notifications and work items Configured in Global Settings (see section 3.4).
The application is delivered as a zip containing identityiq.war plus database , doc , and integration folders. You expand the WAR into a directory, commonly called identityiq_home . Its WEB-INF subfolders hold the files engineers use daily:
WEB-INF/bin – the iiq script used for iiq console , iiq schema , iiq keystore , iiq encrypt , iiq upgrade , and iiq patch .
WEB-INF/classes – iiq.properties (database connection settings), the keystore files iiq.dat and iiq.cfg , and the .hbm.xml Hibernate mapping files under sailpoint/object .
WEB-INF/config – XML import files such as init.xml and init-lcm.xml .
WEB-INF/database – the DDL scripts for supported database platforms.
WEB-INF/lib – Java libraries, where you add a JDBC driver or a custom JAR.
The Databases
The database scripts create more than one database :
The IdentityIQ database (default name identityiq ) holds every persistent object.
The plugin database ( identityiqPlugin ) gives installed plugins their own tables. By default, iiq.properties sets plugins.enabled , plugins.runSqlScripts , and plugins.importObjects to true .
The Access History database was added in IdentityIQ 8.4. The documentation says this separate database is required even when Access History is disabled . It may share a database instance, but a separate instance is recommended in production because it keeps growing.
Oracle, Microsoft SQL Server, and MySQL have long been supported. IdentityIQ 8.4 added PostgreSQL. Always confirm the exact versions in the Supported Platforms section of the release notes for your IdentityIQ version, because platform support changes from release to release.
Components Outside the Web Application
IQService – a native Windows service that lets IdentityIQ reach information available only through Win32 APIs. You must install and register an IQService before you can provision to Active Directory , aggregate Terminal Services attributes, read Windows Event Logs, or load local Windows users and groups through the direct connectors. This includes password changes. The Active Directory application stores the IQService host and port, and the IQService version must match the IdentityIQ server version, including patch level.
Connectors – most connectors run inside IdentityIQ itself. Some need an agent near the target system, and IQService is the most tested example.
Message broker – when Data Extract and Access History arrived in 8.4, they used an ActiveMQ broker, embedded or external (the Debug pages have an ActiveMQ Monitoring page). The documentation notes that as of 8.4p2, Access History and Data Extract no longer depend on ActiveMQ .
Load balancer – distributes user sessions across UI hosts in a multi-host installation.
Identity provider – optional SAML or rule-based single sign-on (section 3.3).
Multi-Host Installations
Production installations usually run several IdentityIQ instances against one shared database . The documentation describes the moving parts:
Server objects and heartbeats. Each instance has a Server object. A heartbeat thread updates it regularly. If a host's heartbeat stops advancing, the other hosts mark it as crashed. When several instances run on one machine, each one needs a unique iiq.hostname so that it gets its own Server object.
Services per host. Background services include Task (the Quartz task scheduler), Request (the request processor), Heartbeat , Cache , Monitoring , and Reanimator . The Reanimator resets or terminates tasks that look hung. In the Administrator Console, under Environment > Hosts , you can switch services on or off for each host. A host whose Task service is off still runs requests aimed specifically at it but does not pick up untargeted work. The Request service cannot be fully shut down.
Dedicated hosts. To keep batch processing away from interactive users, disable the Task service on UI hosts. Then put a comma-separated hosts list in a task definition's Host field or in a RequestDefinition object's hosts attribute. With a list, the task runs on the first host that has an active heartbeat.
Partitioning. Account aggregation, account group aggregation, identity refresh, Identity Request Maintenance, Perform Maintenance, manager and targeted certification generation, and role propagation can be split into partitions. The partitions go into a global queue, and hosts compete to run them. If a host fails, its partitions return to the queue. RequestDefinition objects such as Aggregation Partition and Identity Refresh Partition set maxThreads per host. The default is 1.
Loading diagram... Multi-host IdentityIQ topology
Exam Traps
"The heartbeat is a database cluster feature." No. The heartbeat is an IdentityIQ service that updates Server objects. It is not database replication.
"Disabling the Task service stops everything on that host." No. Targeted requests still run. Only untargeted work is no longer picked up.
"IQService is needed for every connector." No. It is needed for Windows-specific work such as Active Directory provisioning and password changes, Windows local accounts, and Event Log collection.
"Access History is optional, so its database is optional." The documentation says the separate database is required even when the feature is not used.