Free Practice Questions for SailPoint IdentityIQ-Engineer Exam

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)

This statement is not correct. IdentityIQ syslog event searching is not limited only to Incident Code lookups. Incident Code is useful when a user-facing error displays a code that can be traced back to a logged system event, but syslog analysis is broader than that. Administrators and engineers use syslog data to investigate operational errors, workflow failures, connector issues, provisioning errors, aggregation failures, authentication problems, and application exceptions. Advanced Analytics and log-search capabilities are intended to help filter and locate system events using more than a single incident-code value. Treating Incident Code as the only searchable attribute would make syslog analysis nearly useless for routine troubleshooting where no user-facing incident code is available. The correct engineering view is that Incident Code is one important search key, not the exclusive search mechanism. References/topics: IdentityIQ Engineer — syslog search, Advanced Analytics, incident code troubleshooting, system-error diagnosis, operational logging.

Yes. A Manager Correlation Rule is specifically intended for situations where IdentityIQ must establish the manager/direct-report relationship but a straightforward attribute-to-attribute mapping is insufficient. In a simple implementation, IdentityIQ can correlate an application attribute containing the manager identifier directly to an identity attribute. Here, however, the organization has inherited several employee-number formats through mergers. That requires normalization, transformation, conditional comparison, or other custom matching logic before the manager identity can be resolved.

SailPoint explicitly documents that Manager Correlation normally uses an application attribute and an identity attribute, but when the matching requirement is more complex than a simple field match, a Manager Correlation Rule can implement the correlation programmatically. The rule can normalize the different employee-number formats, generate appropriate comparison values, search for the matching Identity object, and return the manager relationship required during identity processing. A normal account Correlation Rule addresses account-to-identity correlation and is therefore not the precise rule type for this requirement.

References/topics: IdentityIQ Engineer — Manager Correlation Rule, authoritative-source aggregation, Identity Cube manager relationships, complex correlation logic, Application Definition Rules.

=======

The statement is false. While it is true that logging and auditing require extra function calls and generate data, the suggestion that this data can be compressed to avoid storage issues and improve performance is misleading. In practice, while compression might save storage space, it does not inherently improve performance, particularly because the overhead of compression and decompression could negate the performance benefits. Effective performance management in IdentityIQ involves more nuanced approaches, such as optimizing the level of detail in logs, managing log rotation, and tuning the system for efficient I/O operations.

SailPoint IdentityIQ Logging and Auditing Guide

SailPoint IdentityIQ Performance Tuning Guide

A Post-Iterate rule is used in the context of data aggregation or import processes, where it runs after each record has been processed during the iteration of accounts. This type of rule is not appropriate for handling provisioning errors or creating audit records based on provisioning failures. For auditing provisioning errors, you should configure error handling in the provisioning policy or use a custom workflow that logs errors into the audit log. The Post-Iterate rule is irrelevant to provisioning tasks and error logging, making it unsuitable for this purpose. Refer to the SailPoint IdentityIQ documentation on rules and workflows for proper error handling strategies during provisioning.

Yes, defining account correlation via a rule is an action that can be performed as part of configuring an application definition in SailPoint IdentityIQ. Account correlation rules are often used to determine how accounts from different sources are linked to identities within IdentityIQ. These rules allow for complex logic to be applied when matching accounts to identities, beyond simple attribute matching.

SailPoint IdentityIQ Administration Guide (Section on Account Correlation)

SailPoint IdentityIQ Application Configuration Guide (Using Rules for Account Correlation)

Create Policy is not required for every IdentityIQ application. In IdentityIQ, provisioning policies are used when the system needs structured forms and field definitions for operations such as account creation, update, delete, enable, disable, or password actions. A Create Policy is specifically relevant when IdentityIQ is expected to create accounts on that target application and needs to collect or calculate the required values for account creation. Many applications may be onboarded initially for aggregation, correlation, governance, certifications, or visibility only, without immediate provisioning. In those cases, a Create Policy is unnecessary. Even in provisioning-enabled environments, not all applications support account creation, and some may support only entitlement changes or account disables. Therefore, Create Policy is an optional provisioning configuration, not a required field for setting up any application. References/topics: IdentityIQ Engineer — application onboarding, provisioning policies, Create Account policy, aggregation-only applications, account provisioning configuration.

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.

No. The key technical problem is the term Create Rule . IdentityIQ does not use an application “Create Rule” as the standard mechanism for defining how new target-system accounts are provisioned. New-account provisioning is principally defined through an application ' s Create Account Provisioning Policy . That policy identifies the fields required for account creation and determines how their values are obtained. Field values can themselves come from literals, scripts, rules, dependencies, or requester-entered information.

IdentityIQ does have a Creation Rule , but that is an aggregation rule with a different purpose. SailPoint documents the Creation Rule as executing when a new Identity is created during aggregation, commonly from an authoritative application. It can manipulate the identity being created—for example, its name or attributes—but it is not the mechanism that specifies how a new account is provisioned to a target application.

Provisioning rules such as BeforeProvisioning and AfterProvisioning can customize a ProvisioningPlan around connector execution, but that still does not make “Create Rule” the account-creation definition. Therefore, as worded, the proposed solution is false.

References/topics: IdentityIQ Engineer — Application Provisioning Policies, Create Account policy, Creation Rule, BeforeProvisioning Rule, Application Definition.

=======

Yes. Once the custom audit action and report definition have been created and loaded into IdentityIQ, configuring and scheduling the resulting custom report through Intelligence > Reports is a valid step in completing the reporting solution.

IdentityIQ ' s reporting framework exposes standard and custom report definitions through the Reports UI. A report can be opened and configured with the required filters or parameters, saved as an appropriate report instance, executed immediately, or scheduled for future and recurring execution. SailPoint documents that reports can be scheduled to execute once, hourly, daily, weekly, monthly, quarterly, or annually.

For a custom audit-report implementation, this scheduling step logically follows the underlying development work: the custom AuditAction must first be defined, executable logic must actually create AuditEvent records using that action, and a custom report definition must be created that queries the required audit data. Scheduling the report does not replace any of those earlier implementation steps, but it is a legitimate final operational step once the custom report exists.

Therefore, this proposed solution is one valid step toward accomplishing the stated goal.

References/topics: IdentityIQ Engineer — custom AuditEvent reporting, custom TaskDefinition reports, Intelligence > Reports, report scheduling, recurring compliance reporting.