ServiceNow Certified Implementation Specialist - Discovery (CIS-Discovery / CIS-DISCO) (SERVICENOW-CIS-DISCOVERY) (SERVICENOW-CIS-DISCOVERY) — Questions 76–150

Identification rules determine which CI a discovered record matches; if they fail to match, the CI is not updated even though the probe completed successfully. The 'Success' status reflects probe execution, not record reconciliation, so faulty identification rules are the likely cause.

Pattern properties include the CI type that the pattern discovers. This setting determines the base CI class for the pattern and is essential for the pattern to correctly create or update CIs in the CMDB. It is configured at the pattern level, not within individual steps.

The MID Server record carries the Capabilities related list, where you assign capabilities such as Windows. Only MID Servers holding the matching capability are selected for that discovery, restricting the named server to Windows-only probes within the cluster.

The Variables tab shows the content of the temporary memory during the current debug session.

Each discovery run creates a Discovery Status record, and its related Discovery Log tab lists per-device scan activity, including the specific device's probe results, errors and timings, making it the location to inspect that device's log.

A MID Server deployed inside the target network segment initiates outbound connections to ServiceNow, so discovery traffic never traverses the firewall inbound. This satisfies the constraint of discovering devices behind a firewall without opening inbound ports.

CIDR notation lets you express an entire subnet as a single compact range, such as 192.168.1.0/24, which Discovery expands into individual addresses during scanning. This satisfies the stem's requirement for a valid IP range configuration method, avoiding the need to list every host address separately.

In the CMDB, the 'ip_address' field on a server CI is typically a single-value field that stores the primary IP address. Additional IP addresses are represented as separate Network Adapter CIs (cmdb_ci_network_adapter) related to the server. Discovery patterns often populate the primary IP and create or update network adapter CIs for each interface. This design allows multiple IPs to be tracked without overloading a single field.

IRE applies identification and reconciliation rules to incoming Discovery payloads, matching CIs against existing records and resolving conflicting attribute values. This prevents duplicate CIs and enforces data integrity before anything is written to the CMDB.

Dependency View renders a CI's relationships as an interactive graphical map, showing upstream and downstream connections visually. This satisfies the graphical-format requirement, unlike list-based CI records, which present relationships as text and are harder to interpret at a glance.

Parse Name-Value pair extracts key-value pairs from a multi-line string in one step, splitting on the colon delimiter and returning each key with its value. This directly satisfies the single-step extraction constraint, avoiding manual scripting or repeated string operations.

A regular expression supplies the pattern and capture group that the Parse Variable step uses to isolate the required substring from the larger variable. Without a regex defining the capture group, the step cannot identify which portion of the source string to extract.

The Identification section defines the CI identification rules, so failures there stem from incorrect identifier entries, conditions or table selection. Inspecting it directly reveals why the pattern cannot match incoming data during the identification phase.

Debug mode replays the discovery and mapping process step by step, exposing where CI attributes or relationships diverge from the actual infrastructure. This pinpoints why the business service is flagged inaccurate, which is the standard diagnostic path before rebuilding the service.

Verifying the MID Server service is running on the host directly addresses the most common cause of a MID Server failing to report 'Up': the Windows service or Linux daemon has stopped. Without the service active, no heartbeat reaches the instance, so the MID Server record cannot show 'Up' status.

The MID Server record stores the host IP address as the network endpoint the instance uses to reach that MID Server, satisfying the need to identify where it runs. This connection detail appears alongside the MID Server name and status, confirming the address is a stored record attribute rather than discovered configuration data.

Reconciliation rules define which data source wins when multiple sources report conflicting values for a CI attribute, letting you set source precedence per attribute. This directly satisfies the stem's requirement to change a data source's priority, since precedence is configured there rather than in identification or CI class settings.

Catastrophic backtracking occurs when nested quantifiers force the regex engine to explore exponentially many match paths as input length grows, so a pattern that succeeds on small command outputs can hang indefinitely on large ones. This directly satisfies the stem's focus on extraction challenges, since command outputs are often lengthy and unpredictable.

