IdentityIQ-Engineer SailPoint Certified IdentityIQ Engineer Question and Answers

A Post-Iterate Rule in SailPoint IdentityIQ is a type of connector rule that is executed after each account from the source system (e.g., SQL Loader application) has been read during the aggregation process. This rule allows for additional processing or customization of the data after the account has been iterated over. According to SailPoint IdentityIQ documentation, configuring a Post-Iterate Rule enables the execution of logic after each account ' s data has been processed, confirming that the given statement is valid. Refer to the SailPoint IdentityIQ Connector Development Guide for detailed information on rule execution during aggregation.

Yes, the sets of columns displayed in most tables in the IdentityIQ user interface are controlled by entries in the ColumnConfig elements of the UIConfig object. The UIConfig object in IdentityIQ is responsible for defining various aspects of the user interface, including the configuration of columns that are displayed in tables throughout the application. By modifying the ColumnConfig elements within this object, administrators can customize which columns appear in specific tables, including their order, visibility, and labels.

Therefore, the correct answer is A. Yes.

The correct sequence of steps to turn on Certifications logging at the severity log level of trace is as follows:

Edit the file: [IdentityIQ installation] > WEB-INF > classes > log4j.properties.

This step involves accessing the configuration file where logging parameters are managed. The log4j.properties file is crucial for adjusting logging settings such as the log level for specific modules in SailPoint IdentityIQ.

Uncomment the out-of-the-box logger #log4j.logger.sailpoint.api.Certification=info.

This step enables the logger for Certification by removing the comment from the respective line in the log4j.properties file. This makes the logger active for the certification process.

Change the log level to trace and save.

After uncommenting the logger, change the log level from info to trace. The trace level provides the most detailed logging, capturing comprehensive information about the certification process for troubleshooting.

Restart the application server.

Restarting the application server is necessary for the changes in the log4j.properties file to take effect. SailPoint IdentityIQ reads the updated configuration during the startup process.

Comprehensive Detailed Explanation with All IdentityIQ Engineer References

Editing the log4j.properties file is a standard practice in SailPoint IdentityIQ for configuring logging. This file, located in the WEB-INF/classes directory, controls how and what IdentityIQ logs for different components.

Uncommenting the specific logger is needed to ensure that the system is logging the events related to certification. The commented line #log4j.logger.sailpoint.api.Certification=info can be found in the default configuration and needs to be activated for proper logging.

Setting the log level to trace is crucial because trace provides the most detailed logging, which is essential for deep debugging or tracking granular details about the certifications in IdentityIQ.

Restarting the server ensures that the changes to the logging configuration are applied, as the settings in log4j.properties are only read during the startup phase.

SailPoint IdentityIQ Log Management and Troubleshooting Guide (section on adjusting log levels and configurations).

Yes. Policy checking behavior is one of the areas commonly controlled in LCM request workflows through workflow variables or configuration controlling policy evaluation mode. IdentityIQ can evaluate whether a requested access change would violate configured policies before the request is finalized or provisioned. Depending on configuration, the system can present policy violations to the requester, block submission, continue with warnings, or require additional approval/mitigation. The proposed behavior — checking whether an access request would violate policies and letting the requester review before submitting — aligns with interactive policy-checking behavior in LCM. This is an execution behavior of the request workflow, not an application schema setting. The engineer must still ensure policies are configured and enabled, but the workflow/control-variable layer can determine how those checks are applied during request submission. References/topics: IdentityIQ Engineer — LCM workflow control variables, policy checking, request policy violations, interactive policy review, access request governance.

Yes. IdentityIQ’s Lifecycle Manager workflows are built from reusable workflow components and subprocesses. Many standard LCM subprocesses can be called from custom workflows, provided the engineer understands the expected input variables, return variables, and control flags. This is a preferred engineering pattern because it avoids rewriting complex provisioning, approval, identity request, policy-checking, or notification logic from scratch. Input variables can alter behavior such as approval routing, provisioning mode, policy checking, notification behavior, target identity, requester, plan handling, and subprocess execution path. However, reuse requires discipline: the custom workflow must pass the correct variables, preserve expected types, and handle returned values correctly. Blindly calling an LCM subprocess without matching its contract can produce broken approvals or provisioning behavior. The proposed statement is therefore true because standard LCM subprocesses are intentionally reusable when controlled through documented workflow variables. References/topics: IdentityIQ Engineer — LCM workflows, subprocess reuse, workflow input variables, provisioning workflows, custom workflow development.

