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

The ECC Queue is the bidirectional message queue carrying probes and commands from the instance to the MID Server, and returning payloads and results. This satisfies Discovery's requirement for asynchronous, firewall-friendly communication, since the MID Server polls outbound rather than accepting inbound connections from the instance.

Downloading the MID Server archive, extracting it, then running the bundled shell script is the documented Linux installation path. The script validates Java, configures the wrapper service, and registers the instance against your ServiceNow credentials, satisfying the stem's requirement for the standard Linux deployment method rather than a manual or Windows-based approach.

A freshly installed MID Server starts in Validation Required status, awaiting an administrator to confirm its configuration and credentials before it can be validated and moved to Up. Until validation completes, it cannot receive probes or execute discovery schedules.

Updating the probe's own timeout parameter targets only that probe, satisfying the requirement to adjust a single probe rather than the whole schedule. Probe-level parameters override the default timeout applied by the discovery schedule, so the change takes effect on the next run without affecting other probes.

Defining the line delimiter tells the parser where one record ends and the next begins, so each 'key = value' pair is processed as a discrete entry. Without it, the output cannot be split into individual records for attribute extraction.

The connection section handles protocol, credentials, and prompt detection, and command steps run within that established session. Matching the custom prompt ensures the MID Server knows when output ends before sending the next command. This is the designed mechanism for non-standard SSH devices and supports multiple sequential commands with parsing between them.

The MID Server acts as the execution proxy, running pattern commands against targets on behalf of the instance, since Discovery cannot reach those systems directly. It satisfies the requirement for remote command execution during pattern runs.

Identification reconciles discovered data against existing records before CIs enter the CMDB, matching on attributes such as serial number or MAC address. This deduplication satisfies the stem's requirement that identification prevents duplicate CIs, since creation without this reconciliation step would generate multiple records for the same physical device.

A Discovery Source records the tool or process that created or updated a configuration item, giving each CI record provenance. This lets administrators trace data origin, reconcile conflicting updates and trust records produced by authorised discovery methods, satisfying the need to know what populated the CMDB.

Pattern Debugger runs a single pattern step-by-step against a target host and displays the parsed variables, letting you confirm the serial number maps correctly to cmdb_ci_lb_device. It validates the identification section without triggering a full Discovery schedule.

Staleness measures how long since a CI's last update by Discovery. When Discovery has not refreshed the Windows server records within the configured staleness threshold, the CMDB Health Dashboard flags them, producing the high staleness score described in the stem.

Discovery Classification records contain the criteria (e.g., SNMP OID values, system descriptions) used to match devices to a specific class. If a router is misclassified as a printer, the classification criteria for 'Router' may not be matching correctly, or the 'Printer' classification may be too broad. Adjusting the Router classification's match criteria ensures the device is correctly identified.

A single MID Server caps discovery throughput. A MID Server cluster distributes probes across multiple nodes with load balancing, so discovery scales horizontally and continues if one node fails, satisfying the requirement to improve performance.

The CMDB Health Dashboard provides metrics and tools to identify duplicate CIs and other data quality issues. Regularly reviewing and reconciling duplicates helps maintain CMDB integrity. Even with good identification rules, duplicates can occur due to data inconsistencies. Using the dashboard to detect and merge duplicates is a proactive measure to minimize their impact. This action complements the identification rules.

A Discovery Exclusion List prevents specified devices or IP ranges from being probed and created as configuration items, directly satisfying the requirement to keep them out of the CMDB. It is applied before discovery runs, so excluded devices never generate CIs.

The MID Server is a Java application installed inside the corporate network that establishes outbound connections to the ServiceNow instance, executing probes, discovery and integrations on internal systems. It satisfies the requirement to reach network-restricted resources without exposing them to inbound internet traffic.

Reconciliation rules block unauthorized sources from updating records.

Unmapped pattern data is discarded because Discovery only persists extracted values that a pattern maps to a CI attribute or related field. The mapping step defines the target column; without it, the identification and exploration engine has nowhere to write the value, so it is dropped rather than stored in a staging table.

Spreading scans over several schedules and MID Servers divides the load, so no single segment absorbs the full probe volume at once. This directly satisfies the stem's constraint of avoiding network traffic impact, since concurrent discovery against many targets from one server is what saturates links.