An orphan CI is a configuration item that has no relationships defined to any other CI in the CMDB. This typically results from incomplete discovery or missing dependency mapping, and it prevents accurate impact analysis until relationships are established.

Presence of required fields directly feeds the Completeness score, which measures whether mandatory attributes are populated on each CI. The dashboard flags CIs missing those fields, so this factor satisfies the stem's requirement for a completeness contributor rather than correctness, duplicate or orphan metrics.

Name-Value pair parsing splits each line on the delimiter, here the equal sign, mapping the left token to a field name and the right to its value. This directly matches the stated key-value format, unlike regex or XML strategies that assume different structural delimiters.

Probe results are written to the ECC Queue as input records; each payload contains the raw XML response returned by the probe for that device. Inspecting the related ECC Queue records shows exactly what the probe sent and received, satisfying the need to see precise probe output during troubleshooting.

MID Server names must be unique within the instance. A duplicate name causes the second server to fail registration, so it cannot be validated or used for discovery. The name is the identity key the instance uses to associate probes and credentials.

Identification rules define the attributes IRE uses to match incoming Discovery data to existing records. If those criteria are wrong, the same physical hardware fails to match its existing CI, so Discovery inserts a new record instead, producing duplicates.

A step condition allows you to specify a condition that must be true for a particular step to execute. In this scenario, you can add a condition to the Identify step that checks if the hostname starts with 'prod-'. If the condition is false, the step is skipped. This provides granular control over step execution within the pattern.

The MID Server's Java installation path is defined in wrapper.conf, which the Java Service Wrapper reads at startup to locate the JVM. Editing this file satisfies the custom Java version requirement, since the wrapper launches the MID Server process using the java command specified there.

The keystore folder holds the MID Server’s private key and certificates, which authenticate it to the instance. Without these, a restored MID Server cannot re-establish trusted communication, so backing it up satisfies the stem’s requirement for critical configuration files.

Classification records map conditions, such as the Linux Server class, to the CI type and the pattern Discovery should run. Attaching the custom pattern there ensures it triggers only once the device is classified as a Linux Server, satisfying the stem's requirement to target that classification rather than ignoring the application.

Exploration is the phase that probes a classified device to gather attributes and populate the CMDB; classification alone does not collect data. If the device is correctly classified but records remain empty, the exploration step has failed, so investigate it before patterns, probes or sensors.

Validation exchanges keys so the instance stores and trusts the MID Server's public key, enabling encrypted communication. This satisfies the stem's mechanism question: trust is established through public key exchange, not through job execution or configuration checks.

Shazzam probes target devices to identify open ports and active services, feeding this data to later classification phases. This directly fulfils the stem's requirement to define the phase's purpose: port and service detection, not credential testing, CI creation, or dependency mapping.

Up status confirms the MID Server is running and checking in with the instance, while Validated false means the explicit validation action has not been performed. Validation confirms the configuration is correct and is a separate step an administrator triggers after the MID Server is reachable, which matches this scenario exactly.

Discovery capability must be enabled on the MID Server record for it to run discovery probes and patterns. Without this capability, the MID Server connects and reports its status but refuses discovery jobs, so the instance cannot dispatch them.

Identification Rules specify which CI attributes, such as serial number, MAC address or name, are compared against incoming discovery data to determine whether a record matches an existing CI. This satisfies the stem's requirement for the rule's primary function within the CMDB.

Identification Rules define the attributes and conditions Discovery uses to recognise and reconcile CIs into the correct class. Without one, discovered devices fall into default or unrelated classes, so the custom class is never populated, defeating the purpose of creating it.

CI Class Manager includes reconciliation rules that define source precedence for CI attributes. By ranking the Discovery source higher than the import source for the serial number attribute, the platform applies Discovery's value when both sources update the CI. This is the supported way to resolve conflicting attribute values between discovery sources and imports in the CMDB.

The Discovery Status record stores the MID Server name that executed each discovery run, so opening the relevant status entry reveals the exact MID Server used. This directly identifies the performing MID Server for that task.

The Discovery Status record log captures per-step execution output, including the exact error and the step that threw it, so it directly identifies the failing step. This satisfies the stem's requirement to pinpoint causation after a pattern step failure, rather than inferring it from device classification or schedule data.