In SailPoint IdentityIQ, the configuration in IdentityExtended.hbm.xml file as shown in the image indeed outlines the use of extended identity attributes. These attributes (extended1, extended2, etc.) are custom attributes that are appended to the standard identity object model to store additional identity-related data.

According to the official SailPoint IdentityIQ documentation, when defining identity mappings under Global Settings > Identity Attributes, only up to 12 additional attributes can be made searchable within the IdentityIQ system. This limitation is crucial because it directly impacts the efficiency of search operations in large environments, where making too many attributes searchable can significantly slow down performance.

Once you define these 12 searchable attributes, any additional attributes can still be added, but they will not be indexed for search operations. This means that while the data in these attributes can be used in workflows, reports, and other operations, they cannot be used in search filters in the IdentityIQ user interface.

This limitation is particularly important when planning the design of the identity schema, as it affects both performance and usability. Therefore, the statement in question is correct and accurately reflects the constraints imposed by SailPoint IdentityIQ in terms of searchable identity attributes.

The statement is false. In SailPoint IdentityIQ, there is no strict limitation on nesting sub-workflows (subprocesses) up to 3 levels. You can nest sub-workflows as deeply as required by your business logic and system design. However, it is advisable to manage the complexity of nested workflows to ensure maintainability and performance, but there is no enforced limit of 3 levels for nesting.

SailPoint IdentityIQ Workflow Guide

SailPoint IdentityIQ Administration Guide (Sections on Workflow Design Best Practices)

The statement is incorrect. The " For Others " option in the quicklink configuration is used to allow users to perform actions on behalf of other identities (e.g., a manager performing an action for a subordinate). However, setting the quicklink to " For Others " does not make it launch a workflow immediately. To have a quicklink launch a workflow immediately when clicked, you would typically need to configure the quicklink to call the workflow directly, without requiring additional user input. " For Others " is more about the context of the action rather than triggering workflows automatically.

SailPoint IdentityIQ Quicklink Development Guide

SailPoint IdentityIQ Administration Guide (Quicklink and Workflow Configuration)

Certifying user expense reports is not a purpose of IdentityIQ certification. IdentityIQ certifications are focused on access and identity governance, specifically reviewing and validating user access rights within systems. Expense report certification would be a different process, typically managed by financial or expense management systems, not by IdentityIQ.

SailPoint IdentityIQ Certification Guide

SailPoint IdentityIQ Governance Overview

Syslog is primarily used for logging system events and not for performing complex searches or queries on hierarchical or organizational data like identifying the number of employees that report to a specific person. Such a query would typically require access to the organizational hierarchy or identity data, which is better achieved through IdentityIQ’s reporting or search capabilities within the application rather than using Syslog. Syslog captures log events related to system operations, errors, and other activity logs but isn ' t designed for the type of structured query described in the question.

SailPoint IdentityIQ Logging and Monitoring Guide

SailPoint IdentityIQ Administration Guide (Sections on Reporting and Search)

The " Total Memory " value displayed on the JVM Memory page indicates the amount of memory currently allocated to the JVM heap. In the image provided, the " Total Memory " is shown as 725.617 MB. This is the amount of memory that the JVM heap is currently using, meaning it has been allocated and is available for the JVM to use.

SailPoint IdentityIQ Performance Tuning and Monitoring Guide

SailPoint IdentityIQ Administration Guide (JVM and Memory Management Sections)

Not all Application objects in SailPoint IdentityIQ must have an Identity object as the owner. While it is common practice to assign an owner to an Application object for governance and administration purposes, it is not a strict requirement. Applications can exist without a direct association to an Identity object. The ownership concept in IdentityIQ is more of a best practice for accountability rather than a mandatory attribute. Refer to the SailPoint IdentityIQ Application Definition Guide for more information on the configuration and management of Application objects.

The proposed solution suggests changing the Email Notification Type to " Redirect to file using FTP protocol " under Global Settings > Configure IdentityIQ Settings > Mail Settings. However, IdentityIQ does not provide an option to redirect emails to a file using the FTP protocol directly through the Global Settings in the application.