WMI probes run against Windows targets, querying the Windows Management Instrumentation service over DCOM/RPC to collect hardware, OS and software data. This satisfies the scenario's requirement for a probe type the MID Server can execute natively on Windows hosts.

Classification examines discovered devices to determine their operating system or device type, assigning the appropriate class so records land in the correct CMDB table. This identification of O/S or device type is precisely the phase's purpose before identification and reconciliation proceed.

Discovery patterns are reusable, rule-based definitions that query and classify devices, then map discovered attributes into the CMDB as configuration items. They populate the CMDB with CI data, including relationships, rather than merely scanning the network.

The MID Server runs as a lightweight agent inside your network, initiating outbound connections to the ServiceNow instance. This lets discovery and orchestration reach devices that are unreachable from the internet, satisfying the requirement to discover infrastructure sitting behind firewalls.

Setting mid.log.level to debug raises the agent's logging verbosity, emitting detailed diagnostic entries about discovery and MID Server activity. This satisfies the stem's troubleshooting requirement by exposing granular execution detail unavailable at default levels, aiding fault isolation.

Regular expressions are ideal for extracting data from unstructured or semi-structured text where the format may vary. In this case, the 'uname -a' output can differ across distributions, so a regex can be crafted to match the version pattern regardless of surrounding text. It provides flexibility and precision. This is the recommended approach for parsing such command output.

Run as specifies the user privilege under which a pattern step executes, allowing discovery to authenticate with the credentials required to query restricted targets. This satisfies the requirement that configurable step attributes include the execution identity, not merely parsing or probe behaviour.

The MID Server uses Java's truststore to validate SSL certificates. By importing the ServiceNow instance's certificate (or its CA) into the MID Server's truststore, the MID Server can verify the instance's identity during TLS handshake. This is the standard method to ensure secure communication and prevent MITM attacks, especially in environments with self-signed certificates.

The MID Server's agent log, under agent/logs on the Windows host, records startup, configuration and connection failures — including rejected credentials or unreachable instance endpoints — that prevent the server registering in the MID Servers list. Checking it first satisfies the stem's requirement to identify the cause before validating network or instance-side configuration.

Discovery IP range exclusions are records that let you exclude specific IP addresses or subnets from being scanned, even if they fall within an included range. This is the correct way to prevent scanning of the database servers while still discovering the rest of the subnet. The exclusion is applied during the scanning phase.

The MID Server record provides a Restart UI Action that issues the restart command to the running MID Server service. This is the supported mechanism for forcing a service restart without accessing the host directly or restarting the entire instance.

The MID Server must reach the ServiceNow instance over the required outbound ports and protocols, typically HTTPS 443, through any proxy or firewall. Without that connectivity the MID Server cannot register or receive jobs, so network access is a planning prerequisite.

Service Mapping builds its service model by resolving CIs through identification attributes, so unstable or duplicate identifiers break topology generation. Ensuring existing CIs carry stable, unique identification attributes lets Service Mapping reliably match and extend the relationships already held in the CMDB during migration.

Completed signifies the discovery run has finished executing, meaning all scheduled probes and sensors have stopped and results are written. It does not by itself confirm every CI was discovered successfully; errors or unreachable devices are reported separately from this status value.

The Lookup step queries existing CMDB records to return values for pattern population, rather than discovering them from the target device. This satisfies the scenario's requirement to reuse already-stored data, such as resolving a related CI's attributes, instead of performing redundant probes or relying on Microsoft Entra ID or other external sources.

Shazzam is the port-scanning probe within Discovery, sending probes to target IP ranges to identify which ports and services are live. It supplies the raw scan results that later phases use to classify and map configuration items.

The Discovery Schedule record carries a MID Server field; populating it binds that specific MID Server to the schedule, so all discoveries it triggers run through that server. This directly satisfies the stem's requirement to associate a particular MID Server with the schedule.

Disabling the Active flag prevents the schedule from executing.

JSON parsing in Pattern Designer deserialises structured device output into key-value pairs, satisfying the stem's requirement for a valid parsing strategy. It handles REST API and modern device responses where nested attributes must be extracted directly, unlike delimiter-based or regex approaches that cannot natively traverse hierarchical JSON structures.

