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

The Data Source is the payload's declared origin, and it drives precedence during IRE processing: it determines which source's values win when multiple discovery sources contribute attributes to the same CI, affecting whether the CI is updated or created.

IRE logs record each identification and reconciliation decision, showing which identifier rule matched and which attribute value was written to the CMDB. This directly satisfies the requirement to debug why a specific CI attribute received its value.

Capabilities on the MID Server record determine which applications may use it. Removing the 'Discovery' capability leaves the MID Server running for other purposes but excludes it from Discovery scheduling, satisfying the requirement to prevent its use for Discovery.

Commenting steps documents the logic behind each operation, so other developers can maintain and troubleshoot the pattern without reverse-engineering it. This directly satisfies the maintainability and readability best practice for pattern design, reducing the risk of errors when patterns are revised or reused across discovery schedules.

Set Variable writes a value into a pattern variable that persists across sections, unlike step-local outputs. This satisfies the requirement to store the WMI query result so later sections of the same pattern can reference it.

The 'agent0.log.0' file is the primary log for the MID Server. It contains startup information, connection attempts, and error messages. When the MID Server status is 'Down', this log will show why it cannot connect to the instance, such as incorrect credentials, network issues, or SSL errors. It is the first place to look for troubleshooting.

Discovery schedules rely on the MID Server to execute probes and patterns against target devices. With the MID Server in a Down state, no orchestration occurs, so the scheduled discovery job either fails outright or never runs until the MID Server recovers.

The MID Server record in the ServiceNow instance stores the reported build and version details, populated during the heartbeat check-in. This satisfies the stem's requirement to view the MID Server's version directly, without accessing the host machine's filesystem or logs.

Identification Rules match devices using hardware attributes such as serial number and MAC address rather than IP address. When an IP changes, Discovery still correlates the CI to the existing record, preventing duplicate device creation.

When the Identification step fails to find a matching CI, the pattern's context variable for the CI's sys_id is empty. Using the condition '${ci.sys_id}' is empty ensures the step runs only when no existing CI was identified, which is exactly what is needed to create a new CI only when none exists.

Pattern Designer renders the execution flow of a pattern graphically, showing each step, the activities performed and their outcomes. This directly satisfies the requirement to visualise how a pattern runs, which the Discovery pattern log or configuration records alone cannot depict.

Identification Rules define which CI attributes (such as serial number, name, or BIOS UUID) are matched to detect an existing CI before insertion. Misconfigured or missing rules cause Discovery to create new records instead of updating existing ones, producing duplicates.

A MID Server Cluster groups multiple MID Servers under one logical name, so Discovery distributes horizontal jobs across members automatically. This satisfies the stem's load-balancing requirement, since clusters provide built-in failover and workload sharing rather than manual per-server assignment.

The Discovery Status module records each discovery run's progression through its individual phases, exposing where failures or delays occur. This phase-by-phase detail satisfies the stem's requirement by letting administrators pinpoint the exact stage at which a discovery schedule stalled or errored.

Discovery only probes addresses within configured IP ranges, so a new subnet absent from any range is never scanned. Verifying the Discovery IP Range first confirms the subnet is included and reachable, addressing the most common cause of no devices being detected.

The MID Server's agent logs record startup, connectivity and probe execution events. When the MID Server stops responding, these logs expose authentication failures, memory exhaustion or lost connections to the instance, making them a primary diagnostic source.

The CI Class Manager governs the CMDB class model: it defines the class hierarchy and configures identification and reconciliation rules that determine how discovered data maps to CIs and how duplicates merge. This directly satisfies the requirement to manage hierarchy, identification, and reconciliation.

To establish a relationship between a printer and a switch, Discovery often relies on the switch's MAC address table (CAM table) to see which MAC addresses are learned on which ports. The printer's MAC address must be present in that table. If the switch's pattern fails to collect or process the MAC address table, the relationship cannot be created. This is a common reason for missing network relationships in Discovery.

The error 'Authentication failed' indicates that the username or password (or key passphrase) provided by the MID Server was rejected by the target servers. Since the connection is established, the issue is with the credentials themselves. The credential record in ServiceNow may have a typo, an outdated password, or the wrong username for those specific servers.

Assigning only the WMI capability restricts the MID Server to WMI probes, because capabilities gate which discovery probes and patterns the instance schedules onto that server. SSH probes require the SSH capability, so their absence excludes them. This satisfies the stem's constraint of a single server performing WMI discovery while ignoring all SSH tasks.

Reconciliation rules resolve conflicting CI attribute values by applying the configured priority order, so the source with the higher priority overwrites the lower-priority value. This satisfies the stem's conflict scenario directly: precedence determines which discovered value persists in the CMDB, without manual intervention or record duplication.

Setting Run to Daily executes the Discovery Schedule once per 24-hour period, and the associated start time determines when that single run begins. Other intervals such as periodic or cron would not guarantee exactly one execution per day.

A for each step iterates over a collection, such as lines of command output, and executes a set of steps for each item. This is perfect for processing multiple entries and creating multiple CIs. It allows dynamic creation of records based on the data. This step type is designed for such repetitive tasks within a pattern.