Typically, to test generated emails in a non-production environment, you would change the Email Notification Type to " Redirect to File " (if the option is available) or configure an SMTP server with a different setup that captures emails in a file or a specific mailbox designed for testing purposes. The specific steps for testing email generation may vary, but the solution as stated does not align with standard IdentityIQ practices.

Thus, the correct answer is B. No.

Yes. If a user already has an account on an application and needs the ability to request an additional/new account through Manage User Access, the relevant LCM/QuickLink configuration must permit requesting new accounts. The proposed setting, “Allow requesting new accounts,” is specifically aligned with that requirement. Manage User Access and Manage Accounts behavior is controlled through Lifecycle Manager quicklink and population configuration, which determines what actions are visible and available to eligible users. Without enabling new-account requests for the appropriate QuickLink population, the user may only be able to manage existing account access or request entitlements for current accounts, not initiate a new account request on that application. This setting must also align with the application’s provisioning support and account creation policy. The configuration grants the UI/request capability; successful fulfillment still depends on application schema, create policy, approvals, and provisioning workflow. References/topics: IdentityIQ Engineer — LCM, Manage User Access, Manage Accounts QuickLink, QuickLink population, new account request, provisioning policy.

Yes, this is a valid action. When using the Services Standard Build (SSB) in SailPoint IdentityIQ, placing the patch jar file in the build ' s base/patch folder is a correct procedure, provided the patch version matches what the client is using. This allows the build process to incorporate the patch into the deployment, ensuring that the correct versions and fixes are applied to the IdentityIQ instance.

SailPoint IdentityIQ Services Standard Build Guide

SailPoint IdentityIQ Patching and Version Management Guide

No. Custom branding changes should not be assumed to update automatically during an IdentityIQ upgrade. Branding changes often involve customized UI resources, message files, images, CSS, JSPs, configuration entries, or other web-application artifacts. During an upgrade, the standard IdentityIQ application files are replaced or changed, and customizations may need to be re-applied, merged, retested, or adjusted to align with the new release. Assuming the upgrade process automatically updates every custom branding change is a bad implementation practice. Engineers should inventory all customizations before upgrade, compare them against the new release, reapply supported changes, and validate the UI after deployment. This also applies to broader customizations such as rules, workflows, Quicklinks, forms, libraries, object extensions, and localized messages. The correct upgrade discipline is controlled migration and regression testing, not blind reliance on automatic preservation. References/topics: IdentityIQ Engineer — upgrade planning, branding customization, UI resource changes, regression testing, customization inventory.

SMTP Port is a required mail configuration value for successful SMTP communication. IdentityIQ must know not only the mail server host but also the network port used to connect to that SMTP service. Common SMTP ports include 25, 465, or 587 depending on whether the environment uses unauthenticated SMTP relay, SSL/TLS, or STARTTLS. Without the port, IdentityIQ cannot reliably establish the socket connection to the mail server, even if the hostname and credentials are correct. Email notification is used heavily across IdentityIQ processes, including workflow approvals, certification reminders, lifecycle events, policy violations, provisioning notifications, and work-item escalation. Therefore, SMTP connectivity settings must be complete and accurate. SMTP Port is not merely cosmetic; it is part of the transport configuration required for IdentityIQ to communicate with the mail infrastructure. References/topics: IdentityIQ Engineer — email notification setup, SMTP server configuration, mail host and port, workflow and certification notifications.

Placing a QuickLink object directly on a workflow is not a valid step in the development of a custom QuickLink. QuickLinks are used to provide users with easy access to specific tasks or workflows through the IdentityIQ interface, but the QuickLink itself is not embedded within the workflow. Instead, the QuickLink is created as a separate object and associated with the desired workflow or task that it is meant to launch.

The correct approach would involve creating a QuickLink that points to the workflow and then controlling access to the QuickLink by restricting it to a specific QuickLink population (e.g., " Managers " ). Therefore, the correct answer is B. No.

Yes, Identity Provisioning Policies can indeed be used to include allowed-values definitions or validation logic on fields within SailPoint IdentityIQ. This ensures that only valid or authorized values can be specified for certain fields, such as when using the " Create Identity " feature to add a new identity. This functionality helps enforce data integrity and compliance with organizational policies by restricting the inputs to predefined or validated options.

