Configuration practice questions

Business Rules on the cmdb_ci table

Why it fails: Using custom Business Rules is an anti-pattern; native CI relationship rules should be used.

Data Dictionary [sys_dictionary] attribute settings

Why it fails: sys_dictionary handles database level cascades for reference fields, not CMDB relationship rules.

IRE payload processor scripts

Why it fails: IRE processes incoming payloads for insert and update actions, it does not manage structural relationship cascade deletion rules.

cmdb_ci

Why it fails: While adding to cmdb_ci would include servers, it would also affect non-server items like network gear and printers.

cmdb_ci_win_server

Why it fails: Adding an attribute here would only benefit Windows servers, excluding Linux and AIX.

cmdb_ci_computer

Why it fails: cmdb_ci_computer includes non-server devices like workstations and laptops.

cmdb_ci_appl table

Why it fails: cmdb_ci_appl is for software applications, not virtual machines.

cmdb_rel_ci table

Why it fails: cmdb_rel_ci stores relationships, not CI attributes.

sys_user table

Why it fails: sys_user stores user records, unrelated to CIs.

cmdb_ci

Why it fails: cmdb_ci inherits from cmdb and is the base class for Configuration Items, but cmdb is the absolute root table.

cmdb_rel_ci

Why it fails: cmdb_rel_ci stores relationship records, not CI records.

task

Why it fails: task is the base table for workflow-driven items like incidents and changes.

cmdb_ci_rel_server

Why it fails: cmdb_ci_rel_server is not the definition table for relationship types; it stores nothing relevant to declaring a new type. Relationship type records live in cmdb_rel_type, where the parent and child class pair is defined. This table would be consulted when querying existing CI relationships, not when authoring a new type.

cmdb_rel_ci

Why it fails: cmdb_rel_ci stores actual relationship instances between CIs, not the type definitions themselves. Creating a new type requires a cmdb_rel_type record specifying the parent and child classes. cmdb_rel_ci is the correct target when instantiating a relationship between two specific CIs, not when defining a new type.

sys_choice

Why it fails: sys_choice holds choice list values for fields, not relationship type definitions. Relationship types are declared in cmdb_rel_type with parent and child class references. sys_choice would be the right table when adding a new selectable value to an existing field, not when creating a CI-to-CI relationship type.

The cmdb_rel_ci table is missing indexes.

Why it fails: Table indexing impacts query performance, not record matching logic.

The CMDB Health Dashboard needs to be restarted.

Why it fails: The Health Dashboard is a read-only reporting and scoring interface; restarting it merely reloads its calculations and cannot alter how the Identification and Reconciliation Engine matches attributes at insert. It is tempting when dashboard scores look stale, and a restart would be correct to refresh displayed health metrics.

CI Class Manager relationship rule definitions

Why it fails: Relationship rules manage parent-child connectivity, not aging thresholds.

Discovery Schedule properties

Why it fails: Discovery schedules govern scan frequency, not CMDB health aging rules.

Data Archiving rule definitions

Why it fails: Data archiving moves old records to archive tables, which is distinct from CMDB Health correctness metrics.

Software license audit compliance

Why it fails: License audit compliance belongs to the Compliance metric group, which checks CIs against licensing and audit rules, not the Correctness pillar. It is tempting because both surface data-quality problems, but Compliance would be the right choice when the requirement is tracking entitlements and audit adherence rather than duplicate or orphan CIs.

Required fields populated

Why it fails: Required fields populated is a Completeness metric, verifying mandatory attributes are present, not a Correctness metric. It tempts because missing data feels like a data-quality fault, but Completeness is correct when the goal is measuring how many CIs have all mandatory fields filled rather than whether populated values are accurate.

Recommended attributes filled

Why it fails: Recommended attributes filled is a Completeness metric, measuring optional attribute coverage, not Correctness. It is tempting because both pillars address data quality, but Completeness is the right pillar when the requirement is tracking how thoroughly CIs are documented with recommended fields, not whether existing values are valid.

Availability