Selecting 'Variable' as the source retrieves the value from a memory variable previously created earlier in the pattern, such as one populated by an earlier step. This allows dynamic values to flow between steps rather than using static text.

Splitting discovery across multiple schedules and MID servers distributes scanning and processing load, preventing a single MID server or schedule from bottlenecking on a very large network. This directly satisfies the scale requirement through workload segmentation.

When installed as a system service, the MID Server service is registered with the operating system's service manager, which restarts it automatically after a host reboot. This satisfies the requirement for unattended recovery without manual intervention.

Delimited Text parsing is ideal for structured text where fields are separated by a consistent delimiter, such as a tab or comma. In this scenario, each line contains a software name and version separated by a tab, so Delimited Text can split each line into columns and extract the required values efficiently.

The Capabilities related list on the MID Server record controls which functions that agent may run, such as Discovery or Orchestration. Adding or removing capability entries directly governs task eligibility, satisfying the stem's requirement for where capabilities are defined.

The MID Server reads proxy host and port from config.xml to know where to send its outbound HTTPS traffic. Without these values, the MID Server would attempt a direct connection that the network blocks, so this setting is essential for operating in an environment where only a proxy provides access to the instance.

Discovery probes infrastructure and returns CIs and relationships as raw data; the Identification and Reconciliation Engine then applies identification rules to create or update authoritative CMDB records. This pipeline satisfies the stem by defining Discovery's role as a source feeding the CMDB rather than writing to it directly.

A MID Server cluster is defined by its member MID Servers: the individual MID Server records that join the cluster and share its workload. Without assigned members, no cluster exists, so membership is a required configuration factor.

Duplicate CIs are those sharing identical identification criteria — the same combination of identifying attributes defined for their class. This matches the dashboard's duplicate metric, which flags records whose identification fingerprints collide, regardless of name or other non-identifying fields, satisfying the stem's requirement for how duplicates are defined.

The ECC Queue holds the inbound and outbound payloads exchanged between the instance and the MID Server. When the MID Server shows 'Down', the most recent ECC Queue entries reveal the specific connectivity or authentication error causing the failure.

Exploration runs patterns against discovered devices to collect detailed attributes such as serial numbers, installed software and configuration, enriching basic identification data. This detailed attribute gathering is the phase's primary function before the data is normalised and reconciled.

The Discovery Dashboard aggregates discovery status metrics, showing totals of CIs discovered against those updated, which directly surfaces efficiency gaps in your Discovery infrastructure. It satisfies the stem's requirement for a summary view identifying potential issues, unlike raw logs or individual CI records that lack consolidated comparison.

The MID Server initiates all communication, so the firewall only needs to permit outbound TCP 443 to the instance. No inbound port or DMZ listener is required, satisfying the strict-firewall constraint while enabling discovery and orchestration.

A configuration item becomes stale when discovery has not refreshed its attributes within the expected reconciliation window, so the record no longer reflects reality. This differs from a missing CI, which discovery has never found at all.

The Capabilities list on the MID Server record restricts which probes that MID Server may run. Listing only WMI capability ensures the instance dispatches WMI scanning to it and nothing else, satisfying the single-purpose constraint.

Temporary Variables capture a step's returned data so later steps can reference it without re-querying the target. This satisfies the scenario's need to carry query output forward through the pattern's execution sequence, enabling dependent steps to consume values such as discovered attributes or identifiers.

Regex parsing extracts the version substring directly by matching the literal "Version:" anchor and capturing the numeric pattern \d+\.\d+\.\d+\.\d+, satisfying the need to isolate 1.2.3.4 from surrounding text in a single pass. Fixed-index or delimiter splitting would require extra steps to strip the label and punctuation.

By limiting the Discovery Behavior to only the probes required for Linux and Windows, the administrator reduces unnecessary scanning. Classification will identify the OS and trigger the appropriate probes. This approach minimizes MID Server load and ensures that only relevant probes are executed, meeting the requirement efficiently without compromising discovery completeness.

The Heartbeat is a periodic signal the MID Server sends to the instance. Its presence confirms the MID Server is actively communicating with the instance, distinguishing a healthy connection from a stalled or unreachable MID Server.