SailPoint IdentityIQ Administration Guide (Sections on Identity Provisioning Policies and Field Validation)

SailPoint IdentityIQ Configuration Guide (Policy Enforcement and Validation)

Syslog is not intended for querying or identifying specific objects, such as all Link objects from a particular application. Syslog is used to record events and log information related to system activities, errors, and operations. To identify all Link objects from a particular application, you would use IdentityIQ ' s internal search functionality or reports that allow you to filter and retrieve such objects. These tasks involve querying the database and application-specific data structures rather than examining log files.

SailPoint IdentityIQ Administration Guide (Section on Objects and Searching)

SailPoint IdentityIQ Configuration Guide (Understanding Link Objects)

Yes, this statement is true. The default language of IdentityIQ can be changed from English by replacing the appropriate message files. Administrators can modify or replace the default English message files with those for another language, which will then become the system’s default language. This allows IdentityIQ to be localized according to the organization ' s language preferences.

SailPoint IdentityIQ Localization Guide

SailPoint IdentityIQ Administration Guide (Language Settings and Message File Management Sections)

Yes. Hierarchy is a valid relationship concept for IdentityIQ roles when a role model has a multiple-level structure. IdentityIQ roles are not limited to flat entitlement collections. Role models can be built with layered relationships, where higher-level roles represent broader business access and lower-level roles represent more technical or application-specific access. This is common in mature role-based access control designs: a business role may include IT roles, which in turn may include entitlements or application roles. A hierarchical structure allows organizations to express access in business terms while still mapping that access down to technical resources. The important engineering point is that the role model must be carefully designed to avoid circular dependencies, overbroad inheritance, and difficult certification outcomes. Hierarchical role relationships support maintainable access modeling when used properly, especially in enterprises that are actively using role-based provisioning and role reviews. References/topics: IdentityIQ Engineer — role hierarchy, role relationships, Bundle object, business roles, IT roles, role-based access model.

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.

Creating a custom audit event and setting up an associated report involves steps such as defining the audit event, modifying the audit configuration, and creating a custom report using the SailPoint IdentityIQ reporting framework. Simply creating a Data Export task does not fulfill these requirements. A Data Export task is used for exporting data from IdentityIQ and is unrelated to the creation of custom audit events or custom reports. Refer to the SailPoint IdentityIQ Reporting Guide and the IdentityIQ Audit Framework documentation for more information on correctly creating and configuring custom audit events and reports.

The best policy types for defining each access policy are as follows:

Users cannot be members of the AccountsPayable group in AD and have the CreateVendor access right in the Vendor System application at the same time.Answer: Entitlement SOD

This policy deals with conflicting access rights at the entitlement level (i.e., group membership and specific access rights). " Entitlement Separation of Duties " (SOD) ensures that users don ' t have access to conflicting entitlements.

Users can have two accounts on a given system, but no more.Answer: Account

This policy pertains to the number of accounts a user can have on a system. The " Account " policy type manages restrictions on how many accounts users can possess.

Users who have either the VPN role or the Travel role cannot also be in the Contractor role.Answer: Role SOD

This policy involves conflicting roles. " Role Separation of Duties " (Role SOD) ensures that users cannot have conflicting roles, such as VPN and Contractor, or Travel and Contractor.

Comprehensive Detailed Explanation with All IdentityIQ Engineer References

Entitlement SOD: This policy prevents users from having conflicting access rights. In this case, being in the AccountsPayable group while also having access to create vendors creates a potential conflict. IdentityIQ uses Entitlement SOD to handle these scenarios by preventing such combinations of entitlements.

Account: This type of policy limits the number of accounts users can have on a given system. By setting up an Account policy, IdentityIQ ensures that a user cannot exceed the set number of accounts (e.g., two accounts on a system).

Role SOD: When dealing with conflicting roles (such as VPN or Travel role conflicting with a Contractor role), Role SOD policies ensure that users do not end up in roles that violate governance or security policies. This type of policy ensures role-based access conflicts are mitigated in IdentityIQ.

SailPoint IdentityIQ Compliance Manager Guide (section on defining and managing Separation of Duties (SOD) policies).

Yes, this is an example of a mover lifecycle event. A mover lifecycle event typically occurs when an individual ' s role or employment status within the organization changes, requiring updates to their accounts and access rights. In this scenario, a contractor whose accounts were previously disabled due to contract expiration needs those accounts re-enabled upon securing a new contract. This reactivation and adjustment of access rights based on a change in employment status fits the definition of a mover event.