Why it fails: Availability is tracked through service management metrics, not CMDB health pillars.

Performance

Why it fails: Performance is not a CMDB health pillar.

Scalability

Why it fails: Scalability is an architectural property, not a CMDB health dashboard pillar.

Cost Center

Why it fails: Cost Center is a financial classification attribute, not a unique identifier; it repeats across many CIs, so IRE cannot distinguish records using it. Tempting because it appears on CI forms and aids reporting, and it would be correct as a reconciliation or class-mapping attribute rather than an identifier.

Department

Why it fails: Department is an organisational attribute shared by numerous CIs, so it cannot uniquely identify a record during IRE processing. Tempting since it is a common CI field used for ownership reporting, and it would be correct as a reconciliation value or filter criterion, not as a unique identifier.

All attributes are stored in a single flat cmdb_ci table with discriminator columns.

Why it fails: ServiceNow stores each class in its own table, so inserting into cmdb_ci_iot writes the record to cmdb_ci_iot and its ancestors, not one flat table. Discriminator columns describe single-table inheritance, used in relational designs without native table extension. Here, cmdb_ci_iot inherits through four physical tables, so no discriminator column exists.

The platform throws an error because more than two levels of extension are prohibited in the CMDB.

Why it fails: ServiceNow supports multiple levels of table extension within the CMDB hierarchy.

Records are stored exclusively in the cmdb_ci table, and child tables only store metadata.

Why it fails: Records are stored in the table where the insert occurs, so a cmdb_ci_iot record lives in cmdb_ci_iot, not cmdb_ci. Metadata-only child tables describe table extension via dictionary entries, which is not how ServiceNow stores instance data. This option would fit a design where child tables merely annotate a shared parent, not true inheritance.

Dictionary Overrides on cmdb_rel_ci

Why it fails: Dictionary Overrides control default values, mandatory status, and read-only states for fields on extended tables, not relationship rules.

CI Class Manager > Relationship Tab

Why it fails: Relationship rules are managed under Suggested Relationships rather than directly inside the CI Class Manager attribute settings.

Discovery Schedule filters

Why it fails: Discovery Schedules control when and what discovery probes run, not CMDB relationship rules.

Identification rules only apply when data is ingested via Service Graph Connectors, ignoring standard Discovery.

Why it fails: IRE applies to all Discovery, Service Graph Connectors, and custom integrations using the IRE APIs.

The IRE automatically creates custom relationship types for every identification rule created.

Why it fails: Relationship types are independent of identification rules.

cmdb_rel_ci

Why it fails: cmdb_rel_ci stores relationship instances between CIs, not CI attributes. It tempts because it sits in the CMDB namespace and appears central to configuration data, but a database instance's attributes live on the cmdb_ci table and its descendants, not on the relationship table.

sys_object

Why it fails: sys_object is not a CMDB class table; it belongs to platform metadata rather than configuration item storage. It tempts because the sys_ prefix suggests a foundational system table, but CI attributes reside on cmdb_ci, the base class from which cmdb_ci_database and other CI classes extend.

cmdb_ci

Why it fails: cmdb_ci is the base class table itself, not a table representing where attributes are stored for a discovered instance; the question asks which table holds the base class definition, and cmdb_ci is that class rather than a storage location for a specific CI's attributes. It is tempting because cmdb_ci is the parent of all CI classes, so it would be the correct answer if the question asked for the base class name rather than the table storing a discovered instance's attributes.

It automatically purges all relationship records whenever a parent CI is updated by a discovery schedule.

Why it fails: Discovery updates relationships via IRE rules, but does not automatically purge all relationships blindly unless configured via stale CI cleanup rules.

It stores unique configuration item attribute values such as IP address and serial number for network gear.

Why it fails: Attribute values are stored in the respective CI class tables (e.g., cmdb_ci_netgear), not the relationship table.

Depends on::Used by

Why it fails: The 'Depends on::Used by' relationship indicates a dependency, but it does not inherently control lifecycle operations like retirement. It is used to show that one CI depends on another, but it does not prevent cascading retirement. The relationship type does not enforce lifecycle separation.

