Free Practice Questions for SailPoint IdentityIQ-Engineer Exam

No. Setting the length of an IdentityIQ extended String attribute to 9000 is not a supported general mechanism for storing an identity image. The length value in IdentityExtended.hbm.xml influences how Hibernate maps the String property to a database column. It therefore has database-specific consequences and must not be treated as an arbitrary storage-capacity control.

The standard IdentityIQ extended-attribute configuration uses String properties with much smaller lengths—for example, length= " 450 " —specifically so the resulting columns remain suitable for searching and indexing. SailPoint ' s own configuration commentary warns that database platforms have different VARCHAR limitations and that sufficiently large String definitions may cause Hibernate to map the value to a LOB/blob-like type that cannot be used in the same way for searches.

An image is binary content and should not be modeled merely by making an extended searchable String column extremely large. Even an encoded image can exceed practical database/index limits and introduces unnecessary Identity Cube and persistence overhead.

Therefore, length= " 9000 " is not a prescribed IdentityIQ image-storage configuration.

References/topics: IdentityIQ Engineer — IdentityExtended.hbm.xml, extended properties, Hibernate mappings, VARCHAR limits, searchable attributes, database schema design.

=======

Yes. IdentityIQ uses message-catalog properties to supply a large amount of user-interface text rather than hard-coding every label directly into individual pages. In traditional IdentityIQ deployments, the iiqMessages resource files contain message keys and their displayed text. Changing or overriding the relevant message key is therefore a standard mechanism for customizing labels, prompts, descriptions, placeholders, and other localized UI strings.

A safer customization pattern is generally to place customer-specific overrides into the appropriate custom message properties file rather than directly altering the SailPoint-delivered base resource, because base files can be replaced during an upgrade. This also supports internationalization because locale-specific message catalogs can provide different values for the same key.

For example, IdentityIQ certification screens, access-request pages, login-related messages, and general interface labels frequently resolve displayed strings through message keys. SailPoint ' s internationalization and templating mechanisms likewise retrieve translated values from message catalogs.

Therefore, the statement that iiQMessages files can be used to change text labels is valid.

References/topics: IdentityIQ Engineer — message catalogs, iiqMessages.properties, iiqCustom.properties, localization, UI labels and branding.

=======

Yes. In the IdentityIQ branding guidance relevant to this certification material, retaining the SailPoint copyright notice is identified as a minimum SailPoint branding requirement . Customers can make substantial user-interface customizations—such as modifying logos, CSS styling, message text, colors, and selected page elements—but the supported branding guidance does not mean all SailPoint product identification may simply be removed.

The copyright notice is treated separately from cosmetic branding elements. The established IdentityIQ branding convention requires the copyright notice to remain in the page HTML and to be displayed throughout the IdentityIQ interface. A related requirement applies when the SailPoint name or logo is removed from the header: product attribution such as “Powered by SailPoint IdentityIQ” must be retained in the copyright footer. The existing question bank also contains that separate product-attribution proposition and marks it as valid.

Accordingly, customization is permitted, but the stated minimum copyright attribution requirement remains valid.

References/topics: IdentityIQ Engineer — UI customization, minimum SailPoint branding requirements, copyright footer, SailPoint product attribution, upgrade-safe branding.

=======

Correct order:

Update the corresponding hibernate file with the new attributes.

Run the command to generate the script to update the IdentityIQ database.

Shut down the application server and then run the generated extendedSchema script on the IdentityIQ database.

Start the application server and update the corresponding ObjectConfig.

These are the exact four minimum steps given in the IdentityIQ Engineer source.

Yes. Account Groups are commonly used to represent entitlement-bearing group or application objects from a target system. SailPoint documentation uses the terms account group and application object closely, and many applications model access through membership in groups. During aggregation, an account may contain an entitlement attribute such as groups, memberOf, roles, or another group-membership attribute.

When the application also defines a group schema, IdentityIQ can aggregate the group objects themselves. The account schema ' s entitlement attribute is linked to the group schema by setting its type to the applicable native object type—commonly group. IdentityIQ can then associate the entitlement values found on accounts with the corresponding group objects.