Therefore, the correct answer is A. Yes.

No, the code snippet provided in the image is incorrect for including a rule library named " Common Rules Library " in a Rule. The correct syntax should reference the sailpoint.object.RuleLibrary class if the intent is to include a Rule Library, as seen in the second image. The first image incorrectly references the sailpoint.object.Rule class, which is not suitable for a rule library inclusion.

Correct Syntax (as shown in the second image):

< ReferenceRules >

< Reference class= " sailpoint.object.RuleLibrary " name= " Common Rules Library " / >

< /ReferenceRules >

SailPoint IdentityIQ Rule Library Documentation

SailPoint IdentityIQ Configuration Guide (Rule and Rule Library Management)

No. IdentityIQ report results are not simply stored as files on the application servers as a universal rule. IdentityIQ is a database-backed governance platform, and generated report metadata/results are associated with task/report result objects and persisted through the platform’s data model. While report exports or generated files may be downloaded or temporarily handled by the application server at runtime, the statement “all report results are stored on IdentityIQ application servers” is technically inaccurate. In clustered deployments, relying on local application-server storage for all report results would also be problematic because multiple application servers may serve the same IdentityIQ environment. IdentityIQ centralizes configuration, task history, report metadata, identities, applications, and governance objects through its database-backed object model. Therefore, the correct understanding is that reports are run by the IdentityIQ task/reporting framework and report result information is managed by IdentityIQ, not universally stored as local application-server files. References/topics: IdentityIQ Engineer — reporting architecture, task results, report instances, application server versus database persistence.

No. ManagedAttribute objects represent managed entitlement or account-group values from applications. They are not generally viewed on the Policy tab of the View Identity QuickLink. The Policy tab is used for policy-related information such as policy violations or compliance policy context, not for listing all entitlements associated with the identity. A user’s entitlements and accounts are normally viewed through identity access/account-related tabs or identity cube access views, depending on UI configuration. This proposed statement confuses ManagedAttribute entitlement data with policy-violation data. A ManagedAttribute may be involved in a policy violation, certification item, access request, or entitlement display, but that does not mean all ManagedAttribute objects associated with an Identity are visible from the Policy tab. The correct engineering distinction is: ManagedAttribute equals governed entitlement metadata; Policy tab equals policy/compliance information. References/topics: IdentityIQ Engineer — ManagedAttribute, Identity Cube, View Identity QuickLink, entitlement display, policy violations.

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. The Environment area under the Administrator Console is intended for administrative visibility into the running IdentityIQ environment, including product/environment details and installed components or extensions where exposed by the platform. Viewing the status or presence of installed SailPoint modules/extensions is consistent with environment inspection. This is very different from controlling the application server itself. The engineer can use IdentityIQ administrative pages to understand what is installed, enabled, or available in the current deployment, which helps during troubleshooting, patch verification, upgrade planning, and support analysis. In multi-node deployments, this kind of environment visibility is useful because module or extension inconsistencies can cause unpredictable behavior. However, viewing status does not imply the Environment tab can install, uninstall, start, or stop all components. The proposed action is read/inspection-oriented, so it fits the purpose of the tab. References/topics: IdentityIQ Engineer — Administrator Console, Environment tab, installed modules, extensions, environment validation, upgrade/troubleshooting checks.

Defining an application is not a default functionality of the Lifecycle Manager (LCM) module. Application definitions are typically part of the core IdentityIQ platform and are managed through the IdentityIQ Administration module, not Lifecycle Manager. LCM is primarily focused on managing identity lifecycle events, such as onboarding (Joiner), role changes (Mover), and offboarding (Leaver).

Therefore, the correct answer is B. No.

One of the primary purposes of an IdentityIQ certification is to provide reviewers with a snapshot of a user ' s system access at a given point in time. This snapshot allows managers, auditors, or other designated reviewers to verify whether the access privileges assigned to a user are appropriate, based on their job responsibilities and compliance requirements. By reviewing this snapshot, organizations can identify and remediate any inappropriate or excessive access, thus maintaining a secure and compliant environment.

Therefore, the correct answer is A. Yes.

