CIS-Discovery Study Guide

Certified Implementation Specialist - Discovery

ServiceNow, Now Platform, Discovery, CMDB, and related names are trademarks of ServiceNow, Inc. This is an independent, commercial exam-preparation resource and is not affiliated with, endorsed by, or sponsored by ServiceNow, Inc. All study content below is original prose written for this guide; it is not copied from ServiceNow courseware or documentation.

This guide is organized by exam weight, heaviest domains first. The CIS-Discovery exam has 45 scored items in 90 minutes (single- and multiple-answer items). Spend your study time proportionally: roughly 70% of the exam lives in the first two domains below.

Order	Domain	Weight
1	Discovery Pattern Design	35%
2	Discovery Configuration	35%
3	Configuration Management Database	15%
4	Discovery Engagement Readiness	15%

Domain 1: Discovery Pattern Design (35%)

Patterns are the modern engine of horizontal Discovery. Where the legacy approach used a long chain of probes and sensors, a pattern is a declarative, ordered set of operations that the MID Server executes to find data, parse it, and populate Configuration Items (CIs). You author and edit patterns in the Pattern Designer, a low-code editor. Understanding what a pattern is made of and how it runs is the single most testable skill on the exam.

Anatomy of a pattern

A discovery pattern is built from sections, and each section is an ordered list of steps:

Identification section: runs first. Its job is to collect just enough data to identify the primary CI (for example, the host) and create or match it in the CMDB through the Identification and Reconciliation Engine (IRE). The identification section determines whether you have found a real, uniquely identifiable device before you invest effort exploring it.
Connection section(s): exist only in application patterns (Service Mapping). They run after an identification section has matched the CI and find the CI's outgoing connections (for example, from a load balancer to the application servers behind it, or from a running process to the database it connects to). Horizontal (infrastructure) patterns have no connection section, and a connection section never opens or authenticates the SSH, WMI or SNMP session.
Extension sections: add logic (often through a shared library) without editing the shipped identification section.
Steps and operations: every step holds exactly one operation, and steps run in order.

Operations and parsing strategies

Each pattern is a sequence of operations. Common operation types you must recognize:

Set Parameter Value: assign or compute a variable used later in the pattern.
Parse Variable / Parse File: extract structured data from raw command output or a file.
Process and connection collection: Parse Command Output on commands such as ps or netstat pulls running processes and their network connections (the backbone of application discovery).
WMI Query, SNMP Query, HTTP Get Call, Parse Command Output: protocol-specific data collection steps.
Create Relation/Reference: build a relationship (such as Runs on::Runs) or reference between CIs. CI attributes themselves are filled through CI attribute variables.
Create Connection: describe an outgoing connection; available only in connection sections of application patterns.
Merge Table / Filter Table / Transform Table / Union Table: manipulate the in-pattern tabular variables (Merge Table joins two tables, Filter Table keeps the rows that meet a condition).
Match: checks a condition and stops running the pattern if the condition is not met. It does not join tables or filter rows.

There is no generic "Web Service" operation (HTTP data collection uses HTTP Get Call) and no loop or For Each construct: table operations already work across all rows.

When you extract data from raw text, you choose a parsing strategy. The main strategies tested are:

Delimited text: split each line on a delimiter (space, comma, tab) into columns.
Configuration file strategies (for example INI or properties files): pull name = value style output.
Regular expression (regex): capture groups from semi-structured text. The most flexible and the most common source of pattern bugs.
XML / JSON / table: parse structured payloads directly into pattern variables.

Most operations write their results into a temporary variable (scalar or tabular). The documented variable kinds are global variables, CI attribute variables and temporary variables; there are no CI, Global or Connection "scopes". Later operations read from those variables. Tracing the flow of a variable from the operation that fills it to the operation that consumes it is the core troubleshooting skill.

Authoring and debugging in Pattern Designer

Use Debug mode to run a pattern against a chosen target, testing each step with its Test button and inspecting the value of every variable after each operation. This is how you isolate which operation produced a wrong or empty value.
Pattern steps run top to bottom; reordering operations changes behavior. An identification step that depends on a variable must come after the operation that sets it.
Extensions let you enhance a pattern (add new exploration logic) without altering its identification section, so you do not change how the primary CI is matched.
Patterns are versioned and can be associated with CI types; the right pattern runs based on what classification determined the device to be.