These group values can become ManagedAttribute objects and appear in the Entitlement Catalog, where IdentityIQ can attach governance information such as owner, description, requestability, and certification metadata. This allows the target-system group to function as a governed entitlement.

Therefore, representing a particular group-based entitlement associated with accounts on a target system is an appropriate Account Group use case.

References/topics: IdentityIQ Engineer — Account Groups, Application Objects, group schemas, ManagedAttribute, Entitlement Catalog, account entitlements.

=======

Yes, " Business Role " is a default role type available in SailPoint IdentityIQ that a manager can request during the access request process. Business Roles typically represent a collection of entitlements or access rights that align with specific job functions or responsibilities within an organization. Managers can use this role type to extend or modify the access granted to an employee.

SailPoint IdentityIQ Role Management Guide

SailPoint IdentityIQ Administration Guide (Sections on Role Types and Access Request)

Yes. Rapid Setup application onboarding can be used for common onboarding configuration, including account classification logic such as identifying service accounts based on an account attribute and value. Service accounts often need to be distinguished from normal human accounts because they may have different ownership, certification, correlation, requestability, password, and governance treatment. A typical configuration uses an account schema attribute and a value or pattern to flag accounts that should be treated as service accounts. This fits Rapid Setup’s purpose: allowing engineers to configure standard onboarding behavior without writing custom connector logic for every common case. The capability is still limited compared with full custom rules or advanced application configuration. If the service-account identification logic requires complex multi-attribute conditions, external lookups, or custom transformations, a rule or deeper application configuration may be needed. But the proposed action itself is a valid Rapid Setup onboarding configuration. References/topics: IdentityIQ Engineer — Rapid Setup, application onboarding, account classification, service accounts, account attribute filters.

This proposed solution is incorrect. A create-type lifecycle event trigger is used when a new identity is created or first detected in IdentityIQ. The requirement is not about a new identity; it is about an existing identity whose Division attribute changes from IT to Senior IT. That is an update or attribute-change scenario. A create event would not reliably fire when an existing user’s Division attribute is modified during aggregation or identity refresh. It also does not address the second required condition: the user must be a manager. The correct approach must detect the specific attribute transition and then evaluate the manager condition. Using a create trigger would either never launch the workflow for the intended case or launch it only at identity creation time, which is outside the stated requirement. This is a basic but important lifecycle-event design distinction: joiner/create events are not substitutes for mover or attribute-change events. References/topics: IdentityIQ Engineer — lifecycle events, create triggers, attribute-change triggers, mover events, identity refresh processing.

Yes. IdentityIQ provides audit configuration capabilities through the user interface so administrators can manage much of the platform’s audit behavior without directly editing XML for every standard case. Audit configuration is used to control which events or actions are captured, allowing organizations to record relevant administrative, governance, provisioning, workflow, and compliance activity. This is important because excessive auditing can create unnecessary database volume and noise, while insufficient auditing can leave gaps in troubleshooting and compliance evidence. For standard audit controls, the Audit Configuration page is the normal administrative place to manage audit behavior. However, this does not mean every custom audit requirement can be completed only through the UI. Custom audit actions, custom reports, or custom rule/workflow audit writes may still require XML or BeanShell work. The statement says the majority of auditing is managed through the UI page, which is valid for standard IdentityIQ auditing operations. References/topics: IdentityIQ Engineer — Audit Configuration, audit events, audit actions, compliance evidence, custom audit extension.

No. IdentityIQ certifications are used to review and attest access, roles, entitlements, account group memberships, policy violations, or other governance items. They are not designed to ensure “SailPoint” itself is compliant with ISO 9001, and ISO 9001 is not a government regulation in the way the proposed solution states. ISO 9001 is a quality management standard, not an access-governance regulation that IdentityIQ certifications directly enforce. An organization may use IdentityIQ certification evidence as part of broader compliance programs, but the certification’s direct purpose is access review: confirming that users have appropriate access and that inappropriate access is revoked, remediated, or justified. The wording is wrong both in target and scope. The certification process supports customer governance/compliance objectives, not SailPoint corporate ISO compliance. References/topics: IdentityIQ Engineer — certification purpose, access review, compliance evidence, entitlement review, role review, governance controls.