Yes, the typical input variables for a rule are listed in the BeanShell rule editor in IdentityIQ, based on the rule registry. When you create or edit a rule in IdentityIQ using the BeanShell editor, the available input variables that are relevant to the rule type are typically pre-defined and listed based on the rule registry. These input variables provide context and data that the rule can operate on, and their availability helps guide the rule development process.

Therefore, the correct answer is A. Yes.

This proposed solution is incorrect because it confuses generating a schema script with applying a generated schema script. To generate the database script for extended attributes, the engineer must update the relevant Hibernate mapping files and then run the appropriate IdentityIQ schema-generation command, commonly from the IIQ_HOME/WEB-INF/bin area, so IdentityIQ can produce the database-specific SQL needed for the extension. Running the extendedSchema script on the database is an execution/apply step, not the generation step. In other words, the generated SQL script is run after it has already been produced. For ManagedAttribute or other object extensions, the sequence matters: define the extension in the mapping/configuration layer, generate the script, stop application services as needed, apply the script to the database, then ensure IdentityIQ object configuration reflects the new attribute. The proposed solution skips the generation step entirely. References/topics: IdentityIQ Engineer — Hibernate extension files, extended schema generation, ManagedAttribute extension, database schema update process.

The statement is false. In SailPoint IdentityIQ, the language displayed in the user interface is not always based on the default language selected in the global settings. The language displayed in the user interface is typically determined by the user ' s language preference, which can be set individually for each user. If a user ' s preferred language is not available, then the system may fall back to the default language specified in the global settings. Thus, while the global default language serves as a fallback, the actual language displayed is often based on user-specific settings.

SailPoint IdentityIQ Administration Guide (Localization and Language Settings Sections)

SailPoint IdentityIQ User Guide (User Preferences and Language Selection)

Yes, the current version and patch level of IdentityIQ can be found through the Debug-About page. The Debug-About page in SailPoint IdentityIQ provides critical information about the system, including the software version, patch level, and other configuration details. This page is a useful resource for administrators to quickly verify the IdentityIQ version and ensure that the correct patches have been applied.

Therefore, the correct answer is A. Yes.

This statement is incorrect. In SailPoint IdentityIQ email templates, entire blocks of text, including whole paragraphs, can indeed be conditionally included or omitted using the appropriate templating syntax such as #if, #else, and #end. The templating engine in IdentityIQ, which typically uses Apache Velocity, supports complex conditional logic that can control large sections of the email content, not just individual lines.

HR Role is not a default IdentityIQ role type. IdentityIQ role modeling uses standard role types such as Business Role, IT Role, Application Role, and Composite Role; the Word bank lists those default types and separately notes that a nonstandard label such as Entitlement Role is not a recognized default role type. “HR Role” could exist in a customer environment as a custom role name, a business-role naming convention, or a role representing human resources access, but it is not a default role type in IdentityIQ. The question is not asking whether a role named “HR Role” can be created. It asks whether HR Role is a default type available for manager request during access request. That distinction matters. Managers request role objects configured as requestable, but the role type must be one of the supported model types. Therefore, the proposed solution is invalid. References/topics: IdentityIQ Engineer — role model, default role types, Business Role, IT Role, Application Role, Composite Role, access request configuration.

This statement is false. BeanShell rules in IdentityIQ do not universally have to produce a meaningful output. A rule’s expected return behavior depends on the rule type and the context in which the rule is executed. Some rules are designed to return a Boolean, String, Map, ProvisioningPlan, Identity, or another object. Other rules perform side effects, such as modifying a plan, transforming values, logging, altering an object, or executing validation logic, and may return null or no useful result. The Word bank contains a related but different rule-output concept: a BeanShell rule does not always need to return an object derived from sailpoint.object.SailPointObject; it may return several other object types or null. The proposed statement is even broader and still incorrect because IdentityIQ rule output is rule-type dependent, not mandatory in a generic sense. References/topics: IdentityIQ Engineer — BeanShell rules, rule registry, return values, rule execution context, input/output contracts.

Yes, the statement is true. When editing a step in the Business Process Editor in SailPoint IdentityIQ, the available step actions are Script, Rule, Subprocess, and Call Method. These actions allow for various types of logic and processing to be embedded within workflows. Each of these actions serves different purposes:

Script: Executes a Beanshell script.