Pattern vs. probe-based discovery

Probes/sensors (legacy/classic) are still used in the early phases (port scanning, classification), but identification and exploration of most CI classes is pattern-driven today.
A pattern executes entirely on the MID Server and returns results in a single payload, which is generally more efficient than many round-trips of probes and sensors.

What to drill for Domain 1: the section types (identification, extension, and connection sections in application patterns only) and one operation per step; the order of operations and variable flow; Match vs. Merge Table vs. Filter Table; parsing strategies and when to use each; how to use Debug to find the failing step; extensions vs. editing identification; and how a connection section in an application pattern finds outgoing connections after identification.

Domain 2: Discovery Configuration (35%)

This domain is the operational plumbing: how Discovery is scheduled, which MID Server runs it, what credentials it uses, and how the four-phase horizontal flow actually executes.

The horizontal discovery flow: PCIE

Memorize the four phases in order. A useful mnemonic is PCIE: Port scan (Scanning) → Classification → Identification → Exploration.

Scanning (Port scan / Shazzam): the Shazzam probe sweeps the target IP range and fires port probes to detect which TCP/UDP ports are open and which protocols are alive. The result tells Discovery what kind of conversation each device can have (SSH, SNMP, WMI/WinRM, HTTP, etc.).
Classification: based on the open ports and a probe (for example, an SNMP, SSH, or WMI classification query), Discovery decides the device's broad type: Windows server, Linux server, network gear, storage, etc. Classification picks the right downstream identifier/pattern.
Identification: Discovery collects the attributes needed to uniquely identify the device and hands them to the IRE to create or match the CI in the CMDB (avoiding duplicates). Identification answers "is this CI already in the CMDB, and which record is it?"
Exploration: now that the CI is known, the pattern (or probes) gathers the full detail: installed software, running processes, network connections, disks, services, and relationships to other CIs.

A failure in an early phase cascades: nothing identifies if classification picked the wrong type, and nothing explores if identification failed.

Discovery Schedules

A Discovery Schedule is the record that tells Discovery what to scan, when, and how. Key fields and choices:

Discover (what to find): Configuration items, IP addresses, Networks, Service, Serverless, Cloud application, Cloud resources or Certificates.
MID Server selection method: Auto-Select MID Server (the platform chooses based on the Discovery or ALL supported application and the MID Server IP ranges), Specific MID Server, Specific MID Cluster, or Use Behavior.
Schedule / Run: periodic (daily, weekly), run on a recurring window, or on demand / Discover Now.
Max run time: stops a run that is still going when its window ends. (Concurrency is limited on the MID Server, for example by its worker thread settings, not on the schedule.)
Discovery ranges: the IP ranges, IP lists or networks the schedule scans, plus any exclusions.

Discovery Behaviors

A Discovery Behavior maps port probes / functionality to specific MID Servers for a given range. Behaviors are how you handle segmented networks: you tell Discovery "use this MID Server to reach that part of the network." Each Discovery Functionality in a behavior lists its MID Servers directly, and a schedule set to Use Behavior applies it to control which MID Server performs which phase against which subnet.

MID Server: selection, clusters, capabilities

The MID Server is the Java application installed inside the customer network that does all the actual probing; the instance never talks to target devices directly.