The Discovery Log captures per-phase execution detail, including Exploration errors, and records the exact credential failure message returned by the probe. It satisfies the stem's requirement to locate the specific error logs for insufficient credentials, since the log is scoped to the individual discovery run rather than aggregated platform-wide.

MID Server Clusters let a single schedule distribute probes across multiple MID Servers, sharing load and reaching segmented network ranges. This satisfies the requirement to spread scanning capacity rather than relying on one MID Server.

The Pattern Designer provides a test capability that executes the pattern against a specified device and exposes step-by-step results, including parsed variable values. This lets you confirm the hostname extraction is correct in isolation, without waiting for or affecting a scheduled discovery. It is the intended validation workflow during pattern development.

XPath addresses the nested structure directly by navigating the XML hierarchy with path expressions, selecting a specific child node without manual iteration. This satisfies the stem's requirement to drill down into a particular node within a nested response, unlike flat parsing approaches that cannot target depth precisely.

Horizontal discovery patterns are responsible for collecting detailed attributes such as serial number from devices. If the serial number is missing, the pattern may not include the necessary probe or step to retrieve it, or the pattern may be outdated. Investigating and potentially updating the Windows OS pattern ensures the correct command or WMI query is executed to populate the serial number field.

Deleting a Discovery Schedule removes the record that triggers automated discovery runs, so no further executions occur on its defined interval. This directly satisfies the scenario's requirement of stopping future automated runs, though existing discovered CIs and historical discovery data remain unaffected in the CMDB.

CMDB Data Manager automates lifecycle management of configuration items, satisfying the stem's focus on governing CI records across their lifespan. It applies policies for creation, certification, retirement and deletion, enforcing data hygiene without manual intervention. This directly addresses the requirement to manage CIs from onboarding through decommissioning, rather than merely discovering or reconciling them.

The Discovery Pattern Log records each pattern step's execution, including the values returned and any attribute-mapping errors. When a CI is identified but an attribute is not written, this log exposes the failing step, unlike horizontal discovery logs that only report overall probe outcomes.

Regex parsing extracts structured attribute values from raw command output, feeding them into the pattern's CI population logic. It satisfies the requirement for a valid output-handling method by transforming unstructured text into discrete fields the identification and exploration steps can consume.

The Identification and Reconciliation Engine applies identification rules and reconciliation precedence to normalise incoming discovery data before it reaches the CMDB. This satisfies the requirement to orchestrate CI data flow while enforcing data quality and deduplication.

Dependency View renders CIs and their relationships as an interactive map, exposing upstream and downstream connections that flat lists hide. It satisfies the requirement to visualise dependencies, unlike related lists or CI class managers, which present records without topology context.

The config.xml startup parameters include the instance URL the MID Server connects to and the credentials of the MID user it authenticates as. These are the connection details required for the MID Server to reach and register with the instance.

The Call Pattern step invokes another pattern from within the current one, so shared identification logic lives in a single reusable pattern rather than being duplicated. This directly delivers the modularity and reuse the stem requires.

The Pattern Designer Debugger executes a pattern step-by-step on the MID Server, exposing each step's exact input and output values. This satisfies the requirement to inspect the specific failing step's data, which the standard pattern log does not capture.

Pattern Debugger Output captures each step's raw command execution, including stdout and stderr, so you can inspect the exact output produced immediately before the timeout. This satisfies the stem's requirement to investigate the specific preceding command's output, which the Discovery log alone does not expose at step-level granularity.

Encrypted credentials resolve through a credential alias tied to the MID Server or its policy. If that alias association is missing or misconfigured, the MID Server cannot decrypt or retrieve the credential, causing authentication to fail.

The MID Server initiates all communication, so it requires outbound access to the ServiceNow instance; no inbound firewall rules are needed. This satisfies the constraint that discovery traffic originates from inside the network, letting the MID Server reach the instance through the firewall.

Regular expressions are case-sensitive by default and may fail if the output has extra spaces or different formatting. This is a common issue when parsing command output. The pattern designer should test the regex against actual output and adjust for case insensitivity or whitespace. This is the most likely cause of the attribute not being populated.