Using the CMDB CI Lifecycle Management to transition the CI to a retired state is a structured approach to decommissioning. It ensures that the CI goes through the proper lifecycle stages, updating its status and potentially triggering workflows. This maintains data integrity by keeping a record of the CI's lifecycle and ensuring that it is no longer considered active. It is a recommended practice.

A running MID Server service that still shows Down in the instance points to a communication failure, so verify network connectivity between the MID Server and the instance and review agent.config settings such as the instance URL and credentials.

The mid.snmp.port parameter sets the default UDP port the MID Server uses when initiating SNMP discovery probes, overriding the standard port 161. It applies globally to SNMP-based discovery traffic unless a device-specific port is supplied.

The MID Server runs inside the customer's network and initiates outbound connections to the ServiceNow instance, relaying discovery and orchestration commands. This gateway model lets the instance reach internal systems without inbound firewall openings, satisfying the local network communication requirement.

A paused MID Server still reports its heartbeat as Up to the instance, so it appears healthy, yet the pause flag halts job polling and execution. Resuming it restores processing, which matches the stem's symptom exactly.

The MID Server Properties module manages global configuration properties that apply across all MID Servers, rather than per-instance settings. Changes made here propagate to every MID Server, providing centralised control of shared parameters such as thread pools and timeouts.

The MID Server IP range restricts which devices the MID Server is allowed to scan. If a device's IP falls outside the configured range, the MID Server will not process it, preventing unauthorized scanning. This ensures that Discovery is scoped to the intended network segments and avoids unnecessary traffic.

Identification rules determine how incoming CIs are matched and reconciled against existing records. Reviewing them first confirms the new tool's data will be identified correctly, preventing duplicate CIs before any discovery schedules or probes are configured.

Validation performs a mutual security handshake, exchanging credentials and certificates so the instance only accepts MID Servers it trusts. This satisfies the stem's security requirement, confirming the MID Server's identity before any discovery traffic or commands are accepted.

'Continue on error' overrides the default abort behaviour, so the pattern engine logs the failure and advances to the subsequent step rather than halting the whole execution. This satisfies the stem's question about the outcome of an error in such a step.

The CMDB Audit History related list on a CI record logs each attribute change with the old and new value, the user or integration that performed the change, and a timestamp. This directly answers which source modified which attribute and when, making it the right tool for this review.

A Parse step applies a regular expression to the raw command output, extracting the required value from multi-line text by matching a defined pattern rather than relying on fixed line positions. This handles the multi-line output constraint reliably within the Discovery Pattern.

Capabilities are assigned to MID Servers to restrict which discovery probes they may run, so a server can be limited to WMI or SNMP scanning rather than executing every probe type. This satisfies the stem's requirement for scan-type filtering, letting you dedicate MID Servers to specific protocols or network segments.

Restarting the MID Server is available directly from the record's related links, letting administrators recover a stalled or unresponsive MID Server without console access. This satisfies the scenario's requirement for actions triggerable from the MID Server record itself, alongside other operational links such as restarting the sensor or viewing logs.

Classification records contain conditions that determine when a device matches that classification. If the conditions are too restrictive or incorrect, the device will not be classified even if the pattern runs. The administrator should verify that the conditions (e.g., based on discovered attributes like operating system, manufacturer, or open ports) are accurate for this server.

This is correct because a Parse step with a regex targeting the 'src' token extracts the exact IP from the command output. The captured group can be mapped to the CI attribute in the pattern's data model, ensuring only the desired value is stored. This approach is robust and handles variations in other parts of the output.

An Extension Section appends custom logic to an existing pattern without altering the base steps, so the original functionality is preserved while your code runs during Discovery. This satisfies the constraint of extending the network switch pattern while keeping its shipped behaviour intact.

Discovery Range Sets are the standard way to define subsets of IPs for a schedule.

Parse JSON extracts named attributes from a JSON payload returned by an API, satisfying the requirement to pull a specific attribute. It converts the response into structured values usable by later pattern steps, unlike simple string or regex operations.

An unpaused MID Server is one of the three required 'Up' conditions. A paused node stops processing and reports as Down regardless of service state or heartbeat, so clearing the pause flag is essential for the Up status.

The CMDB Health Dashboard continuously scores configuration items against completeness, correctness and compliance metrics, surfacing stale, duplicate or orphaned records. This directly satisfies the stem's requirement to identify and report data quality issues, giving administrators actionable insight into CMDB integrity rather than merely storing data.

Orphaned CIs are those lacking any relationship record to other configuration items, leaving them disconnected from the service model. This status flags them for remediation so the CMDB accurately reflects dependencies rather than isolated, unlinked entries.

The CI Timeline displays a history of updates and the data sources that performed them.

Reconciliation Rules govern which data source may update a given CMDB attribute. If a rule excludes ServiceNow as an allowed source for the Operating System field, the pattern's correctly extracted value is discarded, leaving the attribute unchanged despite successful discovery.