Rule: Calls an existing IdentityIQ rule.

Subprocess: Invokes another workflow as a subprocess.

Call Method: Invokes a method on a specified object.

SailPoint IdentityIQ Business Process Editor Guide

SailPoint IdentityIQ Administration Guide (Section on Workflow Management)

Yes, the statement is true. Both logging and auditing in SailPoint IdentityIQ can have a negative influence on performance because they involve additional function calls within the application. These processes generate data that needs to be stored, which can impact performance if not managed properly. Extensive logging and auditing, particularly at high levels of detail, can lead to increased I/O and storage usage, potentially slowing down system operations.

SailPoint IdentityIQ Performance Tuning Guide

SailPoint IdentityIQ Logging and Auditing Guide (Impact on Performance)

The Create Identity Provisioning Policy in SailPoint IdentityIQ is designed to apply specific provisioning rules and actions during the creation of identities, especially when aggregating data from authoritative sources. These policies ensure that newly created identities have valid and authorized attribute values based on organizational rules and compliance requirements.

During identity aggregation from an authoritative source, the provisioning policy can enforce rules such as role assignments, attribute validation, and other actions necessary to ensure that the identity is created correctly and securely.

Therefore, the correct answer is A. Yes.

Yes. This is a valid Identity search use case because the relationship between an employee and their manager is normally represented on Identity objects through attributes such as manager, manager ID, supervisor, or reporting relationship. If the identity cube contains the manager relationship, Identity search or Advanced Analytics can be used to filter identities whose manager equals a specific person and then count the returned identities. This is completely different from using Syslog for the same purpose. The Word bank rejects Syslog for this scenario because Syslog is a logging facility, not an organizational data query mechanism. But the video asks about the Identity search type, and Identity search is the correct object domain for employee reporting relationships. The engineer must ensure that the manager attribute is populated and searchable or otherwise available to the search interface. References/topics: IdentityIQ Engineer — Identity search, manager attribute, identity cube, reporting relationships, Advanced Analytics filters.

No. Whether an application supports password change requests through the IdentityIQ UI is not controlled by generic LCM workflow control variables. Password-change support depends on the application connector’s capabilities, password-management configuration, application settings, schema/support for password operations, policies, and QuickLink/user-interface configuration. The workflow may process or route a password-change request once launched, but it does not define which target applications support that operation. That capability must be configured at the application/connector and password-management layer. Mixing these layers would create a brittle design: workflow variables should govern execution behavior, while application configuration defines available account operations. Therefore, the proposed solution is not achievable merely by configuring out-of-the-box LCM workflow control variables. References/topics: IdentityIQ Engineer — password management, application connector capabilities, LCM workflows, QuickLink password change, account operation support.

Yes. Importing SailPoint XML objects can be performed through supported IdentityIQ import mechanisms, and using the user interface path Global Settings > Import From File is a valid approach for importing XML object definitions. XML imports are commonly used to move IdentityIQ configuration objects such as rules, workflows, applications, roles, policies, email templates, task definitions, and other SailPoint objects between environments. Engineers may also use the IdentityIQ console for imports, especially for larger or automated deployments, but the existence of the console method does not make the UI method invalid. The proposed solution is specifically asking whether selecting a file through Global Settings > Import From File is a valid step, and it is. The important caution is that imported XML should be reviewed carefully because object names, IDs, references, and environment-specific values can affect behavior after import. References/topics: IdentityIQ Engineer — XML object import/export, Global Settings import, configuration migration, deployment management.

Yes, setting the " Source Mappings: Application Rule " configuration on the account attribute is necessary to meet the requirements described. The use case involves flagging privileged accounts based on attributes read from different applications and using these flags in various IdentityIQ features like Advanced Analytics, rule writing, and policy enforcement. By configuring the attribute with a source mapping that uses an Application Rule, you can implement complex logic to derive the attribute ' s value from multiple sources, such as a financial application and a keystore application, according to the specific requirements.

Therefore, the correct answer is A. Yes.

The statement is incorrect. When writing and executing source mapping rules to populate identity attributes, the rule itself does not need to persist the identity attribute to the database. In SailPoint IdentityIQ, once the value for an identity attribute has been calculated by a source mapping rule, IdentityIQ automatically handles the persistence of this attribute to the database as part of the aggregation or provisioning process. The developer does not need to explicitly persist the attribute; this is managed by the system.