The 'Run as' field on the individual pattern step specifies the OS user account under which that command executes, so setting it to root satisfies the requirement for privileged execution without elevating the whole pattern.

A Set Relation step explicitly defines a relationship between the CI being built and another CI. Referencing the previously captured host identifier ensures the guest is linked to the correct parent. This is the designed construct for expressing containment during pattern execution, so relationships appear in the CMDB after identification and reconciliation.

IRE requires identification rules to resolve to a single CI. When a payload matches multiple CIs, uniqueness cannot be established, so the engine rejects the payload and returns a non-uniqueness error rather than merging or arbitrarily selecting a record.

Dot notation with an array index, `servers[0].id`, traverses the parsed JSON object to the first element of the `servers` array, then reads its `id` property. This satisfies the stem's requirement to reach a nested property inside an array, since Parse JSON exposes the structure as addressable objects and arrays.

An excluded IP range is optional filtering, not mandatory schedule data. Discovery Schedules require core fields such as name, MID Server, and IP ranges to scan, so exclusion lists are supplementary. This makes it the element that is not a required part.

Discovery connects to Linux targets over SSH, so it requires SSH credentials — typically a username with either a password or private key. These authenticate the MID Server before patterns run commands such as uname or cat /etc/os-release.

An IP Service groups a named collection of ports and protocols that Discovery probes against target devices. It defines what to scan, letting administrators tailor horizontal discovery to specific services such as SSH or WMI rather than scanning every port indiscriminately.

Staleness measures how long since a configuration item was last updated by a discovery source. When that interval exceeds the defined threshold, the CMDB Health Dashboard flags the CI as stale, indicating the record may no longer reflect reality.

Horizontal discovery begins by identifying the device via probes and sensors, then establishes a connection using the appropriate credentials, and finally extends into the device to collect configuration data. This sequence satisfies the stem's requirement for the correct order of operations, since extension cannot occur before identification and connection succeed.

A Parse Variable step applies a regex to the prior command output, and the capture group isolates the numeric value regardless of surrounding text. This is the standard, robust approach when the value is embedded in a line with a stable label, and it avoids brittle line-position assumptions that break when output formatting changes across OS versions.

The IP Service record defines which ports Discovery probes for a given service type, so adding a port there extends scanning coverage. Updating it satisfies the requirement to scan the new port without altering credentials or schedules.

Publishing transitions the pattern from Draft to Active, which is the prerequisite state that makes it selectable by Discovery. An unpublished pattern cannot be referenced by a discovery schedule, so publishing must precede any use.

A custom Discovery Behaviour lets you define the exact probe sequence executed against a device class, overriding the default classification-driven probes. This satisfies the need to control which probes run for a specific device type, giving granular command over collection without altering global Discovery schedules or credentials.

The `cmdb_identifier_entry` table stores the identification rules that Discovery applies per CI class, so inspecting it reveals exactly which attribute combinations are being matched. Duplicates arise when those entries are misconfigured or missing, causing the same server to fail matching and create a new CI record instead.

MID Server logs are written locally by the agent, so they can be read directly on the host file system, which is essential when the instance is unreachable or the MID Server cannot check in.

Compliance is one of the three CMDB Health Dashboard metric families, evaluating CIs against defined certification, audit and policy requirements. It satisfies the stem's requirement by being an explicitly tracked health metric, alongside completeness and correctness, rather than a discovery or reconciliation setting.

The MID Server User credential authenticates the MID Server's outbound REST and SOAP calls into the ServiceNow instance, establishing the trusted identity under which discovery probes and imports run. Without it, the MID Server cannot log in, so no discovery results reach the instance.

The CMDB Health Dashboard aggregates discovery data into daily metrics on completeness, compliance and correctness, directly satisfying the requirement for daily monitoring. Unlike raw discovery logs or ad hoc queries, it surfaces stale or missing CIs continuously, letting administrators spot failing discovery schedules and credential issues before they degrade CMDB accuracy.

Using 'serial_number' as the sole identifier ensures that Discovery matches on this unique attribute. If a CI with the same serial number exists, it will be updated rather than duplicated. This is the correct approach because serial number is unique and reliable for routers.