The MID Server uses a dedicated user account to authenticate with the instance. This user must have the 'mid_server' role, and the credentials must match those stored in the MID Server configuration. If authentication fails, the MID Server cannot receive or send data, so verifying the role and password is the correct first step.

By creating a custom capability and applying it to both the MID Server and the discovery schedule, you ensure that only MID Servers with that capability can execute the schedule. This effectively dedicates the MID Server to the sensitive segment, as other MID Servers without the capability will not process the task. This is the standard method for task routing.

Capabilities are stored directly on each MID Server record, letting that individual server advertise which discovery probes and patterns it may run. This satisfies the stem's constraint by scoping capability assignment per server rather than globally, so administrators control exactly which MID Server handles each discovery task.

ServiceNow Discovery patterns support a 'Pattern' step that allows you to call another pattern as a subroutine. By creating a separate pattern with the common steps and invoking it from other patterns, you promote reusability and maintainability. This is the recommended approach for sharing logic across patterns.

Staleness arises when CIs are never revisited by Discovery. Ensuring every target device falls within a discovery schedule guarantees each CI is periodically re-verified, preventing devices from being silently omitted and their records ageing beyond acceptable staleness thresholds.

Credential records hold the usernames, passwords, and related authentication data Discovery uses to log into target devices during horizontal and vertical discovery. They satisfy the requirement by supplying the login secrets referenced by discovery schedules.

Credential Aliases decouple discovery from stored credentials, letting a single alias resolve to different credential records per MID Server or environment. This satisfies the requirement that credentials be referenced indirectly, so Discovery can select the correct credential without hard-coding it into each schedule.

Without a matching pattern, Discovery cannot execute the probes and classification steps needed to identify and populate the device record, so the horizontal discovery run for that CI ends incomplete rather than producing a fully mapped configuration item. The missing-pattern constraint therefore halts completion for that device specifically.

Classification criteria determine how devices are matched to CI classes. If the criteria for Windows are missing, incorrect, or ordered after a more generic Linux criterion, the device may not be classified correctly. Reviewing and adjusting the criteria ensures that the Windows server is properly identified. This is a direct troubleshooting step for classification failures.

The Identification Section in the Pattern Designer defines the criteria used to match and identify a CI, such as serial number or name. It satisfies the requirement to specify identifying attributes, distinguishing it from the Connections or Steps sections, which handle relationships and discovery actions.

Discovery appears in the MID Server Capabilities list because it enables the MID Server to run horizontal and vertical discovery probes, scanning IP ranges and classifying CIs. Without this capability assigned, the instance cannot dispatch discovery schedules to that MID Server.

The Pattern Log records each pattern's execution steps, including which commands ran and where parsing failed, so reviewing it in Discovery Status reveals the exact point of failure. This satisfies the need to trace pattern behaviour during debugging.

Delimited parsing splits command output on a consistent separator, extracting each field into distinct values for attribute mapping. Because the stem specifies lines separated by a uniform delimiter, this strategy directly matches the data structure and populates the target attributes reliably.

Serial number and manufacturer on Windows are typically collected through WMI queries executed by specific probes and pattern steps. If those steps fail or are excluded for this device, the CI is still created and classified but hardware attributes remain empty. Reviewing these probe steps and their ECC queue results is the most direct way to find why one server differs from its peers.

Raising `wrapper.java.maxmemory` in wrapper.conf directly lifts the JVM heap ceiling the MID Server's Java process may allocate, resolving consistently high memory usage caused by heap exhaustion. This parameter governs maximum heap size, so tuning it addresses the stem's constraint without altering thread pools or probe scheduling.

Raising the MID Server's concurrent task limit lets it run more probes and patterns in parallel, directly addressing the throughput bottleneck causing the slow scan. The constraint in the stem is scan duration, and this setting governs how many discovery jobs execute simultaneously, so additional capacity is used rather than sitting idle.

Pattern Designer's Test mode runs a pattern against a chosen Discovery status record's input payload, letting you validate parsing and step logic without launching a full scan. This satisfies the requirement to test in isolation.

Manual 'Discover Now' initiates an on-demand horizontal discovery run against a specified CI or IP range, bypassing the scheduled pattern. It satisfies the stem's requirement for a valid trigger because it invokes the same Discovery engine and probes as automated schedules, letting engineers validate credentials or troubleshoot mid-cycle without waiting for the next window.