SailPoint IdentityIQ Source Mapping Guide

SailPoint IdentityIQ Administration Guide (Aggregation and Attribute Mapping Sections)

An Account Group Membership Certification is designed to certify group memberships within accounts, typically focusing on the validation of access within specific account groups (e.g., Active Directory groups).

This type of certification does not directly address the accuracy of role composition or the correctness of entitlements assigned within roles. Since the bank ' s goal is to ensure that all roles include the correct entitlements, an Account Group Membership Certification is not suitable for this purpose.

Thus, the correct answer is B. No.

Yes, specifying which access items may be requested can be achieved via configuration of control variables in the out-of-the-box Lifecycle Manager (LCM) workflows. In IdentityIQ, control variables within LCM workflows allow administrators to define the scope and criteria for access requests, including restricting or specifying which entitlements, roles, or applications can be requested by users. This is part of the request configuration process, where the access items that users can see and request are defined.

Therefore, the correct answer is A. Yes.

The statement that a BeanShell rule in IdentityIQ must always return an object derived from the abstract class sailpoint.object.SailPointObject is incorrect. While many rules in IdentityIQ may return objects that derive from SailPointObject, it is not a strict requirement. Rules can return various types of objects depending on their purpose and context. For example, a rule might return a String, Boolean, Map, or even null, depending on what the rule is designed to accomplish.

Therefore, the correct answer is B. No.

Adding a new object attribute to the Application ObjectConfig in IdentityIQ is not sufficient on its own to generate the database script needed to extend Application attributes. This action updates the configuration within IdentityIQ for how the application object is managed, but it does not produce the necessary SQL scripts to modify the underlying database schema. The actual database schema must be extended using specific IdentityIQ tools and commands like iiq extendedSchema.

SailPoint IdentityIQ Configuration Guide (ObjectConfig and Schema Management)

SailPoint IdentityIQ Administration Guide (Database Schema Extension)

Filter String is not required when setting up every IdentityIQ application. A filter string is a connector-specific or configuration-specific option used in some application definitions to limit which accounts, groups, or objects are included during aggregation or connector operations. For example, LDAP-style connectors may use filters to restrict returned accounts, and other connector types may expose filter-like options depending on the source system. That does not make Filter String a universal mandatory field. IdentityIQ applications require core configuration such as application name, connector/type selection, schema information, and account identity handling, but not every application needs a filter. Some applications aggregate all accounts from the configured source, while others use connector-specific search, API, file, or database settings. Treating Filter String as universally required would be wrong because it depends on connector type and business filtering requirements. References/topics: IdentityIQ Engineer — application definition, connector configuration, aggregation filtering, required versus optional application settings.

The statement " All Identity Mappings must use a rule to set the identity attribute " is incorrect. While source mapping rules can be used to populate identity attributes dynamically, it is not mandatory for all identity mappings to rely on a rule. Identity mappings can also be configured using direct mappings, where attributes from a source are directly mapped to IdentityIQ attributes without any rule-based logic.

Therefore, the correct answer is B. No.

Yes, the statement is true. In SailPoint IdentityIQ, the built-in auditing options are indeed immutable, meaning they are always recorded and cannot be disabled or altered. This ensures that critical actions and changes are always logged for compliance and security purposes. However, custom audit configurations, such as additional custom audit fields or logs, can be turned on or off based on specific organizational requirements.

SailPoint IdentityIQ Audit Guide

SailPoint IdentityIQ Administration Guide (Sections on Auditing and Compliance)

In SailPoint IdentityIQ, the concept of a " role " is fundamental to the identity governance framework. The platform supports several default role types that are pre-configured to help organizations manage access effectively. The default role types include:

Business Role: Represents a collection of entitlements necessary for a specific job function within the organization.

IT Role: Aggregates technical entitlements that are typically assigned together, often linked to specific applications or systems.

Application Role: Tied to a specific application, representing roles within that application ' s context.

Composite Role: A combination of other roles, either business or IT, to form a higher-level role.

The term " Entitlement Role " is not recognized as a default role type in SailPoint IdentityIQ. While entitlements can be components of roles, " Entitlement Role " itself is not a predefined role type in the platform. Therefore, the correct answer is B. No.