IdentityIQ-Engineer Questions Bank

This is not a joiner lifecycle event. The person already existed in the organization and previously had accounts. The scenario says their access was disabled and now needs to be reinstated, which is a rehire or reactivation process. In IdentityIQ, that is fundamentally different from onboarding a brand-new employee. A joiner process generally provisions new access and new accounts for a person who is newly hired or newly introduced to the identity-governance system. A rehire or reinstatement process should evaluate prior access, reactivate appropriate accounts, restore or recalculate roles, and avoid re-enabling access that is no longer valid. The phrase “previous accounts enabled” is the key clue: existing accounts are being reactivated, not newly created. Therefore, this proposed scenario should not be classified as a joiner lifecycle event. References/topics: IdentityIQ Engineer — joiner/mover/leaver model, rehire processing, account reactivation, LCM workflow routing, disabled account enablement.

In SailPoint IdentityIQ, a Workgroup can indeed be used to provide a group of users with specific capabilities. Workgroups are collections of users that can be assigned roles, tasks, and permissions. By associating capabilities with a Workgroup, all members of that Workgroup will inherit the capabilities defined.

This feature is commonly used to manage teams or departments that need to share specific privileges, such as the ability to approve access requests or manage certifications. Configuring capabilities for a Workgroup is a standard practice within IdentityIQ to simplify permission management and ensure consistent access control across the group.

Therefore, the correct answer is A. Yes.

An AfterProvisioning rule in SailPoint IdentityIQ is typically used to execute custom logic after the provisioning process has been completed successfully. However, if provisioning fails, this rule will not be triggered because it is specifically designed for post-successful provisioning activities. To log an error message in the audit record when provisioning fails, a better approach would be to use a provisioning error handler or configure a specific workflow that captures errors and logs them accordingly. The AfterProvisioning rule is not the correct solution for this use case. Refer to the SailPoint IdentityIQ Provisioning and Workflow documentation for appropriate methods of handling provisioning errors and audit logging.

No. Updating the original shipped HTML file is not the general IdentityIQ configuration mechanism for changing UI settings or branding. IdentityIQ exposes different customization mechanisms depending on what the engineer needs to modify. For example, table presentation can be controlled through UIConfig and ColumnConfig, login-page text can be driven through message-catalog keys, and styling or branding can be implemented through supported CSS or branding mechanisms. The existing question bank itself distinguishes these configuration mechanisms: it identifies ColumnConfig for table display and message-catalog keys for login-page text.

The bank also notes that primary and secondary color behavior is associated with custom CSS/branding rather than the IdentityIQ Configuration > Miscellaneous page.

Direct modification of original product HTML/XHTML resources is also poor upgrade practice because shipped web resources can be replaced during patches and version upgrades. Supported configuration objects, message catalogs, CSS customization, or plugin UI mechanisms provide safer and more maintainable extension points.

References/topics: IdentityIQ Engineer — UIConfig, ColumnConfig, message catalogs, CSS, branding, upgrade-safe UI customization.