ServiceNow Certified Implementation Specialist Data Foundations

Identification Simulation can show input, IRE logs, and output for a simulated run without committing CMDB updates.

This is correct because Identification Simulation is designed to expose the information that would be used and produced during IRE processing without actually committing the resulting CMDB changes. The administrator can review the input payload, IRE processing information, and simulated output. This makes the feature useful for diagnosing identification and dependency behavior. A simulated result therefore provides diagnostic evidence without changing the CMDB.

A partial item can be stored for potential later processing when it has a recoverable identification-related error.

This is correct because IRE can retain certain items that cannot currently be fully processed when the error is considered recoverable. A partial item can preserve the information needed for a later processing attempt. This is different from an item that is considered incomplete and is retained only for logging. The distinction allows recoverable identification problems to be addressed without permanently discarding the item.

An incomplete item is stored for logging and is not processed again.

This is correct because an incomplete item represents a payload item that cannot be processed because the required information is insufficient or otherwise incomplete. IRE can retain the item for diagnostic or logging purposes. It is not treated as a recoverable item that will automatically be retried later. This distinction is important when determining whether the original source data can be expected to receive another processing attempt.

A simulated output proves that the corresponding createOrUpdateCI API call already committed the CMDB changes.

This is incorrect because Identification Simulation specifically avoids committing CMDB updates. The output represents what the IRE processing would produce during the simulated operation. It does not prove that a real createOrUpdateCI execution occurred. A simulated result therefore cannot be used as evidence that the CMDB was actually modified.

A dependent CI can be generated without supplying information for its required dependency because IRE resolves all dependencies from the class name alone.

This is incorrect because a dependent CI requires the appropriate dependency information for the relationship to be represented correctly. The class name alone is not sufficient to establish all required dependency context. Identification Simulation can work with dependent CIs when the required dependency information is supplied. Omitting that information can prevent the expected payload or relationship processing from occurring.

A payload with duplicate CIs is accepted by IRE and processed using the first matching CI.

This is incorrect because duplicate CI conditions are not simply resolved by taking the first matching CI in the payload. IRE has identification behavior designed to prevent ambiguous or duplicate identification from being treated as a straightforward match. A payload containing duplicate or conflicting CI information can therefore produce an identification error rather than arbitrarily selecting the first record. The first matching CI is not a general IRE resolution rule.

The advisor replaces its stored scope with the current instance configuration without requiring the administrator to review the change.

This is incorrect because the advisor does not silently replace its stored scope when an administrator changes the instance configuration outside the advisor. The distinction between the two configurations is important because the advisor maintains its own scope. The administrator is expected to be made aware when those configurations no longer match. Automatically overwriting the stored scope would remove that visibility.

The advisor compares its stored scope with the current instance principal-class configuration and notifies the administrator that the configurations are out of sync.

This is correct because the advisor checks whether the principal-class configuration it has stored matches the current instance configuration. When Server has been removed and Database added outside the advisor, the two configurations no longer match. The advisor identifies this discrepancy and notifies the administrator that the configurations are out of sync. This gives the administrator an opportunity to reconcile the difference rather than silently changing one configuration.

The advisor recalculates the principal classes from incident, problem, and change activity before determining whether the two configurations differ.

This is incorrect because the discrepancy check is a comparison of the advisor's stored scope and the current instance principal-class configuration. It is not necessary to recalculate principal classes from operational activity before determining whether those configurations differ. Operational activity can be relevant to other advisor recommendations, but it does not replace the direct synchronization check described here. The issue is specifically that the administrator changed the principal-class configuration outside the advisor.

The advisor discards its stored scope because principal-class changes made outside the advisor invalidate the advisor configuration.

This is incorrect because an out-of-sync configuration does not cause the advisor to simply discard its stored scope. The advisor retains its configuration and identifies the discrepancy so that the administrator can address it. Treating the stored scope as invalid and deleting it would prevent the administrator from seeing what configuration has diverged. The documented behavior is notification of the mismatch rather than automatic disposal of the advisor scope.

The com.snc.task.principal_class_filter property is a comma-separated list of task types.

This is correct because the property identifies the task types for which principal-class filtering should be applied. Its value is configured as a comma-separated list of task types. The property therefore acts as the control point for deciding which task records receive the filtering behavior. It does not directly define which CI classes are principal.

Filtering is applied to the cmdb_ci field for task types listed in that property.

This is correct because the filtering behavior affects the CI reference used by the applicable task records. When a task type is included in the property, its cmdb_ci field can be constrained to principal classes. This is why changing the property can alter what appears in the CI lookup on those task forms. The property controls where the principal-class filter is applied rather than redefining the classes themselves.

Removing a task type from the property can stop principal-class filtering for that task type without clearing the Principal Class designation on CI classes.

This is correct because the property controls which task types use the filtering behavior. Removing a task type therefore changes the behavior for that task type without changing the underlying class configuration. A CI class can remain designated as a Principal Class even when a particular task type no longer applies the filter. These are separate configuration controls.