Contains::Contained by

Why it fails: The 'Contains::Contained by' relationship is typically used for physical or logical containment, such as a server containing a database. It implies a strong ownership where the contained item's lifecycle may be tied to the container, which could lead to unwanted cascading retirement. It is not suitable for business service to application service mapping.

Runs on::Runs

Why it fails: The 'Runs on::Runs' relationship is used to show that a CI runs on another, such as an application running on a server. It is not appropriate for business service to application service mapping and does not address lifecycle independence. It implies a hosting relationship, not a usage relationship.

Enable the CMDB Health Dashboard for the new source.

Why it fails: The CMDB Health Dashboard is a monitoring tool and does not affect IRE processing. Enabling it may provide visibility into data quality but is not required for IRE to identify and reconcile CIs from a new discovery source.

Create a Transform Map to convert data to CI format.

Why it fails: Transform maps are used in import sets to map incoming data to target tables, but IRE processes data through its own identification and reconciliation engine. While transform maps may be used in the overall data import process, they are not a direct requirement for IRE to process data from a discovery source.

Configure a Reconciliation Rule to specify attribute precedence.

Why it fails: Reconciliation rules are used to resolve conflicts when multiple data sources provide different values for the same attribute. While important, they are not strictly required for IRE to process data; IRE can use default reconciliation behavior. The question asks for actions to enable IRE to process data, which is primarily identification.

Create a Business Rule on the cmdb_ci table to check the updated-by user.

Why it fails: A business rule keyed on the updated-by user cannot reliably distinguish a data source writing through the import set from a genuine manual edit, and it fires after the record is already changed. It is tempting because business rules are the usual place to enforce field-level logic, and would be correct for validating user-entered values rather than protecting attributes from a specific source.

Modify the Identification Rule to exclude the manual attributes.

Why it fails: Identification Rules determine which attributes match existing records and can add attributes, but they cannot selectively exclude individual attributes from being overwritten by a data source. They are used to define matching criteria between sources, not to protect manually maintained fields.

Disable the data source integration entirely.

Why it fails: Disabling the integration stops all attributes updating, including the many fields SCCM legitimately maintains, so discovery data goes stale. It is tempting because it guarantees the manual values survive, and would be correct if the data source supplied nothing of value or were being permanently retired.

CI Class Manager

Why it fails: CI Class Manager administers class definitions, attributes and identifiers in the CMDB schema; it displays no instance-level relationship map. It is the right place when creating or editing CI classes, not when viewing a core router's upstream and downstream dependencies graphically.

CMDB Query Builder

Why it fails: CMDB Query Builder returns tabular result sets from stored queries and reports; it does not draw the interactive dependency map of a single CI. It suits bulk reporting across many CIs, whereas viewing one router's parent-child and upstream relationships requires Dependency Views.

CSDM Dashboard

Why it fails: The CSDM Dashboard reports data-model health, coverage and governance metrics across CSDM domains; it renders no dependency topology for a single CI. It would be chosen when auditing CSDM adoption, whereas the graphical relationship map for a router is the Dependency Views map.

Data Normalization Engine

Why it fails: Data Normalization Engine applies rules that standardise attribute values before storage, so it cannot alter matching logic itself. It is tempting because naming inconsistencies are the visible symptom, but normalisation rewrites data rather than controlling how incoming CIs are compared. The Identification and Reconciliation Engine governs matching and reconciliation rules.

CMDB Health Dashboard

Why it fails: The CMDB Health Dashboard reports on duplicate, orphan and stale CIs after the fact; it surfaces symptoms rather than letting you examine or adjust matching rules. It is tempting because duplicates appear there, but remediation requires the Identification and Reconciliation Engine, where matching criteria and precedence are configured.

Dependency View

Why it fails: Dependency View visualises relationships between CIs, such as which services rely on which servers, and plays no part in matching incoming discovery records. It is tempting because duplicate CIs distort those maps, yet the tool that examines and adjusts matching logic is the Identification and Reconciliation Engine.