Selection: with Auto-Select, Discovery picks a MID Server whose supported Applications include Discovery (or ALL) and whose configured IP ranges cover the target. If none matches, the default MID Server for the application is the fallback. Auto-select ignores cluster membership. Specific MID Server, Specific MID Cluster or Use Behavior on the schedule overrides auto-selection.
Capabilities: declare which protocols or functions a MID Server offers and are used by other applications (for example Orchestration). For Discovery auto-selection, capability is not applicable.
Clusters: group MID Servers for load balancing (work spread across members, and members also take over a failed member's work) or failover (a standby takes over if one fails). To use a cluster for Discovery, set the schedule to Specific MID Cluster. Fail-over is not available when a MID Server fails while Shazzam is running under auto-selection.
Validation: a MID Server must be Validated, and Discovery accepts MID Servers that are Up or Degraded; check connectivity and that required ports outbound to the instance (HTTPS/443) are open.

Credentials

Discovery needs credentials to log into targets. You manage them on the instance (or in an external vault) and they are pushed encrypted to the MID Server.

Credential types: SSH (key or password) for Unix/Linux, Windows (for WMI/WinRM/PowerShell), SNMP (community string v1/v2c or USM for v3), VMware/vCenter, cloud (AWS/Azure/GCP service credentials), JDBC/SQL, and more.
Credential affinity: once a credential succeeds against a device/IP, Discovery records that pairing so it tries the known-good credential first next time, instead of cycling through every credential. This speeds up runs and reduces lockouts. If the affinity credential stops working, Discovery tries all available credentials again until it creates a new affinity. Before any affinity exists, the credential Order field sets the sequence. Credentials have no IP range field; Applies to limits them to all or specific MID Servers.
Least privilege: prefer credentials with only the rights Discovery needs. ServiceNow documents SSH commands that do not require a privileged (root/sudo) user versus those that do; design credentials to grant only what the required commands demand.

What to drill for Domain 2: the PCIE phase order and what each phase outputs; Shazzam/port probes; how MID Server auto-selection works (Discovery or ALL application plus IP range, default MID fallback, capability not applicable); clusters for load balancing vs. failover and Specific MID Cluster; behaviors mapping work to MID Servers per subnet; credential types per platform; and credential affinity.

Domain 3: Configuration Management Database (15%)

Discovery exists to populate a healthy CMDB. This domain is about how data lands correctly and stays trustworthy.

CI classes and the CMDB

CIs live in class tables that extend a base class (cmdb_ci) in a hierarchy (e.g., cmdb_ci_server → cmdb_ci_win_server). A more specific subclass inherits the parent's fields.
Classification during Discovery determines which class a CI is written to; reclassification moves a CI from one class to another (for example, when a device was first found generically and later identified more precisely). Reclassification has three types: upgrade, downgrade and switch. It is controlled by the glide.class.* system properties and by reclassification restriction rules, not by a setting on the identification rule.

Identification and Reconciliation Engine (IRE)

The IRE is the gateway through which Discovery and other IRE callers write CIs, so the CMDB stays free of duplicates.

Identification rules: each CI class has an identification rule made of one or more identifier entries, evaluated in priority order. An entry lists the criterion attributes that must match an existing CI for it to be considered "the same." Example: a server may be identified by serial number first, then by name + IP.
Reconciliation rules: when multiple discovery sources can write the same attribute, reconciliation decides which source is authoritative for that attribute. Once an authorized source has updated an attribute, later updates are accepted only from the same or a higher-priority source (unless the data is stale under a data refresh rule).
Duplicates: by default (skip_duplicates true) when an identifier matches several duplicate CIs, the IRE updates the oldest, marks the others with duplicate_of, and creates a de-duplication task.
Data sources & precedence: IRE tracks which source last updated a CI; this underpins reconciliation and helps spot conflicting writes.
IRE applies to payloads from its callers (Discovery, IntegrationHub ETL, Service Graph Connectors and the IRE APIs), inserting, updating, or matching CIs as the rules dictate. A plain import that writes CMDB tables directly does not pass through the IRE.

CMDB Health

CMDB Health dashboards score data quality across KPIs grouped into three families you should memorize:

Completeness: are required and recommended fields populated? (e.g., CIs missing an owner or a critical attribute).
Correctness: are CIs free of duplicates, orphans (per-class orphan rules that can test attributes, missing relationships or specific relationship types) and stale records (not updated within an expected window)?
Compliance: do CIs pass the audits (certification filters and templates) defined for them?

Health jobs run on a schedule and feed dashboards used to prioritize remediation (deduplicate, fill gaps, retire stale CIs).

What to drill for Domain 3: the CI class hierarchy and reclassification; that IRE is the entry point Discovery uses to prevent duplicates; identifier entries with criterion attributes evaluated by priority; reconciliation deciding authoritative source per attribute; and the three CMDB Health families (completeness, correctness, compliance) plus the fact that duplicate, orphan and stale CIs are Correctness metrics.

Domain 4: Discovery Engagement Readiness (15%)

Before Discovery can run successfully, the environment must be prepared. This domain is about the pre-implementation conversation with network, security, and platform teams.

Network zones and MID Server placement

Map the network into zones/segments and place MID Servers so that each zone is reachable. Firewalls between segments often block probe traffic, so a MID Server may be needed inside each zone, with Discovery Behaviors routing work to the correct one.
The MID Server makes only outbound HTTPS (443) connections to the instance: it never accepts inbound connections from the instance. Confirm this path is open.

Firewalls and ports

Discovery's MID Server must reach targets on the protocol ports the device uses: SSH 22, SNMP 161/UDP, WMI/RPC (Windows dynamic RPC + WinRM 5985/5986), HTTPS 443, SQL ports, etc. The Shazzam phase needs these ports reachable to detect services.
Work with the firewall team to allow the MID Server's source IP to reach the target ranges on the required ports; a device whose ports are all blocked shows as alive but not classified.

Least privilege and credentials governance

Request service accounts with only the privileges Discovery needs. On Windows, that means a domain user with local administrator rights on the targets. Many SSH discovery commands run without a privileged user; reserve sudo for the specific Discovery commands (used by both probes and patterns) that require it.
Use a credential vault integration where the customer mandates it, rather than storing secrets only on the instance.
Set the credential Order so the most likely credential is tried first; credential affinity then reuses the one that worked, which keeps runs fast and avoids lockouts from credential cycling.

Cloud discovery readiness

Cloud (agentless) discovery uses the cloud provider's API, reached via a MID Server with outbound internet to the provider endpoints, authenticated by a cloud service account / service principal.
Cloud discovery finds logical datacenters (regions/accounts) first, then the resources inside them; you run discovery on a service account to enumerate its datacenters and then their resources.
Ensure the service principal has read permissions across the subscriptions/accounts to be discovered.

What to drill for Domain 4: MID Server outbound-only 443 to instance; per-protocol ports for targets; placing MID Servers per network zone and using behaviors across firewalls; least-privilege service accounts (non-privileged vs. privileged SSH commands); credential vaults; and cloud discovery's service-account → logical datacenter → resources flow.

Fast-recall cheat list

PCIE = Scanning → Classification → Identification → Exploration. (Port scan, Classify type, Identify the CI via IRE, Explore details.)
Shazzam probe does the port scan in phase 1; port probes detect which protocols are alive.
A pattern = ordered steps (one operation each) in identification and extension sections, plus connection sections in application patterns only; runs on the MID Server.
Identification section runs first and finds/matches the primary CI; a connection section (application patterns) runs after identification and finds outgoing connections.
Match gates (stops the pattern if a condition fails); Merge Table joins tables; Filter Table filters rows; HTTP Get Call for HTTP. No Web Service operation, no loops.
Parsing strategies: delimited text, regex, configuration files (INI/properties), XML/JSON.
Debug mode in Pattern Designer = step through operations, inspect each variable to find the failing step.
Extensions add discovery logic without changing the identification section.
MID Server selection (Auto-Select) = Discovery or ALL application + IP range covering the target, default MID Server as fallback; capability is not applicable and clusters are ignored (Specific MID Server, Specific MID Cluster or Use Behavior override it).
Clusters: load balancing (spread work, members also cover a failed member) or failover (standby takes over).
Discovery Behaviors map port probes/work to specific MID Servers per subnet: used across firewalled zones.
Discovery Schedule defines what/when/which MID Server; supports Discover Now (on demand). There is no delta or changes-only schedule mode.
Credential affinity = remember the known-good credential per device/IP to try it first; if it fails, all credentials are tried again until a new affinity forms. Order sets the sequence before an affinity exists.
IRE is the gateway that Discovery and other IRE callers use to write CIs and prevent duplicates.
Identifier entries = criterion attributes evaluated by priority to match an existing CI.
Reconciliation rules decide the authoritative source per attribute.
CMDB Health families: Completeness (required and recommended fields), Correctness (duplicates, orphans, stale CIs), Compliance (audits).
Reclassification moves a CI between classes: upgrade, downgrade or switch.
MID Server → instance is outbound HTTPS/443 only.
Common target ports: SSH 22, SNMP 161/UDP, WinRM 5985/5986, HTTPS 443.
Least privilege: prefer non-sudo SSH commands; grant root/sudo only where required.
Cloud discovery: service account/principal → logical datacenters → resources, via MID Server over the provider API.