The property causes the Principal Class setting to derive automatically to every descendant class.

This is incorrect because the property does not control CI class inheritance. Principal Class designation is part of the CI class configuration, while the property controls which task types use principal-class filtering. Changing the task property does not automatically mark descendant classes as principal. The two configuration mechanisms should not be conflated.

The property changes which CI classes are designated as principal in cmdb_class_info.

This is incorrect because the property does not define the Principal Class designation itself. It determines which task types apply the principal-class filter to their CI reference field. The underlying class designation remains configured separately. Changing the property therefore does not rewrite the class information.

The default task-type list includes incident, problem, and change_request families.

This is correct because the property is intended to identify common task types for which principal-class filtering is enabled. The standard task-type configuration includes Incident, Problem, and Change Request task families. This allows the CI lookup on those tasks to use the principal-class restriction. The list can be adjusted when the administrator needs different task types to use the filtering behavior.

Service-instance groups represent interdependent CIs, so service associations and impact analysis are expected; Technology management service groups can collect unrelated CIs for individual management.

This is correct because the purpose of the dynamic CI group depends on the type of service it represents. A group associated with a service instance represents a collection of CIs that participate in the service and therefore has implications for service associations and impact analysis. A Technology Management Service group can instead be used to collect CIs that are managed together without requiring those CIs to form an interdependent service topology. The service context therefore determines how the group is expected to participate in the CSDM and impact model.

Technology management service groups represent interdependent CIs, while service-instance groups collect unrelated CIs without impact analysis.

This is incorrect because it reverses the service-context distinction. Service-instance groups are the context in which the grouped CIs represent an interdependent service structure relevant to service associations and impact analysis. Technology Management Service groups can be used to collect CIs for management without requiring the same service-instance topology. The answer therefore assigns the expected behavior to the wrong service type.

Both service types require identical service associations because every dynamic CI group propagates impact.

This is incorrect because dynamic CI groups do not have identical service behavior regardless of their service context. The distinction between a service instance and a Technology Management Service is meaningful in the CSDM model. Service-instance groups have the expected service association and impact-analysis behavior, while Technology Management Service groups can serve a different management purpose. Therefore, the existence of a dynamic CI group alone does not mean that every group propagates impact identically.

Neither service type uses service associations because dynamic CI groups are limited to task assignment.

This is incorrect because dynamic CI groups are not limited to task assignment. Their service context can determine how the grouped CIs participate in service relationships and impact analysis. In particular, service-instance groups can represent interdependent CIs that contribute to the service model. The statement therefore incorrectly removes the service-management role of dynamic CI groups.

A health inclusion rule can limit the duplicate metric to Server and Network CIs.

This is correct because CMDB Health inclusion rules can be used to control the records considered by applicable health metrics. A rule can narrow duplicate evaluation to the desired CI classes instead of evaluating every CI in the CMDB. This allows the duplicate metric to focus specifically on Server and Network CIs. The inclusion configuration therefore provides the appropriate control point for the metric population.

Health inclusion rules can be defined per domain, but duplicate-metric health inclusion is supported in the global domain.

This is correct because health inclusion configuration has domain considerations, and duplicate metric inclusion is associated with the global domain. The domain determines where the inclusion behavior is configured and applied. This is important when designing a health configuration in a domain-separated environment. The duplicate metric does not simply use an arbitrary domain-specific configuration without regard to these rules.

Identification inclusion rules can also affect which duplicate CIs appear because the dashboard uses IRE for duplicate identification.

This is correct because duplicate identification relies on IRE identification behavior. Identification inclusion rules can therefore influence which records participate in the identification process used to determine duplicate results. Health inclusion and identification inclusion serve different purposes, but both can affect what ultimately appears in duplicate-related results. The health rule controls the health metric population, while identification configuration influences how duplicate records are identified.

Dot-walking is supported in duplicate-metric health inclusion rules and is required to identify descendant CIs.

This is incorrect because dot-walking is not the mechanism required to identify descendant CI classes for this health inclusion configuration. CI class inheritance and the applicable inclusion behavior determine which classes are evaluated. Requiring dot-walking would incorrectly treat class selection as if it depended on traversing related fields. The configuration does not require dot-walking for this purpose.

A health inclusion rule on cmdb_ci can filter results for every descendant class without affecting any other health metric.

This is incorrect because a health inclusion rule is tied to the applicable metric rather than acting as a universal filter for all CMDB Health metrics. Using the base cmdb_ci class does not mean that the rule becomes a global filter that automatically changes every other metric. The duplicate metric has its own evaluation scope. Therefore, this statement overstates the effect of the inclusion rule.

Duplicate-metric inclusion is controlled by Data Certification tasks rather than by health inclusion or identification inclusion rules.

This is incorrect because Data Certification is not the mechanism that defines the CI population for the duplicate metric. Duplicate evaluation is governed by CMDB Health configuration and IRE identification behavior. Health inclusion rules can constrain the records evaluated, while identification inclusion rules can influence identification. Data Certification tasks do not replace those controls.